REST oder GraphQL: was ich nach Projekten in beiden Welten ehrlich denke
Ich habe in den letzten Jahren in Projekten mit REST und in Projekten mit GraphQL gearbeitet. Beide Lager haben starke Befürworter, und beide Lager haben recht, je nach Kontext. Ein paar Beobachtungen, die ich konsistent mache.
Wo REST einfach besser bleibt
Bei Schnittstellen mit klar abgegrenzten Ressourcen, die einzeln abgefragt und verändert werden, ist REST nach wie vor der ruhigere Weg. Caching auf HTTP-Ebene, vorhersehbare URLs, einfache Tools für Tests und Monitoring, breite Vertrautheit in Teams.
Vor allem: REST hat eine flache Lernkurve. Ein Backend-Entwickler ohne GraphQL-Erfahrung baut innerhalb eines Tages eine produktiv nutzbare REST-Schnittstelle. Diese Vertrautheit ist in einem Mittelstands-Team mehr wert als jeder theoretische Vorteil.
Wo GraphQL wirklich Vorteile bringt
Bei Frontends, die unterschiedliche Sichten auf dieselben Daten brauchen, ist GraphQL stark. Statt drei verschiedene REST-Endpunkte zu pflegen oder einen mit zu vielen Feldern zu liefern, fragt das Frontend genau das ab, was es braucht.
Bei mobilen Anwendungen, in denen jeder Byte zählt, kann das den Unterschied machen. Auch bei Dashboards, die viele heterogene Daten anzeigen, ist GraphQL angenehmer als ein REST-Sammelsurium.
Was in der Praxis oft passiert
In vielen Projekten wird GraphQL eingeführt, weil es modern wirkt, und nicht, weil ein konkretes Problem gelöst wird. Das Ergebnis: ein Schema, das niemand pflegt, Resolver, die nicht performant sind, N+1-Queries, die ohne Tooling unsichtbar bleiben.
GraphQL ist mächtig und vergibt deutlich weniger Fehler als REST. Wer es einsetzt, übernimmt eine Komplexität, die in den meisten Mittelstands-Projekten nicht durch echten Mehrwert gedeckt ist.
Mein Fazit nach beidem
Wenn die Aufgabe REST passt, nehme ich REST. Es ist nicht schlechter, es ist verlässlicher. GraphQL nutze ich, wenn das Frontend wirklich variable Datensichten braucht und das Team die Tooling-Disziplin mitbringt.
Die ehrliche Wahrheit ist unbequem: Die meisten Schnittstellen brauchen nicht GraphQL. Sie brauchen jemanden, der die REST-Endpunkte sauber entwirft.
Schluss
Wer überlegt, in welche Richtung das eigene Projekt gehen soll, profitiert von einer ehrlichen Bestandsaufnahme. Wer Sparring sucht, kann mich ansprechen.