Contract-first-APIs: eine OpenAPI-Datei für Go und Flutter

AppJoy Einblicke

Contract-first-APIs: eine OpenAPI-Datei für Go und Flutter

Bei WhatDaFit, HoldMyBeer und Grifas wird die API einmal aufgeschrieben, in einer OpenAPI-Datei namens swagger.yml. Der Go-Server und der Dart-Client werden beide daraus generiert. So läuft der Ablauf, und deshalb spart er bei jeder Änderung Zeit. Außerdem können ein App-Team und ein Backend-Team, auch bei verschiedenen Firmen, parallel arbeiten.

· Von Tobias Wimmer, AppJoy

Der Ablauf

  • Endpunkte, Request-Bodies, Antworten und Fehler in swagger.yml beschreiben.
  • Einen Befehl ausführen. go-swagger erzeugt die Go-Server-Stubs und Modelle, openapi-generator den Dart-Client mit dio und built_value.
  • Die Handler in Go auf Basis von GORM und PostgreSQL implementieren. Die Flutter-App ruft typisierte Dart-Methoden auf statt handgeschriebenem HTTP-Code.

Warum sich das lohnt

  • Backend und App laufen nicht auseinander: Ein geändertes Feld ist auf beiden Seiten ein Compile-Fehler und kein Bug in Produktion.
  • Weniger Boilerplate: Serialisierung, Validierung und Routing werden generiert.
  • Die Spezifikation dient zugleich als Dokumentation für dich und für jeden weiteren Entwickler, der später dazukommt.
  • Der Client ist austauschbar: Eine zweite App, ein Web-Client oder eine Partner-Integration kann denselben Vertrag nutzen.

Wenn Client und Server von verschiedenen Teams kommen

Der Ansatz lohnt sich am meisten, wenn App und Backend von verschiedenen Parteien gebaut werden, zum Beispiel die App von AppJoy und das Backend vom Kunden oder einem anderen Anbieter. Beide Seiten einigen sich zuerst auf die OpenAPI-Spezifikation, und sie wird zum Vertrag zwischen ihnen.

Einige dich so früh wie möglich auf die Spezifikation, idealerweise in der ersten Woche, und behandle Änderungen daran wie Vertragsänderungen: Beide Seiten prüfen sie, bevor sie übernommen werden.

  • Parallel arbeiten: Das App-Team wartet nicht auf das Backend. Beide starten am ersten Tag von derselben Spezifikation.
  • Endpunkte mocken: Ein Mock-Server, zum Beispiel aus der Spezifikation generiert, beantwortet Anfragen mit den dort definierten Beispielantworten. Die App kann gegen realistische Daten gebaut und getestet werden, bevor das echte Backend existiert.
  • Am Ende zusammenstecken: Ist das Backend fertig, wechselt die App vom Mock auf den echten Server, oft durch Ändern einer einzigen Basis-URL. Haben sich beide Seiten an die Spezifikation gehalten, funktioniert alles wie zuvor.
  • Weniger Missverständnisse: Feldnamen, Typen, Fehlerfälle und Authentifizierung sind festgehalten, es gibt weniger Rückfragen zwischen den Anbietern.
  • Sichtbare Änderungen: Eine Änderung der Spezifikation erscheint als Diff, den beide Seiten prüfen können, bevor etwas bricht.

Deployment

Der Go-Server kompiliert zu einer einzigen Binärdatei. Wir deployen sie auf einen Linux-Server, wo sie als Systemdienst neben PostgreSQL läuft. Für ein typisches MVP gibt es keine Container-Orchestrierung zu pflegen.

Häufige Fragen

Was ist Contract-first-API-Entwicklung?

Man schreibt zuerst die API-Spezifikation, zum Beispiel in OpenAPI, und generiert daraus Code, statt erst Code zu schreiben und danach zu dokumentieren.

Warum Go für das Backend?

Go ist schnell, als eine Binärdatei einfach zu deployen und leicht zu warten, das passt zu MVPs, die wachsen sollen.

Kann die App gebaut werden, bevor das Backend existiert?

Ja. Mit einer vereinbarten OpenAPI-Spezifikation lassen sich die Endpunkte aus den Beispielantworten der Spezifikation mocken. Die App wird gegen den Mock gebaut und getestet und am Ende an das echte Backend angeschlossen.

Was, wenn das Backend vom Kunden oder einem anderen Anbieter gebaut wird?

Vereinbare die OpenAPI-Spezifikation zu Beginn gemeinsam. Dann arbeiten beide Teams parallel gegen denselben Vertrag und integrieren, wenn beide fertig sind, mit deutlich weniger Überraschungen als ohne Spezifikation.

Funktioniert das mit einem bestehenden Backend?

Ja. Hat dein Backend eine OpenAPI-Beschreibung oder kann sie bekommen, generieren wir daraus den Flutter-Client. Die caberQU-App spricht zum Beispiel mit einer PHP-API, die der Kunde selbst betreibt.

Siehe auch: Flutter-Entwickler für App-Entwicklung in Österreich · Flutter vs. React Native vs. nativ: was du 2026 wählen solltest

Fallstudien: WhatDaFit · HoldMyBeer · Grifas

Erzähl uns von deiner Idee

Beschreibe dein Projekt in wenigen Sätzen. Du erhältst eine Schätzung auf Basis deiner Idee.

Zeit für deine eigene App?

Kostenloses Erstgespräch vereinbaren

Die Agentur für App- & Webentwicklung.

© 2026 AppJoy e.U. Alle Rechte vorbehalten.