In der Digitalisierungswerkstatt – einer unserer interdisziplinären Circle – evaluieren wir neue Technologien und Methoden, um innovative Lösungen zu entwickeln und moderne Softwareansätze praxisnah zu testen. Im Rahmen eines aktuellen Projekts haben wir eine Webanwendung mit Backend und Datenbank konzipiert, bei der neben klassischen CRUD-Operationen auch komplexe statistische Auswertungen im Frontend ermöglicht werden sollten.
Die Digitalisierungswerkstatt setzt dabei gezielt auf eine Greenfield-Umgebung, um neue Technologien effizient auszuprobieren und deren Potenziale für den realen Einsatz zu bewerten. Für dieses Projekt fiel die Wahl auf einen modernen Tech-Stack: Das Frontend wurde mit React und Material UI (MUI) umgesetzt, das Backend in Kotlin entwickelt und PostgreSQL als relationale Datenbank eingesetzt.
PostgreSQL überzeugte dabei nicht nur durch seine Stabilität und Verbreitung, sondern auch durch die Möglichkeit, strukturierte Daten nativ im JSON-Format zu speichern und performant zu durchsuchen. Das verschafft uns zusätzliche Flexibilität, insbesondere bei sich wandelnden Datenmodellen.
Besonders zentral war die Entscheidung für GraphQL gegenüber REST, um eine flexible Architektur mit einfacher Erweiterbarkeit und einer Public API für Drittsysteme zu schaffen. Mit dem Schema-First-Ansatz wollten wir eine Grundlage schaffen, um Änderungen an der Schnittstelle zentral zu verwalten und eine automatische Codegenerierung für Frontend und Backend zu ermöglichen.
Im folgenden Beitrag werfen wir einen genaueren Blick auf die Vorteile von GraphQL und Kotlin – insbesondere im Vergleich zu REST und Java – und erläutern, wie wir die Herausforderungen bei der Umsetzung des Schema-First-Ansatzes gelöst haben.
Warum Kotlin eine moderne Alternative zu Java ist
Bei der technischen Umsetzung unserer Anwendung haben wir uns bewusst für Technologien entschieden, die die moderne Softwareentwicklung erleichtern und gleichzeitig ein hohes Maß an Stabilität und Skalierbarkeit bieten. Die Wahl der Programmiersprache für das Backend fiel daher auf Kotlin – eine moderne, statisch typisierte Sprache, die speziell für die Anforderungen zeitgemäßer Softwareentwicklung konzipiert wurde.
Die von JetBrains entwickelte Sprache bietet im Vergleich zu Java zahlreiche Vorteile, ohne dabei auf die bestehende Java-Ökosystem-Kompatibilität zu verzichten. Ein entscheidender Pluspunkt ist die Null-Sicherheit: Kotlin verhindert viele typische Laufzeitfehler, wie etwa Null-Pointer Exceptions, bereits zur Compile-Zeit. Darüber hinaus überzeugt Kotlin durch eine prägnante und gut lesbare Syntax, die sich insbesondere bei der Entwicklung von Webanwendungen mit Spring Boot positiv bemerkbar macht.
Wichtige Vorteile von Kotlin im Überblick:
- Kompakte Syntax: Weniger Boilerplate-Code, schnellere Umsetzung
- Lesbarkeit: Implizite Typdefinitionen vereinfachen den Code
- Named Arguments: Das Builder-Pattern wird oft überflüssig
- Spring-Boot-Unterstützung: Ideal für moderne Web- und API-Anwendungen
- Java-Kompatibilität: Bestehende Libraries und Codebasen bleiben nutzbar
Diese Kombination aus Modernität, Sicherheit und Kompatibilität macht Kotlin besonders geeignet für Backend-Systeme, die – wie in unserem Projekt – in Kombination mit GraphQL eine dynamische Schnittstellenstruktur benötigen.
GraphQL – mehr Flexibilität für moderne APIs
Neben der Wahl der Programmiersprache spielte auch die Architektur der API eine entscheidende Rolle – insbesondere im Hinblick auf Flexibilität, Wartbarkeit und Effizienz. Während REST lange Zeit als Standard für Web-APIs galt, haben wir uns in diesem Projekt bewusst für GraphQL entschieden. Die Abfragesprache bietet eine hohe Flexibilität und ermöglicht es dem Client, genau die Daten abzufragen, die tatsächlich benötigt werden. Das minimiert nicht nur die Netzwerklast, sondern erhöht auch die Effizienz der gesamten Datenverarbeitung.
GraphQL bietet gegenüber REST mehrere Vorteile:
- Effiziente Datenübertragung: Nur relevante Felder werden abgefragt
- Aggregierte Datenquellen: Daten aus verschiedenen Quellen lassen sich zusammenfassen
- Ein einziger Endpunkt: Zentrale API-Struktur für unterschiedlichste Abfragen
- Echtzeitfähigkeit: Unterstützung für WebSockets und Live-Updates
Trotz der vielen Stärken bringt GraphQL auch einige Herausforderungen mit sich:
- Komplexere Serverlogik: Schemata und Resolver müssen sauber gepflegt werden
- Leistungsmanagement: Schutzmechanismen gegen zu komplexe oder verschachtelte Abfragen sind notwendig
- Nicht für alle APIs geeignet: Für einfache, ressourcenbasierte Use Cases kann REST nach wie vor effizienter sein
Um die Vorteile von GraphQL optimal auszuschöpfen, ist eine saubere Struktur der API besonders wichtig – hier setzt der Schema-First-Ansatz an.
Schema-First – Strukturierte API-Entwicklung mit zentralem Modell
Ein Schema-First-Ansatz bedeutet, dass die gesamte API zunächst als GraphQL-Schema definiert wird. Dieses Schema dient als gemeinsame Grundlage für alle Entwicklungsteams und ermöglicht eine parallele Entwicklung von Frontend und Backend. Gerade bei komplexeren Anwendungen sorgt das für klare Verantwortlichkeiten, reduzierte Abstimmungsaufwände und eine konsistente Umsetzung.
In der JavaScript-Welt existieren zahlreiche Tools zur automatischen Codegenerierung aus einem solchen Schema – für Kotlin war es dagegen notwendig, passende Werkzeuge gezielt auszuwählen und zu kombinieren.
Grundlage dieses Ansatzes ist die sogenannte SDL (Schema Definition Language) – eine deklarative Beschreibungssprache für GraphQL-Schnittstellen. In SDL werden Typen, Abfragen und Mutationen formal definiert und dienen anschließend als gemeinsame Referenz für die Codegenerierung in Frontend und Backend. Insbesondere im Schema-First-Ansatz ist SDL der zentrale Ausgangspunkt für eine konsistente API-Architektur.
Toolvergleich – Generatoren für Kotlin-basierte GraphQL-Projekte
Die folgende Übersicht zeigt eine Auswahl relevanter Codegeneratoren für Kotlin, die wir in unserem Projektkontext evaluiert haben. Die Auswahl erfolgte entlang der Anforderungen an Server- oder Client-Code, SDL-Kompatibilität und Framework-Integration:
| Name | Typ | Kompatibilität | Vorteile | Nachteile |
|---|---|---|---|---|
| Expedia Group GraphQL Kotlin Codegen | Server/Client | Spring Boot, Ktor, Apollo Federation | Schema-First-Ansatz mit SDL-Unterstützung, Generiert Data Classes, Resolver und Client-Code, Vollständige Integration mit Spring und Ktor | Keine automatische Generierung von komplexen Resolvern |
| Apollo Kotlin (ehem. Apollo Android) | Client | Android, Ktor, OkHttp | Echtzeit-Updates via Subscriptions, Caching und Normalisierung | Keine Server-Generierung |
| Netflix DGS (Domain Graph Service) | Server | Spring Boot | Integrierte Test-Tools (z. B. Mocking), SDL-first mit automatisiertem Schema-Export | Keine Client-Generierung |
| Kobby Gradle Plugin | Client | Client-seitig | Erzeugt type-sichere DSLs für komplexe Queries, Anpassbar via Schema-Direktiven | Beta-Status, Weniger Community-Unterstützung |
| graphql-java-codegen (kobylynskyi) | Server/Client | JVM (Java, Kotlin, Scala) | Unterstützt SDL und Introspection, Flexibles Mapping von Scalars | Fokus auf Java, Kotlin-Features begrenzt |
| GraphQL SPQR | Server | Spring, Quarkus | Code-first-Ansatz, Minimaler Boilerplate | Kein SDL-first-Support |
| The Guild Codegen | Client | JVM, JavaScript | Einfache Konfiguration für Enums und Input-Typen, Multiplattform-Unterstützung | Begrenzte Funktionalität |
| Karate API Testing (GraphQL-Unterstützung) | Testing | Testumgebungen | Automatische Generierung von Test-Code, Integriertes Mocking | Keine Produktiv-Code-Generierung |
Da derzeit kein Generator existiert, der sowohl Server- als auch Client-Code für Kotlin umfassend unterstützt, ist es in der Praxis oft notwendig, mehrere spezialisierte Tools zu kombinieren. So lassen sich individuelle Projektanforderungen – etwa Subscriptions, Typed Queries oder Federation – gezielt abdecken.
Codegenerierung von GraphQL zu Kotlin – Potenziale & Stolpersteine
Mit der Wahl des Schema-First-Ansatzes ging auch die Entscheidung einher, möglichst viel Code automatisiert zu generieren. Das bringt deutliche Vorteile – insbesondere im Hinblick auf Konsistenz und Typensicherheit – erfordert aber auch ein Umdenken im Entwicklungsprozess.
Typische Herausforderungen:
- Schema-Verwaltung: Zusätzliche Strukturen & Konventionen notwendig
- Fehlermanagement: Verbesserte Fehlerausgaben gegenüber Standardmeldungen wie
INTERNAL_ERROR - Framework-Kompatibilität: Nicht alle Bibliotheken sind vollständig Kotlin-tauglich
Ein zentrales Werkzeug war für uns der GraphQL Kotlin Codegen von Expedia Group. Er bietet eine stabile Integration mit Spring Boot und Ktor, unterstützt SDL vollständig und generiert sowohl Data Classes als auch Resolver. Die automatische Generierung komplexer Business-Resolver ist jedoch nach wie vor nur begrenzt möglich – hier sind weiterhin manuelle Eingriffe notwendig.
Die Codegenerierung aus einem zentralen Schema bietet eine starke Basis für skalierbare, wartbare Architekturen – gerade im Zusammenspiel mit Kotlin. Der initiale Mehraufwand für Tooling und Struktur zahlt sich im späteren Projektverlauf durch klare Schnittstellen, weniger Inkonsistenzen und höhere Geschwindigkeit bei Änderungen deutlich aus.
Fazit – moderne APIs effizient entwickeln
Die Kombination aus Kotlin und GraphQL bietet ein leistungsstarkes Fundament für die Entwicklung moderner, skalierbarer Webanwendungen. Kotlin überzeugt durch seine kompakte Syntax, hohe Typensicherheit und exzellente Integration in bestehende Java-Ökosysteme – ideal für die Backend-Entwicklung.
GraphQL wiederum eröffnet neue Möglichkeiten für flexible API-Architekturen und eine zielgerichtete Datenkommunikation – besonders in dynamischen Projektkontexten. Der Schema-First-Ansatz und eine durchdachte Codegenerierung ermöglichen es, technologische Komplexität effizient zu beherrschen.
Unser Projekt in der IT-Sonix-Digitalisierungswerkstatt zeigt: Mit der richtigen Kombination aus neuen Technologien entstehen Softwarelösungen, die sowohl kurzfristig performant als auch langfristig wartbar und ausbaufähig sind.