Digital Tourism Blog

Die imx.ContentDelivery API (Link) ist ein mächtiges Werkzeug, das extrem performant kontextbasierte Datenabfragen ermöglicht. In unserem aktuellen Lechradwegprojekt (www.lechradweg.info) konnte sie in einem ihrer ersten Anwendungsfälle ihr Potenzial zeigen.

Wer sich in seinem Arbeitsalltag nicht täglich mit Datenbanken und Schnittstellen beschäftigt, tut sich zugegebenermaßen manchmal schwer zu verstehen, warum unsere Entwickler bei der imx.ContentDelivery API ins Schwärmen kommen. Wir haben daher Benjamin Hofmann, Lead-Entwickler im Lechradweg-Projekt, und den Technischen Geschäftsführer Christian Heindl gebeten, am Beispiel des Lechradweg-Projekts so praxisbezogen wie möglich die Vorteile der imx.ContentDelivery API aufzuzeigen.

1. Bitte beschreibt an konkreten Beispielen, was die imx.ContentDelivery API im Lechradweg-Projekt macht.

Christian: Die neue Content Delivery API stellt die direkte Verbindung zwischen der Single-Page Anwendung und der imx.Platform ohne die Notwendigkeit einer Middleware her. So werden z.B. alle Etappenlisten, POI-Listen oder auch Detailseiten direkt vom Browser bei der Content Delivery API angefragt und jeder Request enthält genau nur die Daten, welche für die jeweilige Situation benötigt werden.

Benni: Auch zukünftige Erweiterungen der Daten werden direkt über die Content Delivery API abgefragt werden. Dadurch wird es sehr einfach, die verschiedensten Daten aus unterschiedlichen Quellen miteinander zu verschneiden und in Kontext zu bringen.

2. Was sind die Vorteile aus Sicht unserer Kundinnen und Kunden?

Christian: Es ist keine separate Implementierung einer Middleware zur imx.Platform mehr erforderlich, was zu kostengünstigeren Projekten führt.

Benni: Die Content Delivery API basiert auf GraphQL, einer weithin unterstützten und gut dokumentierten Art von Schnittstelle. Dies macht es auch neben konkreten Projekten wie dem Lechradweg sehr einfach, die benötigten Daten abzufragen und diese dann zu verwerten.

3. Inwiefern haben User etwas vom Einsatz der imx.ContentDelivery API?

Christian: Für Nutzer*innen ist weniger die Content Delivery API von Relevanz, sondern eher der Einsatz einer Single-Page App (SPA) auf Angular-Basis, welches eine reaktive Oberfläche und auch die Offline-Fähigkeit erst sauber ermöglicht.

Benni: Als User hat man hauptsächlich mit dem sichtbaren Frontend zu tun und hier kann die Content Delivery API beim Lechradweg alle Vorteile ausspielen, die sie zu bieten hat. Dadurch, dass beim ersten Seitenaufruf bereits alle zur Anzeige notwendigen Assets vom Browser heruntergeladen wurden, finden bei weiteren Seitenaufrufen nur noch die Requests gegen die API statt. Diese Requests sind sehr schnell und liefern nur die wirklich notwendigen Daten, was auch Traffic im mobilen Umfeld spart. So reagiert die Seite extrem schnell auf Usereingaben.

4. Und wie erleichtert sie das Leben der Entwickler*innen?

Christian: Durch die Content Delivery API werden Logiken zur Interpretation des imx.Platform-Datenmodells bereits in der API zentral implementiert. Diese müssen nicht mehr für jedes Projekt bzw. jede Ablaufumgebung neu implementiert werden – oder in jedem Projekt einzeln nachgezogen werden, wenn sich etwas grundlegend ändert. Daneben gibt es für Entwickler*innen nun ein komplett typisiertes Datenmodell, so dass clientseitig jeweils eine vollständige Typprüfung ohne Unsicherheiten bei der API-Anbindung erfolgen kann.

Benni: Als Entwickler muss man nur einmal verstanden haben, wie man mit einer GraphQL-Schnittstelle sprechen muss, damit sie die benötigten Daten liefert. Man muss dadurch deutlich weniger Fachwissen für verschiedene Schnittstellen aufbringen, und das beschleunigt die Implementierung enorm. Außerdem ist das Debugging sehr einfach, da man z.B. Tools wie Altair nutzen kann, um seine Anfragen auf Fehler zu prüfen und zu korrigieren.

5. Welche ersten Erfahrungen habt Ihr mit der imx.ContentDelivery API im ersten Praxiseinsatz gemacht? Nennt gern ein paar konkrete Beispiele und Learnings.

Benni: Nach meinen ersten Erfahrungen mit der Content Delivery API würde ich gerne nur noch diese nutzen, da die Anbindung einfach Spaß macht. Und auch die Dokumentation ist hervorragend, sowohl von GraphQL selbst als auch von den diversen Tools, die man nutzt, um damit zu sprechen. Einmal kurz gegoogelt und schon hat man die passende Lösung parat.
Aber auch hier steht und fällt alles damit, wie sauber man im jeweiligen Projekt arbeitet und dessen Datenmodell definiert. Manchmal ist es sinnvoll, nicht für alles eine eigene Abfrage an die API zu senden, da man eine andere Abfrage evtl. ein bisschen erweitern kann, um dann vom Caching zu profitieren und einen erneuten Request einzusparen.

Vielen Dank!

Noch mehr Infos über das Lechradweg-Projekt gibt es in unserer Success Story lechradweg.info auf unserer Website.