Wenn eine Institution beschließt, eine mobile App zu entwickeln, dreht sich die erste Frage selten um die App selbst. Es geht darum, woher der Content stammen wird. Kursverzeichnisse, Ankündigungen, Profile von Lehrenden, Veranstaltungslisten, Nachrichten — dieser Content liegt bereits in einem Content-Management-System, und die App benötigt einen zuverlässigen Weg, um darauf zuzugreifen. Genau hier kommt ein API-First-Ansatz für Drupal ins Spiel: Statt die mobile App als separates Projekt mit einem eigenen Content-Speicher zu behandeln, wird Drupal zum einzigen Backend, das die Website, die App und jeden zukünftigen Kanal über einen konsistenten Satz von APIs bedient.
Dieser Artikel erklärt, wie man eine mobile App auf Basis von Drupal mit einer API-First-Architektur aufbaut. Wir klären den Unterschied zwischen „API-first" und „headless", betrachten, warum sich dieses Modell so gut für mobile Anwendungen eignet, gehen die API- und Authentifizierungsebenen durch, behandeln die mobilspezifischen Aspekte, die die meisten Leitfäden auslassen, und stellen einen klaren Rahmen für die Entscheidung auf, wie weit die Entkopplung gehen sollte.
API-First vs. Headless: Die Verwirrung auflösen
API-First vs. Headless: Die Verwirrung auflösen
Diese beiden Begriffe werden oft synonym verwendet, beschreiben jedoch unterschiedliche Dinge, und das Verständnis dieser Unterscheidung prägt, wie man das Projekt plant.
Headless beschreibt eine Architektur: Das Frontend (das, was der Nutzer sieht) wird vom Backend (wo der Content liegt) getrennt, und die beiden kommunizieren über eine API. In einem Headless-Setup rendert Drupal die Seiten nicht mehr selbst, sondern übergibt rohen Content an eine separate Frontend-Anwendung.
API-first beschreibt eine Designphilosophie: Der Content wird von Anfang an so modelliert und als APIs bereitgestellt, dass er jederzeit beliebig viele Kanäle gleichzeitig speisen kann — eine Website, eine iOS-App, eine Android-App, eine Smartwatch, einen Kiosk, einen Sprachassistenten. Bei Headless geht es darum, ein Frontend zu trennen; bei API-first geht es darum, für alle bereit zu sein. Eine mobile App ist oft der Auslöser dafür, API-first zu gehen, doch der eigentliche Gewinn besteht darin, dass dasselbe Backend jeden Kanal bedienen kann, den die Institution später hinzufügt, ohne die Content-Ebene jedes Mal neu aufzubauen.
Drupal eignet sich für beides gut, weil seine API-Fähigkeiten Teil des Cores sind und kein nachträgliches Add-on. Seit Drupal 8, weiterentwickelt über Drupal 9, 10 und 11, liefert die Plattform eine Web-Services-Ebene mit, die strukturierten Content ohne individuellen Code in API-Antworten umwandelt. Das ist das Fundament, auf dem alles Weitere in diesem Artikel aufbaut.
Warum API-first die richtige Grundlage für eine mobile App ist
Die Wahl eines API-first-Drupal-Backends für eine mobile App bringt Vorteile mit sich, die sich über die gesamte Lebensdauer des Projekts zeigen, nicht nur beim Launch.
- Eine Content-Quelle, viele Kanäle: Dieselbe Ankündigung, derselbe Kurs oder dasselbe Profil wird einmal in Drupal eingegeben und gleichzeitig an die Website, die mobile App und jeden anderen Kanal ausgeliefert. Redakteure pflegen den Content nicht doppelt, und die App gerät nie außer Sync mit der Website.
- Strukturierter Content, bereit für jede Oberfläche: Da Drupal Content als strukturierte Daten speichert und nicht als gerenderte Seiten, lässt sich dieser Content sauber auf eine mobile Oberfläche übertragen. Ein Kurs ist kein HTML-Block — er ist ein Satz von Feldern (Titel, Credits, Lehrperson, Zeitplan), die die App nach Bedarf anordnen kann.
- Unabhängige Entwicklung von Frontend und Backend: Das App-Team kann eine neue Version ausliefern, ohne das Backend anzufassen, und das Content-Team kann das Backend umstrukturieren, ohne die App zu beschädigen, solange der API-Vertrag eingehalten wird. Upgrades auf der einen Seite erzwingen keinen Neubau auf der anderen.
- Eine zukunftssichere Investition: Wenn der nächste Kanal auftaucht — eine neue App, ein Campus-Anzeigesystem, eine Integration mit einer anderen Plattform — ist der Content bereits bereitgestellt und wartet nur darauf. Die Institution baut ein neues Frontend, kein neues Backend.
- Content-Management auf Enterprise-Niveau hinter der App: Die App erbt die redaktionellen Workflows, granularen Berechtigungen, die mehrsprachige Unterstützung und die Medienverwaltung von Drupal — Fähigkeiten, die ein eigens gebautes mobiles Backend von Grund auf neu erfinden müsste.
Die API-Ebene: JSON:API, REST und GraphQL
Drupal kann Content über drei zentrale Spezifikationen bereitstellen. Es handelt sich weniger um konkurrierende als um unterschiedliche Werkzeuge, und die richtige Wahl hängt von den Anforderungen der App ab.
| Spezifikation | Was sie ist | Am besten geeignet für |
|---|---|---|
| JSON:API | Eine standardisierte Spezifikation, im Drupal Core ohne jegliche Konfiguration aktivierbar. Stellt jede Content-Entität automatisch als sauber strukturierten Endpunkt bereit. | Die Standardwahl für die meisten mobilen Apps — konsistent, vorhersehbar, ohne Einrichtungsaufwand. |
| REST (RESTful Web Services) | Der klassische Ansatz, ebenfalls im Core enthalten. Endpunkte werden pro Ressource mit mehr manueller Kontrolle konfiguriert. | Einfache Integrationen oder wenn eine bestimmte, individuelle Endpunktform benötigt wird. |
| GraphQL | Eine Abfragesprache (über ein Contributed-Modul), mit der der Client genau die gewünschten Felder in einem einzigen Aufruf anfordern kann. | Komplexe Apps, die Anfragen minimieren und präzise Datensätze abrufen müssen. |
Für die meisten mobilen Projekte ist JSON:API der natürliche Ausgangspunkt. Es ist Teil des Cores, erfordert keine Konfiguration zur Aktivierung und folgt einer strikten Spezifikation, was bedeutet, dass der mobile Entwickler genau weiß, wie die Antworten aussehen werden. Seine Struktur handhabt zudem Beziehungen zwischen Inhalten — ein Kurs und seine Lehrperson, eine Veranstaltung und ihr Veranstaltungsort — auf vorhersehbare Weise, was in institutionellen Apps häufig gebraucht wird. GraphQL wird attraktiv, wenn ein App-Bildschirm viele verschiedene Datenstücke auf einmal abrufen muss und man mehrere Roundtrips vermeiden möchte; der Kompromiss besteht in zusätzlichem Einrichtungsaufwand und Komplexität. Als allgemeine Regel gilt: Beginnen Sie mit JSON:API und wechseln Sie nur dann zu GraphQL, wenn ein konkreter Performance-Bedarf dies rechtfertigt.
Authentifizierung: Warum mobile Apps sich nicht auf Cookies verlassen können
Authentifizierung ist die erste echte technische Hürde bei einem entkoppelten mobilen Aufbau, und sie überrascht viele Teams. Eine klassische Drupal-Website authentifiziert Nutzer über Session-Cookies, die vom Browser verwaltet werden. Eine native mobile App hat weder einen Browser noch einen Cookie-Speicher, sodass dieser Mechanismus schlicht nicht greift. Die App muss sich auf andere Weise authentifizieren.
Die Standardlösung ist die tokenbasierte Authentifizierung. Der Nutzer gibt seine Zugangsdaten einmal ein; die App sendet sie an Drupal; Drupal überprüft sie und gibt ein Token zurück; und die App speichert dieses Token und hängt es an jede weitere Anfrage an. Zwei Ansätze dominieren:
- OAuth 2.0 (Simple-OAuth-Modul): der empfohlene Ansatz für die meisten entkoppelten Apps. Es stellt Zugriffs- und Refresh-Token aus, unterstützt moderne Abläufe einschließlich PKCE für öffentliche Clients wie mobile Apps, und lässt sich sauber mit zentralen Identitätssystemen integrieren. Dies ist der Weg, den die meisten institutionellen Projekte wählen.
- JWT (JSON Web Token): eine leichtgewichtige Alternative, bei der das Token selbst die Identität des Nutzers trägt. Es ist einfach und zustandslos und eignet sich gut für unkomplizierte Apps ohne komplexe Autorisierungsanforderungen.
Für Institutionen, die bereits Single Sign-on betreiben, kann die OAuth-Ebene die App mit demselben zentralen Identity Provider verbinden, der überall sonst genutzt wird, sodass sich Studierende und Mitarbeitende mit ihren bereits vorhandenen Zugangsdaten in der App anmelden. Es ist wichtig, die Authentifizierung frühzeitig richtig aufzusetzen — es ist weitaus schwieriger, einen sicheren Token-Ablauf nachträglich in eine App einzubauen, die auf einer einfacheren Annahme aufgebaut wurde, als ihn von Anfang an entsprechend zu gestalten.
Die mobilspezifische Ebene: Offline, Push und Medien
Die meisten Leitfäden zu entkoppeltem Drupal enden bei API und Authentifizierung. Doch eine mobile App läuft auf einem Gerät mit unterbrochener Konnektivität, begrenzter Bandbreite und einem eigenen Benachrichtigungssystem, und diese Realitäten erfordern eine Planung, die eine Website nie verlangt.
- Offline-Zugriff und Caching: Ein mobiler Nutzer erwartet, dass die App im Zug oder im Hörsaal bei schlechtem Empfang funktioniert. Die App sollte Content lokal cachen und mit Drupal synchronisieren, sobald die Verbindung wiederhergestellt ist. Die API-Ebene unterstützt dies, indem sie cachefähige, strukturierte Antworten liefert, die die App speichern und aktualisieren kann — die Caching- und Synchronisationslogik liegt jedoch auf Seiten der App und muss bewusst entworfen werden.
- Push-Benachrichtigungen: Benachrichtigungen sind einer der Hauptgründe, warum Institutionen überhaupt eine native App wollen — eine neue Note, eine Stundenplanänderung, ein Notfallalarm. Drupal fungiert als Auslöserquelle: Wenn Content veröffentlicht wird oder ein Ereignis eintritt, ruft Drupal einen Push-Dienst (wie Firebase Cloud Messaging) auf, der die Benachrichtigung an die Geräte ausliefert. Der Content und der Auslöser liegen in Drupal; die Auslieferung übernimmt die Benachrichtigungsinfrastruktur der Plattform.
- Medien- und Bildoptimierung: Mobile Bildschirme und mobile Datentarife machen die Bildbehandlung entscheidend. Das Mediensystem und die Bildstile von Drupal können passend dimensionierte Versionen jedes Bildes erzeugen, sodass die App eine für Mobilgeräte optimierte Version anfordert, statt eine für den Desktop bestimmte Datei in voller Auflösung herunterzuladen. Das wirkt sich direkt auf Ladezeiten und Datenverbrauch aus.
- Progressive Web Apps als Mittelweg: Nicht jede Institution braucht eine vollständige native App. Eine Progressive Web App (PWA) bietet einen Großteil des nativen Erlebnisses — Installation auf dem Homescreen, Offline-Unterstützung, Push-Benachrichtigungen — aus einer einzigen Web-Codebasis, und Drupal unterstützt dies über ein dediziertes PWA-Modul. Für viele Hochschulen ist eine PWA ein kostengünstigerer Weg zu einem app-ähnlichen Erlebnis, bevor man sich für native Entwicklung entscheidet.
Entkoppelt, progressiv entkoppelt oder gekoppelt?
Vollständig zu entkoppeln ist ein echtes Bekenntnis, und es ist nicht automatisch die richtige Antwort. Ehrlich zu sein, wann man nicht entkoppeln sollte, ist ebenso wichtig wie zu wissen, wann man es sollte. Es gibt drei grundlegende Modelle:
- Gekoppelt (klassisches Drupal): Drupal übernimmt sowohl Content als auch Darstellung. Das bleibt die richtige Wahl für eine Standard-Website ohne separate App oder Frontend-Framework. Gibt es keine mobile App und keinen zweiten Kanal, fügt die Entkopplung Kosten hinzu, ohne einen Nutzen zu bringen.
- Progressiv entkoppelt: Drupal rendert den Großteil der Seite, übergibt aber bestimmte interaktive Komponenten an ein JavaScript-Framework. Das hält die redaktionellen und Layout-Werkzeuge von Drupal intakt und fügt gleichzeitig reichhaltige Interaktivität dort hinzu, wo sie gebraucht wird — ein sinnvoller Mittelweg für eine Website, die etwas app-ähnliches Verhalten möchte, ohne einen vollständigen Neuaufbau.
- Vollständig entkoppelt: Drupal ist rein ein Backend, und ein oder mehrere unabhängige Frontends (eine mobile App, eine separate Web-App) konsumieren dessen APIs. Dies ist das Modell, das eine native mobile App erfordert, und es ist die richtige Wahl, wenn Sie tatsächlich mehrere Kanäle bedienen — es bedeutet jedoch, dass das Frontend-Team Verantwortlichkeiten übernimmt, die früher Drupal übernommen hat, von Routing über SEO bis Barrierefreiheit.
Der entscheidende Faktor ist, wie viele Frontends der Content bedienen muss. Eine einzelne Website bleibt am besten gekoppelt. Eine Website plus eine native mobile App weist auf eine entkoppelte oder hybride Architektur hin. Der Fehler besteht darin, um der Entkopplung willen zu entkoppeln — ein vollständig entkoppelter Aufbau für ein Projekt, das eigentlich nur eine einzige Website benötigte, fügt Komplexität und Kosten hinzu, die die Institution über Jahre hinweg pflegen muss. Die umfassenderen Plattform-Abwägungen haben wir in unserem Vergleich von Drupal, WordPress und Joomla betrachtet.
Front-End-Optionen: React Native, Flutter und Native
Da ein API-first-Drupal-Backend frontend-agnostisch ist, funktioniert es mit jeder mobilen Technologie, die das Team bevorzugt. Die API kümmert sich nicht darum, was sie konsumiert, was die Entscheidung freigibt, sich an den Anforderungen der App und den Fähigkeiten des Teams zu orientieren.
- React Native: eine beliebte plattformübergreifende Wahl, die iOS- und Android-Apps aus einer einzigen JavaScript-Codebasis baut. Es harmoniert natürlich mit Drupals JSON:API, und dahinter steht ein großes Ökosystem und ein umfangreicher Talentpool.
- Flutter: Googles plattformübergreifendes Framework, das die Sprache Dart nutzt und für flüssige Performance und ein konsistentes Erscheinungsbild über Plattformen hinweg bekannt ist. Es konsumiert Drupals APIs genauso bereitwillig wie jeder andere Client.
- Native (Swift / Kotlin): die separate Entwicklung für iOS (Swift) und Android (Kotlin) bietet die tiefste Plattformintegration und beste Performance, bei höheren Entwicklungskosten. Das Drupal-Backend bedient alle identisch.
Der entscheidende Punkt ist, dass dies eine wirklich offene Wahl ist. Da das Backend Standard-APIs bereitstellt, ist die Institution an keine bestimmte Frontend-Technologie gebunden und kann diese sogar später ändern, ohne die Content-Ebene anzufassen.
Häufige Fallstricke bei einem API-first-Mobile-Projekt
- Entkoppeln, obwohl es nicht nötig war: der häufigste Fehler. Gibt es keinen zweiten Kanal, ist eine gekoppelte Drupal-Website einfacher, günstiger und leichter zu pflegen. Entkoppeln Sie, weil Sie eine mobile App haben — nicht, weil es modern klingt.
- Authentifizierung zu spät angehen: tokenbasierte Authentifizierung prägt die gesamte App-Architektur. Entwerfen Sie den OAuth- oder JWT-Ablauf zu Beginn, nicht erst, nachdem die App bereits um Session-Annahmen herum gebaut wurde.
- Vergessen, was das Frontend nun übernimmt: In einem entkoppelten Aufbau übernimmt das Frontend-Team Routing, SEO, Barrierefreiheit und Metadaten — Dinge, die Drupal zuvor automatisch erledigt hat. Diese müssen explizit eingeplant werden, sonst geschehen sie einfach nicht.
- Die mobilspezifische Ebene ignorieren: Offline-Verhalten, Push und Bildoptimierung sind kein Nachgedanke. Eine App, die schlechte Konnektivität nicht bewältigt oder Desktop-große Bilder ausliefert, wirkt kaputt, egal wie sauber die API ist.
- Zu viele Daten abrufen: Mehr anzufordern, als ein Bildschirm benötigt, verschwendet Bandbreite und Akku. Nutzen Sie die Feldfilterung von JSON:API oder GraphQL, wo es passt, um nur das Nötige abzurufen.
- Die API als Nachgedanken behandeln: Der ganze Sinn von API-first besteht darin, das Content-Modell und seine API von Anfang an bewusst zu gestalten. Eine API nachträglich auf eine Content-Struktur aufzusetzen, die nie für externen Zugriff gedacht war, führt zu unhandlichen, ineffizienten Endpunkten.
Gut durchdacht, verschafft ein API-first-Drupal-Backend einer Institution eine einzige, sauber strukturierte Content-Quelle, die eine Website, eine mobile App und alles, was als Nächstes kommt, antreiben kann — ohne Content zu duplizieren oder das Fundament jedes Mal neu aufzubauen. Es passt natürlich zu Organisationen, die bereits auf Drupals strukturierten Content setzen und ihn auf neue Kanäle ausweiten möchten. Um die breitere Palette dessen zu sehen, was die Plattform unterstützt, bietet unsere Übersicht darüber, was man mit Drupal machen kann, eine Übersicht der umliegenden Szenarien, und der Leitfaden was ist Drupal behandelt die Grundlagen seines strukturierten Content-Modells.
Häufig gestellte Fragen zu Drupal und mobilen Apps
Ist Drupal ein gutes Backend für eine mobile App?
Ja, insbesondere wenn die App Content mit einer Website oder anderen Kanälen teilen muss. Die API-first-Fähigkeiten von Drupal sind fest im Core verankert, sodass es strukturierten Content über Standard-APIs an iOS, Android oder jedes andere Frontend ausliefern kann, ohne individuelle Infrastruktur aufbauen zu müssen. Es passt besonders gut, wenn die App von einem Content-Management auf Enterprise-Niveau im Hintergrund profitiert — redaktionelle Workflows, granulare Berechtigungen, mehrsprachiger Content und eine robuste Medienverwaltung. Für eine eigenständige App ohne gemeinsam genutzten Content und ohne Content-Management-Bedarf kann ein schlankeres Backend ausreichen; das Argument für Drupal wird mit zunehmender Content-Komplexität stärker.
Muss ich PHP kennen, um eine mobile App auf Drupal aufzubauen?
Nein, nicht für die App selbst. In einer entkoppelten Architektur wird die mobile App mit mobilen Technologien gebaut — React Native, Flutter, Swift oder Kotlin — und kommuniziert mit Drupal ausschließlich über APIs. Die mobilen Entwickler arbeiten in ihrer eigenen Sprache und kommen nie mit PHP in Berührung. PHP-Kenntnisse sind nur auf der Drupal-Seite relevant, für die Konfiguration des Backends, die Content-Modellierung und die Anpassung der API-Ebene — Aufgaben, die typischerweise vom Drupal-Team und nicht vom App-Team übernommen werden.
JSON:API oder GraphQL für eine mobile App?
Beginnen Sie mit JSON:API. Es ist im Drupal Core ohne jegliche Konfiguration aktiviert, folgt einer strikten und vorhersehbaren Spezifikation und deckt die Bedürfnisse der meisten mobilen Apps bereits ab Werk ab. GraphQL lohnt sich, wenn App-Bildschirme viele unterschiedliche Datenstücke in einer einzigen Anfrage abrufen müssen und man Roundtrips minimieren möchte — es bringt jedoch über ein Contributed-Modul zusätzlichen Einrichtungsaufwand und Komplexität mit sich. Der praktische Weg lautet: standardmäßig JSON:API, GraphQL dann, wenn ein konkreter Performance-Bedarf den zusätzlichen Aufwand rechtfertigt.
Kann ein Drupal-Backend gleichzeitig eine Website und eine mobile App bedienen?
Ja, und das ist einer der stärksten Gründe, sich für einen API-first-Ansatz zu entscheiden. Ein einziges Drupal-Backend kann gleichzeitig die Website und die mobile App aus demselben Content bedienen. Eine Ankündigung oder ein Kurs, die einmal eingegeben werden, erscheinen auf beiden Kanälen, immer synchron, ohne doppelten Aufwand. Genau das bedeutet „eine Content-Quelle, viele Kanäle" in der Praxis, und das ist der Kernvorteil, von Anfang an API-first zu bauen.