Jump to content

migo315

Members
  • Content Count

    42
  • Joined

  • Last visited

  • Days Won

    1

migo315 last won the day on October 9

migo315 had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Serverumzug ist durch. Das Filterhandling habe ich nochmal angepasst und vereinfacht. Wenn ich zum Beispiel nach Achterbahnen von Vekoma suche, die man ab mindestens 120cm Größe fahren darf und sich in einem Radius von 50km meiner aktuellen Position befinden, sieht so eine Abfrage wie folgt aus:
  2. Ich habe mal den Hinweis bekommen, dass man die Halle nicht abreißen wird, da man eine erneute Baugenehmigung für ein Objekt solcher größe an dieser Stelle nicht bekommen würde. Was in der Halle daraus gemacht wird, ist dann aber eine andere Sache. Inwiefern dieser "Hinweis" wirklich auf Tatsachen beruht oder Spekulation war, kann ich nicht sagen. Plausibel klingt dies aber durchaus.
  3. Nur zur Info: In den letzten Tagen sowie den nächsten Tagen wird man nicht viel von mir hören. Ich plane einen Serverumzug und werde leider(!) meinen aktuellen Hoster heroku.com verlassen. Die letzten Tage habe ich mehrere Hoster gestetet und den Umzug vorbereitet. Da mache ich die nächsten Tage auch weiter. Daher wird hier diese Woche nicht viel passieren.
  4. Heute habe ich mich dem Thema Sortierung, Filterung und Facetten (Auswahlmöglichkeiten für Filter) gewidmet. Bisher war es so, dass ich 1:1 die Syntax erwarte, welche meine Such Engine benötigt. Ich habe diese quasi nur weitergegeben. Das hatte zwei Vorteile: Es war mega flexibel, da quasi jedes Feld aus der Such Engine frei zur Verfügung stand und ich musste keine "Zwischenschicht" einbauen. Nachteil war aber, dass es dadurch X mögliche Kombinationen gab die ich nicht dokumentieren wollte und das jede Änderung in meiner Such Engine ggfs. die oder andere Abfrage verfälscht. Beispiel Sortierung: Wenn man nach Name Sortieren möchte, musste man bisher über die REST API die Sortierung via Query Parameter mitgeben: https://api.coaster.cloud/parks?sort=name.keyword.desc "name.keyword" ist dabei das Feld in der Such Engine. Mal davon abgesehen, dass ja eigentlich nur ich die Feldnamen aus meiner SuchEngine kenne, könnte das Feld theoretisch auch jederzeit umbenannt werden. Uncool für Entwicker. In Zukunft will ich diese "flexibilität" auflösen und tatsächlich alle Sortierungen hart definieren. In GraphQL dann als ENUM darstellen. So kann jeder Entwickler über die GraphQL Doku leicht sehe, welche Sortiermöglichkeiten es gibt und kann bei der Syntax keine große Fehler machen (dank Validierung und Autocomplete). So stelle ich mir dies vor: Das gleiche auch bei Facetten. Hier war jedes Feld möglich und man musste 1:1 den Feldnamen aus der SuchEngine verwenden. Beispiel: https://api.coaster.cloud/parks?facet[]=address.country.translation.de&facet[]=types.translation.de Auch das möchte ich mit ENUMS lösen. Dieses Beispiel, um die Liste aller Länder und Park Typen zu erhalten, würde dann ca so aussehen: Und Filter ähnlich. Auch da definiere ich die Filtermöglichkeiten demnächst vor. Statt so ... https://api.coaster.cloud/parks?filter[]=address.country.code:"DE" ... dann so um alle Parks aus Deutschland zu erhalten: Der Vorteil: Alle Sortier- Filter- und Facettenmöglichkeiten sind fest definiert. Dadurch sind diese auch Dokumentiert (samt Validierung und Autocomplete). Und alle drei sind nicht mehr hart an der SuchEngine gefesellt, so dass interne Änderungen in der SuchEngine (oder gar der Austausch der SuchEngine) zu keine Veränderungen in der API führt. Je mehr ich mit GraphQL arbeite, desto mehr merke ich, dass für eine so große öffentliche API diese weitaus geeigneter ist als REST.
  5. Ich finde es echt immer wieder traurig, wenn in Wartezeit Diskussionen eine Preispolitik als Lösung erachtet wird. Ja, über Preise kann man einen Markt so regulieren, so dass einigen Menschen etwas nicht mehr wahrnehmen können oder wollen. Sozial ist aber was anderes ... Versteht mich nicht falsch: Alles soll seinen Preis haben. Und wenn der Movie Park aus wirschaftlichen Gründen eine Preis pro Maze verlangt, ist dies völlig legitim. Wenn aber nur an der Preischraube gedreht werden soll damit weniger Leute sich den Park leisten können und entsprechend man weniger Warten muss, ist das einfach nur traurig.
  6. Habe heute mal was gemacht. Die REST API und die bisherige GraphQL API hat die Daten immer live aus der Datenbank gezogen, verarbeitet und ausgegeben. Ab heute werden die Daten aus der GraphQL aber bereits vorab verarbeitet und serialisiert gespeichert. Bei Abfragen wird daher keine einzige Datenbank Query mehr ausgeführt. Die Such Engine gibt das seralisierte Ergebnis zurück, welches dann nur noch ausgegeben werden muss. Das steigert die Performance. Hier der Vergleich: REST API: 700 - 800 ms im Schnitt Alte GraphQL: 300 - 500 ms im Schnitt Aktuelle GraphQL: 100 - 200ms im Schnitt Damit lässt sich arbeiten. Im November werde ich vermutlich auch den Hoster wechseln und auf eine Machine mit mehr Power gehen. Dann könnte sich der Wert auch noch verbessern. Anmerkung: Sobald man Wartezeiten in der GraphQL abfragt sind die Zeiten eher bei ~400ms. Dann werden auch Datenbank Abfragen gemacht, da diese Daten noch nicht in der Such Engine gespeichert werden.
  7. Kollegen von mir waren da. Montag werde ich wohl mehr Erfahren. Denn diese Meinung ... ... teile ich. Das Publikum im Movie Park sind sowieso oft nicht die "nettesten". Ich kann mich an recht alten Zeiten erinnern, wie damals schon halbstarke Versucht haben am HHF Leute zu erschrecken und dabei ein wenig zu weit gingen.
  8. Uiuiui, als ich das heute morgen direkt nach deiner Nachricht getestet habe, ist mir schon die Kinnlade runtergefallen. Die Antwortzeit lag bei ~3 Sekunden. Kurios: Die REST Api war weiterhin zügig. Dabei verwenden beide den identischen Code unter der Haube. Letztendlich lag die Ursache daran, dass die GraphQL API einen PHP Warning geschmießen hat. Und die werden nach Sentry gesendet. Wenn der Fehler also bei 25 Parks auch 25 mal Auftritt, wird dies 25 mal an Sentry gesendet. Und das hat die Performance runtergezogen. Ich habe den PHP Warning gelöst, jetzt liegt die GraphQL wieder bei den ähnlichen Geschwindigkeit wie die REST Api.
  9. Ich denke ebenfalls das die Rate der Jahreskartenbesitzer höher ist. Zur Preis Leistung muss man ja ebenfalls erwähnen, dass die Saisonkarte für 70 € ja den Zugang in drei Parks in direkter nähe (Bobbejaanland, Movie Park, Slagharen) für eine komplette Saison einschließt. Das ist eigentlich schon fast "unverschämt" günstig. Ja, der Movie Park kann vom Niveau her nicht mit dem Phantasialand mithalten. Aber sowohl im Movie Park (als auch Bobbejaanland) kann man Spaß haben. Sowohl als Erwachsener als auch mit Kinder. Und das für 70 € ein ganzes Jahr. Einfach unschlagbar. Das viele den vollen Tagespreis zahlen ist mir aber auch schon aufgefallen. Und verstehen kann ich es nicht, dass man es nicht schafft, mal eben auf die Movie Park Seite zu gehen. Denn konkrete Vergünstigungen braucht man gar nicht. Der Movie Park bietet eine Tageskasse für 29,50 € an. Aber eben nur Online und mit 2 - 3 Tage Vorlauf - dafür aber fast jeden Tag. Ohne Gutscheine und Co kann man also für quasi fast jeden Tag eine Tageskarte für unter 30 € erhalten. Ein Guter Preis. Alles darüber wäre zu teuer. Movie Park sehe ich daher auch in einem ganz anderen Preisniveau als Phantasialand. Du hast die Chance, ohne jegliche Rabattaktionen, unter 30 € in den Movie Park zu kommen. Das schafft man im Phantasialand nicht - da ist man zwingend auf eine Aktion angewiesen. Und diese ist meist auch zeitlich begrenzt. Einzige Ausnahme sind da der VVK für die Wintertage. Da finde ich Phantasialand tatsächlich günstig. Hab erst gestern die Karten für 23 € gekauft.
  10. Den großteil der Park- und Attraktiondaten ist mittlerweile abgreifbar: https://api.coaster.cloud/playground Die lokalisierung habe ich nochmal angepasst. Statt eine Ebene runter zu gehen, kann man die Sprache als Argument mitgeben. Wird keine Sprache angegeben, wird als Standard "englisch" genommen. Beispiel um den Status vom Phantasialand zu bekommen: Ich habe dies angepasst, da ich stäker mit Argumenten arbeiten möchte in Zukunft. Eine Idee wäre zum Beispiel, dass der Entwickler bei Attributen (zb. die Höhe einer Attraktion) die Einheit angeben kann. Statt Meter zum Beispiel die Höhe in Fuß (auch: fiktives Beispiel): Habt ihr Lust euch mal den aktuellen Stand (siehe https://api.coaster.cloud/playground) anzusehen und Feedback zu geben? Passt das für euch? Ist etwas unklar dokumentiert?
  11. Ich habe immer wieder das Problem, seit ein paar Wochen, dass der Werbebanner über den "Antworten" Button gelegt wird. Muss dann immer mit FF Devtools das ganze HTML gedöns entfernen. FireFox 70.0
  12. Imho können die aktuelle, jungen Generationen nichts mit dem Bermuda Dreieck mehr anfangen. Daher war ein Thema Wechsel durchaus Sinnig um etwas "greifbares" zu haben. Auch wenn ich selber die Bermuda Geschichte eher mag.
  13. Nein, die Seite wird einfach nur nicht richtig gepflegt. Siehe aktuelle Zeiten auf https://coaster.cloud/de/parks/phantasialand/waiting-times oder https://queue-times.com/parks/56/queue_times // Edit: Da waren ein paar schneller
  14. Für die vollständige Umsetzung der GraphQL werde ich wohl noch ein wenig länger dauern. Ich muss bei manchen Sachen echt noch ausloten, was wie am Besten umgesetzt wird. So sieht mein Plan aus: - Die GraphQL wird in den nächsten Tagen immer weiter ausgebaut. - Die REST API bleibt bis zum offiziellen "Release" der GraphQL ebenfalls bestehen - Nach Release der GraphQL wird die REST API entfernt. - Ich werde morgen bereits mit einem fetten Hinweis daraus aufmerksam machen, dass die REST API deprecated ist und mit der in Entwicklung befindlichen GraphQL ausgetauscht wird. Ich plane die GraphQL bis zum 3.November fertig zu haben und zu releasen. Mittlerweile habe ich einige Verbindungen gesetzt. Wenn man Efteling abfragt, kann man dazu nun auch die Wartezeiten (Queues) abfragen. Und zu jeder Queue die verknüpfte Attraktion (Attraction !== Queue, da eine Attraktion mehrere Queues haben kann). Die Abfrage sieht dann so aus: Die "lokalisierung" von übersetzbaren Texten überlege ich so zu lösen, dass der Entwickler einfach die Sprache auswählt (siehe state.label.de im Beispiel oben). In der REST API hat der Entwickler immer die Sprache als Query Parameter einmal gesetzt. Zwar muss der Entwickler so an diversen Stellen die bevorzugte Sprache angeben, kann dafür flexibel an jeden Knoten entscheiden ob er deutsch oder englisch oder beides haben will.
  15. Sehr gut! Bisher filter ich immer in der App anstatt bereits die API filtern zu lassen. Macht Sinn so ein Filter in der API einzubauen! Das geht je bereits über die REST API. Wenn man zum Beispiel alle Attraktionen vom Phantasialand haben möchte, die man 100cm und einem Alter von 4 Jahren fahren darf, funktioniert folgende REST URL: https://api.coaster.cloud/parks/f7328b4a-3308-4823-b4b6-58fb9a254199/attractions?filter=regulation(100,4) Alles, was die REST API kann, würde natürlich auch die GraphQL API dann können. Alles ändere wäre ja sonst witzlos. In der GraphQL API habe ich die Attraktionen mal (mit Namen) ebenfalls testweise umgesetzt. Die Abfrage der Größenbestimmung sieht dann so aus: Oder man möchte nur die aktuellen Wartezeiten vom Phantasialand: Wie erwähnt: Setzt euch noch nicht mit der Syntax fest. Ich "spiele" gerade nur rum. Die finale Fassung wird wohl erst Mitte / Ende der Woche fest stehen. Langsam fang ich aber an GraphQL immer mehr zu lieben
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.