Wie so viele unserer eigenen Marken und Projekte begann der “Beergarden Finder Munich” mit einer simplen Frage: Welcher ist der beste Biergarten in München? Als wir diese Frage in 2012 gestellt haben konnten wir nicht ahnen, mit welcher Schärfe dieses Thema in Bayern diskutiert wird. Jeder hat da natürlich eigene Vorlieben. Deswegen haben wir gemeinsam mit Jens Wiese das getan, was jeder in 2012 getan hat: Eine App gebaut!

Die erste Version der App aus 2012 basierte auf einem eigens gebauten PHP-Backend und einer mit dem Titanium SDK geschrieben iOS App. Auch wenn die App für uns primär als Proof of Concept diente bekamen wir doch angenehmes Feedback. Eine hohe Priorität hatte die App für uns jedoch nie, was dazu führte, dass die App lange nicht aktualisiert wurde.

Auf der UX Munich 2015 fanden wir dann aber die Inspiration das Projekt “Beergarden Finder Munich” noch mal von einer neuen Perspektive zu betrachten. Alles neu, alles besser! Aber immer noch primär zum lernen und ausprobieren.

Irgendwas mit WordPress

Eine Sache war klar: Wir wollten irgendwas mit WordPress machen. Erfahrungen mit der Anzeige von eigenen Locations auf Standort-Karten hatten wir im selben Jahr bereits in unserem Projekt für Munich Startup gesammelt, wo wir auf Basis von WordPress eine Karte mit den Startups in München angezeigt haben.

Aber wie kann man eine ähnliches Konzept als App darstellen und trotzdem die Bequemlichkeit und Flexibilität von WordPress erhalten? Zum Glück arbeitete ein Team um den WordPress Contributor Ryan McCue zum selben Zeitpunkt an der WordPress REST API. Deswegen haben wir uns dazu entschieden, bei der Kommunikation zwischen App und WordPress Backend auf die Version 1.2 der WP REST API zu setzen.

Im Jahr 2015 war das Konzept “Headless CMS” noch nicht weit verbreitet. Rückblicken ist unklar, ob wir zu diesem Zeitpunkt schon davon gehört hatten. Trotzdem war es für uns die logische Architektur, um die App umzusetzen.

Was ist ein Headless CMS?

Ein CMS wie WordPress wird als “headless” bezeichnet, wenn es nicht direkt mit einem Frontend verbunden ist. In einem solchen Szenario werden die Inhalte über eine API bereitgestellt und von externen Clients, die normalerweise vom CMS getrennt sind, konsumiert.

Der Hauptvorteil eines Headless CMS besteht darin, dass es einen “reinen” Content-Hub ermöglicht. Dieses bietet die Flexibilität, Inhalte auf vielfältige Weise wiederzuverwenden und an unterschiedliche Anforderungen anzupassen. Beispielsweise können die Inhalte für Websites, mobile Apps, Virtual Reality, Wearables und in jeder Umgebung mit Internetzugang genutzt werden.

Ein weiterer Vorteil von Headless CMS ist die Entkopplung von Frontend und Backend. Dadurch wird die Entwicklung und Skalierung von Projekten erleichtert. Da die Präsentationsschicht von der Inhaltsverwaltung getrennt ist, können Entwickler und Redakteure unabhängig voneinander arbeiten. Das erhöht die Effizienz und Flexibilität des gesamten Prozesses enorm.

Im Fall des “Beergarden Finder Munich” dient WordPress als Headless CMS. Dieses stellt einer mobilen App die erforderlichen Daten zur Verfügung, damit die notwendigen Informationen über die Biergärten angezeigt werden können.

Was ist eine REST API?

REST, die Abkürzung für Representational State Transfer, beschreibt nicht direkt die API (Application Programming Interface) selbst, sondern vielmehr die zugrundeliegende Struktur und Architektur einer API. Der Zweck von REST besteht darin, einen einfach zu nutzenden, maschinenlesbaren Endpunkt zum Austausch von Daten, Informationen und Inhalten bereitzustellen.

Die Idee von REST ist es, diese Daten ohne einen dominanten Zustand für verschiedenste Arten von Clients verfügbar zu machen. Ob bei Single-Page-Webapps, mobilen Apps, digitaler Beschilderung oder Handelsanwendungen – REST findet in der heutigen Welt nahezu überall Anwendung.

Eines der zentralen Prinzipien von REST trägt den Namen HATEOAS, was für “Hypermedia as the Engine of Application State” steht. HATEOAS beschreibt die Notwendigkeit, innerhalb einer API über URLs zu navigieren, anstatt über Zustände oder Variablen. Das Ergebnis ist eine klar strukturierte und leicht verständliche Architektur, die die Daten effektiv organisiert.

Ein praktisches Beispiel hierfür ist die WordPress-API. In der REST-API sind alle unsere Beiträge im JSON-Format abrufbar, beispielsweise unter dem Endpunkt https://www.luehrsen-heinrich.de/wp-json/wp/v2/posts. Fügt man am Ende eine Post-ID hinzu, erhält man alle verfügbaren Informationen für einen einzelnen Beitrag, wie zum Beispiel unter https://www.luehrsen-heinrich.de/wp-json/wp/v2/posts/2253.

Die App entwickeln

Nach einer kurzen, aber intensiven Konzeptphase hatten wir eine klare Vorstellung von den benötigten Daten für unsere App. Daraufhin implementierten wir die erforderlichen Funktionen in Form eines WordPress-Plugins. Die Datenerfassung basierte auf einem benutzerdefinierten Beitragstyp, der durch mehrere Metaboxen erweitert wurde, um sämtliche relevanten Daten für das Frontend bereitzustellen.

Die Entwicklung der App selbst gestaltete sich äußerst unkompliziert. Um plattformunabhängig zu sein und unseren Erfahrung mit JavaScript zu nutzen, entschieden wir uns für ein “Titanium SDK”-Projekt.

Wir füllten einen “Map View” mit den von der REST-API bereitgestellten Daten und fügten weitere Detail- und Inhaltsansichten hinzu. Die größte Herausforderung bestand in der Implementierung der Abstimmungs- und Kommentarfunktionen, da wir Inhalte über die API an das WordPress-System zurücksenden mussten.

Fazit

WordPress als Headless CMS einzusetzen, ist definitiv eine attraktive Option. Wir sind zuversichtlich, dass uns in der Zukunft nützliche Hooks, Filter und Aktionen zur Verfügung stehen werden, um das Frontend zu deaktivieren und die Systembelastung zu reduzieren. Bis dahin setzen wir einfach auf ein minimalistisches Theme.

Um ein optimales Beispiel abzugeben, könntest du den Theme-Teil deines WordPress-Systems verwenden, um die Dokumentation für dein “Headless” CMS und die API bereitzustellen.

Eine Frage, die uns beschäftigt, ist, wie ein post-Gutenberg WordPress den über die API bereitgestellten Inhalt verarbeiten wird, da zukünftige Basisinhalte stärker vorgeprägt sein werden als heute. Unserer Meinung nach wird es dadurch (etwas) anspruchsvoller, WordPress als universellen Content-Hub für verschiedene Wiedergabe-Clients zu verwenden.