Wenn Ihr Team gerade eine API entwickelt, ist die Wahrscheinlichkeit groß, dass die Einführung von GraphQL im Raum steht. Wenn Sie als Entwickler Datenbanken (der nächsten Generation) abfragen möchten, ist es sehr wahrscheinlich, dass Sie Ihre Anfrage in GraphQL senden müssen. Die Query Language ist eine der angesagtesten Optionen, um die Suche nach Daten zu organisieren.

GraphQL wurde im Jahr 2012 von Facebook entwickelt - als prägnante und leistungsstarke Methode, um Datenstrukturen in seinem massiven Social Graph zu durchsuchen. Ab 2015 begann der Konzern, GraphQL offenzulegen - 2019 übergab er die Kontrolle an die gemeinnützige GraphQL Foundation. Inzwischen bauen diverse Unternehmen Datensuchdienste auf GraphQL auf.

Ist GraphQL also auch die richtige Wahl für Ihr nächstes Projekt? Um Ihnen diese Entscheidung zu erleichtern, haben wir fünf gute Gründe für und gegen GraphQL zusammengestellt.

5 Gründe für GraphQL

1. GraphQL ist kurz und bündig

Entwickler, die nach Daten suchen müssen, lieben die kompakte Form von GraphQL - vor allem diejenigen, die am Frontend arbeiten und User Interfaces kontinuierlich um neue Funktionen und Daten erweitern. Die Syntax bietet eine der einfachsten Möglichkeiten, um Antworten von komplexen, manchmal verschachtelten Datenstrukturen abzufragen. Das erleichtert es, mehr Daten abzufragen, ohne den Code neu schreiben zu müssen.

Der Abfragemechanismus von GraphQL ist außerdem so konzipiert, dass er einen Großteil der Komplexität herkömmlicher Abfragen ausblendet. Manche Entwickler kämpfen bei Datenbankabfragen mit inneren und äußeren Joins, andere sind es leid, drei oder vier Abfragen zu senden, um die Daten in drei oder vier verschiedenen Datenbanken auf der ganzen Welt zu finden. GraphQL verbirgt all diese Komplexität.

2. GraphQL entwickelt sich weiter

GraphQL ist noch relativ jung und wird fleißig weiterentwickelt. Das bedeutet auch, dass häufig neue Funktionen hinzukommen. Das GraphQL-Versionsprotokoll vom Oktober 2021 enthält beispielsweise mehr als 100 Änderungen und Erweiterungen.

3. GraphQL hat Power

Vor allem Entwickler, die einfach nur Daten aus einer API abrufen wollen, staunen regelmäßig über die Abfragemöglichkeiten, die GraphQL bietet. Wenige Tastenanschläge reichen aus, um eine Abfrage zu ändern. Die wahre Stärke von GraphQL liegt jedoch unter der Haube: Ein intelligentes Backend sorgt dafür, dass Informationen auf die bestmögliche Art und Weise beschafft werden. Optimierungsroutinen können eine Anfrage statisch analysieren und relativ genaue Vorhersagen treffen, die das Backend wiederum nutzen kann, um den schnellsten Weg zu wählen.

GraphQL kann auch feste Abfragen zusammenstellen und eine Liste zwischengespeicherter Objekte erstellen, um die Geschwindigkeit zu erhöhen.

4. Daten für die Menschen

Daten sind nur gut, wenn sie auch genutzt werden. Dazu müssen Sie zu den Menschen an der "Basis" gelangen. Deshalb konzentrieren sich Front-End-Entwickler darauf, schöne Schnittstellen für die breite Masse zu schaffen. Wenn GraphQL diesen Entwicklern das Leben leichter macht, können sie wiederum allen anderen das Leben leichter machen. Einen offenen und leicht zugänglichen Mechanismus zu schaffen, um Daten abzurufen, kann auch zu einer Renaissance der Datennutzung im gesamten Unternehmen führen.

5. Supergraphen als Brücke zwischen Ihren Backends

GraphQL-Liebhaber sprechen gerne davon, alle Daten eines Unternehmens in einem großen Supergraphen zusammenzufassen. Dazu nehmen sie verschiedene Legacy-Systeme und ergänzen einige neue Felder, um eine Single Source of Truth zu schaffen. Jedes Data-Warehousing-Team ist in der Lage, ein Portal zu erstellen, das sämtliche Perlen beinhaltet.

5 Gründe gegen GraphQL

1. Es macht Abfragen gefährlich einfach

Vielen Entwicklern kommt es gelegen, dass das GraphQL-Backend die Komplexität von Anfragen verbirgt. Dennoch sind dieselben Developer dann überrascht, wenn sich die Ergebnisausgabe um den Faktor fünf, zehn oder sogar hundert verlangsamt. Jede neue Abfrage fügt Joins zu Prozessen hinzu und schickt das Backend auf die Reise. Die Serverlast wächst - und die Datenbankadministratoren drehen am Rad.

Und es kommt noch schlimmer: Einige Cloud-Implementierungen werden nach Workloads abgerechnet. Eine umfassende Abfrage kann so am Ende des Monats in eine umfassende Cloud-Rechnung münden.

2. API-Versionierung ist verwirrend

Viele Teams sind zwar in der Lage, ihre GraphQL-APIs ständig zu verbessern und zu erweitern - aber nicht alle bewerkstelligen das auf elegante Art und Weise. Einige wollen "Null"-Antworten für Felder einschleusen, die verschwunden sind. Andere fügen Dummy-Daten ein. Manche ergänzen den Pfad um explizite Versions-Tags (etwa "/v3/data") und erstellen einen einzigen Baum mit verschiedenen Versionen in verschiedenen Zweigen. Die Entwickler, die die API betreiben, können sich damit konfrontiert sehen, dass sie Informationen hinzufügen, aber nicht entfernen können - und dass sie Anfragen nach Feldern unterstützen müssen, nur weil irgendjemand, irgendwo, noch danach fragt.

3. Macht kann gefährlich sein

Jeder liebt Macht, bis sie Kräfte freisetzt, die nicht mehr zu kontrollieren sind. Im Fall von GraphQL sieht das so aus, dass eine Abfrage viel zu viel Bandbreite, Rechenressourcen - oder beides - verschlingt. Aber es gibt noch andere Gefahren: Informationen, die eigentlich geheim gehalten werden sollen, könnten freigegeben werden - oder Aktualisierungen für Daten ausgelöst werden, die eigentlich unverändert bleiben sollen.

4. Kein Schema

Eine häufige Beschwerde von Entwicklern: Es gibt keine selbsterklärende Map oder ein Schema, das sie durch den GraphQL-Datenbaum führt. Die richtige Zeichenfolge ist vielleicht da, aber auf welchem Zweig? Zumindest eine relationale Datenbank ordnet alles in hübschen, rechteckigen Tabellen an, deren Spalten klar definiert und einigermaßen konsistent sind. Das mag eher an einer komplexen Graphen-Datenstruktur liegen als an der Sprache selbst, macht Entwicklern das Leben jedoch nicht leichter.

5. Supergraphen sehen nur einfach aus

Die Vision, einen Supergraphen zu erstellen, der alle Ihre Daten in einer großen Schnittstelle vereint, ist selten so einfach, wie sie klingt. Über die Details einer solchen Integration können sich ganze Datenteams über lange Zeiträume hinweg den Kopf zerbrechen. Entwickler beschweren sich zum Beispiel oft darüber, dass die Typsysteme der verschiedenen Zweige nicht übereinstimmen. Ein Zweig speichert vielleicht Daten im Textformat, während ein anderer einen numerischen Standard verwendet.

Wenn der Supergraph Daten vereinheitlicht, die in verschiedenen Ländern oder Kontinenten gespeichert sind, ist die Chance groß, dass Sie Zweige in verschiedenen Sprachen managen müssen. Es ist einfach, verschiedene Datenquellen so zusammenzuführen, dass sie wie eine einzige Schnittstelle aussehen - die Daten aber tatsächlich zu vereinheitlichen ist wesentlich komplexer.

GraphQL - ja oder nein?

Entwickler und Teams, die GraphQL in Erwägung ziehen, sollten bereit sein, sich die Zeit zu nehmen, um die Besonderheiten von GraphQL zu durchdringen. Es ist verlockend, GraphQL als eine einfache Lösung zu betrachten - das könnte sich allerdings in Form bodenloser Cloud-Rechnungen und Sicherheitskopfschmerzen rächen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.