GraphQL vs REST
Client + Server und
deren Vor- und Nachteile
Schwerpunkte:
- Was ist GraphQL?
- Vergleich: REST-API mit GraphQL (Pro / Contra)
- Was bietet PostGraphile
- Lösungsansätze / Techstacks (ASP.Net, REST, GraphQL)
- zu lösende Probleme + FAQ
- weiteres Vorgehen
Was ist GraphQL
-
GraphQL ist eine Abfragesprache, aber nicht wie SQL sondern eher zu verstehen als Anwendungsabfragesprache, die Anwendung definiert was wo benötigt wird
- folgt dem deklarativen Programmier-Paradigm (Imperative REST vs Deklarative GraphQL) how vs what
- Implementierung ist Programmiersprachunabhängig
- GraphQL-APIs verfügen über ein stark typisiertes Schema (in SDL geschrieben)
- Man kann mit einer einzigen Query Zugriff auf alle gewünschten Daten erhalten oder auch beliebige Businesslogik ansteuern
- Es gibt nur einen Endpunkt welcher meist über POST mit Queries (Abfragen), Mutations (Veränderungen) oder Subscriptions (Echtzeit) angesteuert werden kann
- Serverseitig findet man zu jedem abgefragten Feld eine Resolver-Funktion, welche beschreibt wie die Daten verarbeitet und geladen werden
3 verschiedene Arten von Architekturen
1. GraphQL-Server mit einer verbundenen Datenbank
GraphQL kümmert sich auch nicht um die Datenbank oder das Format, in dem die Daten gespeichert werden. Sie können eine SQL-Datenbank wie AWS Aurora oder eine NoSQL-Datenbank wie MongoDB verwenden.
3 verschiedene Arten von Architekturen
2. GraphQL-Schicht, die vorhandene Systeme integriert
Mit GraphQL kann die Komplexität vorhandener Systeme wie Mikrodienste, ältere Infrastrukturen oder APIs von Drittanbietern hinter einer einzigen GraphQL-Schnittstelle verborgen werden.
3 verschiedene Arten von Architekturen
3. Hybridansatz mit verbundener Datenbank und Integration des vorhandenen Systems
Beide Ansätze können auch kombiniert werden, und der GraphQL-Server kann Daten aus einer einzigen Datenbank sowie aus einem vorhandenen System abrufen. Dies bietet vollständige Flexibilität und überträgt die gesamte Datenverwaltungskomplexität auf den Server.
Resolver-Funktionen
In der GraphQL-Serverimplementierung entspricht jedes Felde im angefragten Payload genau einer Funktion, die als Resolver bezeichnet wird. Der einzige Zweck einer Resolver-Funktion besteht darin, die Daten für ihr Feld abzurufen.
Wenn der Server eine Query erhält, ruft er alle Funktionen für die Felder auf, die in der Payload der Abfrage angegeben sind. Sobald alle Resolvers zurückgegeben wurden, packt der Server die Daten in dem von der Abfrage beschriebenen Format und sendet sie an den Client zurück.
Was ist GraphQL, illustriert
Beispiel: Einfaches GraphQL Schema mit 3 Typen
Vorteile GraphQL
- Dem Client erlaubt es effizientes laden von Daten, es wird nur das geladen was benötigt wird
- Für verschiedene Frontend-Frameworks und Plattformen
- stark typisiertes System über Schemadefinition (SDL)
- Tools wie Apollo-Codegen können plattformspezifische Typdeklarationen für Client-Apps generieren (Flow-Typen für JavaScript, native Typen für Swift usw.), fehlende oder falsche Felder führen somit zu Laufzeitfehlern bevor die Queries an den Server geschickt werden
- einfaches Mocking zum Testen des Frontends möglich
- Dokumentation der API wird automatisch generiert und kann über API Explorer wir GraphiQL oder GraphQL-Playground inspiziert werden (https://developers.universe.com/page/graphql-explorer)
- inline documentation über inline field "description" bei Schema-Definiton (siehe Beispiel)
- Domain layer abstraction
- Möglichkeit, neue Schnittstellen abstrakt über vorhandenen Datenstrukturen zu legen
- unabhängig vom Transportprotokoll
- Introspection von Beginn an möglich
- Schnelle Funktionsentwicklung für Frontend
- Schema-Stiching: ermöglicht das Kombinieren und Verbinden mehrerer GraphQL-APIs und das Zusammenführen dieser zu einer einzigen
- Real Time-Scenarios können über Subscriptions umgesetzt werden
- Eine schnell wachsende Community
Vorteile GraphQL
- Perfomance-Tracing erlaubt detailiertes Monitoring (Beispiel Apollo Optics)
Nachteile GraphQL
- Error-Handling: Jede Response liefer ein HTTP Status "200" zurück, auch bei Fehlern. Hier müssen die Responses geparst werden. Apollo-Client hilft dabei mit eigenen Handlern
-
File-Uploads: sind nicht standardmäßig in GraphQL möglich, dieses Features muss manuell in die API implementiert werden. Anfragen müssen Clientsetig als multipart/form-data gesendet werden. Der Inhaltstyp muss auch im GraphQL-Servercode behandeln werden können.
Oder: Files werden über separate API behandelt - Aufsetzen eines GraphQL-Server: ist vorerst schwierig, da man in die Thematik einsteigen muss - new ways of thinking -
- Performance: deeply-nested queries können server überlasten, hier muss Schutz geboten werden. In einer GraphQL-API gibt es Tools wie Dataloader, mit denen Sie Datenbankaufrufe stapeln und zwischenspeichern können. In einigen Fällen reicht dies jedoch nicht aus. Die einzige Lösung besteht darin, Abfragen durch Berechnen maximaler Ausführungskosten oder Abfragetiefen zu blockieren. Jede dieser Lösungen hängt von der verwendeten Bibliothek ab.
- Performanceprobleme: diese zu finden und den Flaschenhals auszumachen kann schwierig werden, da ein einzelner Resolver daran schuld sein kann, erweitertes Tracing ist notwendig (z.B. über Apollo Tracing / Apollo Engine)
- Server Side Caching: Anfragen zu cachen ist schwieriger umzusetzen als bei REST, da der eine GraphQL-Endpunkt nie die gleichen Daten zurückliefert. Caching-Mechanismen müssen also tiefer im System ansetzen als z.B. nur über Netzwerk (HTTP)
Wer nutzt GraphQL?
- Facebook (hat GraphQL 2012 entwickelt, seit 2015 frei zugänglich, seit 2017 läuft das Projekt unter der freien OWFa-1.0-Lizenz)
- Github (GraphQL API released 2016)
- Financial Times
- The New York Times
- PayPal
- Sky
- Shopify
- Yelp
- uvm.
- ...
- many CMS integrations for decoupling frontend from backend: Drupal, wordpress, graphCMS...
Hier einige Case-Studys von Unternehmen die GraphQL implementiert haben: https://www.graphql.com/case-studies/
GraphQL-Server Best Practices
- Benutzung von Models und Collections, damit nicht jeder Resolver mit eigener Busnines-Logik ausgestattet werden muss (Auth gehört auch dazu)
- Implementierung von DataLoader im das Batching von Anfragen zu ermöglichen und Datenbankabfragen zu minimieren
- den Context den Resolvern dynamisch übergeben, sodass Schema, Type und Resolver von Context losgelöst sind
- maximale Abfrage-Tiefe definieren
- Abfragekomplexität definieren um zu rechenintensive Abfragen limitieren zu können
- Implementierung von Edges für Paginierung von Collections (Cursor Based, Offset/Limit-Based)
Vergleich REST-API mit GraphQL
- zuallererst, REST und GraphQL lassen sich schwer vergleichen da beide völlig unterschiedlich sind, es sind verschiedene Werkzeuge (als würde man Hammer mit Schraubendreher vergleichen)
- GraphQL ist keine magische Kugel und auch nicht grundsätzlich "besser", es hängt von Anwendungsfall ab
- man kann beide gleichzeitig verwenden
- GraphQL bringt eine neue differenzierte Entwickler-Erfahrung als REST-APIs
Vergleich REST-API mit GraphQL
Wie wird die Schnittstelle im Client Implementiert?
GraphQL:
- SmartCompontents, auch Container-Components genannt: Daten, Mutations, Subscriptions und LoadingState werden über HOC (High-OrderComponent) an die Props der jeweiligen Component gehangen
- DumpComponent spiel Daten nur noch aus, die die Smartcompement angefordert hat
- Ein zusätzlicher Abstraktionslayer ist hier nicht vorgesehen da die Abstraktion von GraphQL-Server übernommen wird
- Typensicherheit der Responses kann über Typescript ermöglicht werden, aktuell nicht im Einsatz
REST:
- alá Respository Pattern: Interfaces und Models beschreiben meine Datentypen, Services meine Schnittstellen zu Datenmanipulation und ermöglichen das ansteuern von Businesslogik
- diese können über Swagger-Doc und Swagger-Generate automatisch generiert werden
Vorteile REST-API
- REST-Endpunkte und Microservices passen gut zueinander. Einzelne Anwendungsbereiche können so separiert voneinander skaliert werden
- High performance (vor allem über HTTP2)
- Seit Jahrzehnten bewährt
- Vollständige Entkopplung von Client und Server ermöglicht unabhängige Entwicklung
Nachteile REST-API
- underfetching: Das Abrufen zugehöriger Daten erfordert häufig mehrere HTTP-Aufrufe. Mehrere Roundtrips können notwendig sein
- overfetching: Apps erhalten weit mehr Daten, als sie tatsächlich benötigen (könnte über Parameter wie Lutz implementiert hat gelöst werden) Frage dort dennoch, wie sich das auf die generierten Models auswirkt!?
- Clientside DataHandling, Storage und Caching muss manuell implementiert werden
- long time maintenance und Versionierung bei Softwareupdates kann zur Last werden, da App eventuell auf Endpunkte zurückgreift die nicht mehr existieren oder stark verändert wurden
- Frontend-Entwickler sind unter umständen auf Anpassungen an der Schnittstelle angewiesen
- Dokumentation separiert nötig um Endpunkte und ihre erwarteten Datentypen zu beschreiben (z.B. über Swagger)
- Schlechte oder keine Werkzeuge für Clients
Was bietet PostGraphile
Postgraphile V4.0 Middleware
ORM like Layer über PostgreSQL-Database. PostGraphile kombiniert leistungsstarke Funktionen wie das rollenbasierte Grant-System von PostgreSQL und Sicherheitsrichtlinien auf Zeilenebene mit den erweiterten GraphQL-Look-Ahead- und Plugin-Erweiterungstechnologien. Dadurch wird sichergestellt, dass das generierte Schema sicher, performant und erweiterbar ist
- Database Introspection und automatische Schemagenerierung
- Tolle Leistung - keine Probleme mit N + 1-Abfragen
- Anschlüsse für einfache Paginierung und Relay-Unterstützung
- Automatisch entdeckte Beziehungen, z.B. userByAuthorId
- Automatische CRUD-Mutationen, z.B. updatePost
- Computed columns, die eine einfache Erweiterung der API über DB-Spec ermöglichen
- Benutzerdefinierte Abfrageprozeduren, die beliebige SQL-Abfragen ermöglichen
- Benutzerdefinierte Mutationsverfahren, mit denen komplexe Änderungen einfach sichtbar gemacht werden können
Was bietet PostGraphile
- beachtet Best-Practices für GraphQL-Server Implementierung
- fügt Realtime-Funktion über pg_notify auf datenbankebene hinzu
- Paging, Filtering und advanced Filtering (über Plugins) integriert
Nachteile:
- standardmäßig alle Tables + Views + Function des DB-Schemas involviert, nur über custom Plugin oder smartComments sind einzelne Schema-Typen zu deaktivieren
- Funktioniert nur mit PostgreSQL-Datenbank
- Umbenennung der Feldtypen über smartComments oder extra GraphQL-Proxy der den Postgraphile-GraphQL-Server partiell durchreicht möglich
Welche Features müssten bei einer Custom GraphQL-Server-Implementierung händisch adaptiert werden (z.B. über ASP.Net Core GraphQL.Net):
- dynamische Schemagenerierung (Introspection DB)
- Erstellung von CRUD-Mutationen
- Collection mit Pagings, Filterung (Edges, Nodes)
- automatische Erkennung von Relationen in der DB
- DataLoader um Requests zu batchen
Lösungsansätze
Lösungsansatz 1:
Anmerkungen:
- aktueller Lösungsansatz für Prototyp
Herausforderungen/Probleme:
- (siehe Postgraphile Nachteile)
Lösungsansätze
Lösungsansatz 2:
Anmerkungen:
- DB-Zugriff wird über Postgraphile zur Verfügung gestellt und muss nicht extra implementiert werden
Herausforderungen/Probleme:
- herausfinden wie GraphQL Proxy implementiert werden muss
Lösungsansätze
Lösungsansatz 3:
Anmerkungen:
- komplette eigene Implementierung von GraphQL-Schemas mit Mapping auf EntityFramework für direkten DB-Access
Herausforderungen/Probleme:
- dynamische Schemagenerierung (Introspection DB)
- Erstellung von CRUD-Mutationen
- Collection mit Pagings, Filterung (Edges, Nodes)
- automatische Erkennung von Relationen in der DB
- DataLoader um Requests zu batchen
Lösungsansätze
Lösungsansatz 4:
Anmerkungen:
- Klassischer TechStack
Herausforderungen/Probleme:
- (siehe REST Vor-/Nachteile)
Lösungsansätze
Folgende Technologien sollte man in Erwägung ziehen
Frontend:
- Typescript
- Typensicherheit, was liefert GraphQL zurück?
- Repository Pattern (bei Verwendung von REST)
Middleware:
- ASP.Net Core GraphQL.Net
- Domain-Driven-Design
- Models
- Collections
- GraphQL.Conventions
- GraphQL .NET gibt es schon eine Weile. Die Bibliothek GraphQL.Conventions ist eine ergänzende Schicht, auf der .NET-Klassen automatisch in GraphQL-Schemadefinitionen eingebettet werden können, indem vorhandene Property-Getters und -Methoden als Feldauflöser verwenden werden
FAQ
Ist es einfach, einen GraphQL-Server zu erstellen?
-
Das Schema ist wie das Erstellen einer Swagger-Dokumentation für die API, nur dass in GraphQL das Schema immer erzwungen wird. Durch das Schema muss auch keinen Router und URL-Muster angeben werden. Das erstellen von GraphQL-Server kann also schneller sein als die Implementierung in REST (siehe auch Postgraphile)
Kann ich GraphQL mit <Angular / React / Ember / Redux> und anderen Apps verwenden?
-
Relay ist eine von mehreren GraphQL-Clients (jeodch direkt von Facebook entwickelt). Es sind andere Clients verfügbar, beispielsweise Apollo Client oder Lokka. GraphQL kann sogar ohne Client verwenden werden und rohe Zeichenfolgen an den Server senden, wie auch bei REST, frage ob das dann Sinn macht
-
Relay: steile Lernkurve, aber fügen Sie neben graphql noch viel hinzu: wie das Zusammenführen von Abfragen, Paginierung und verzögerte Abfragen
-
Apollo: Zwischenspeicherung und Integration in die Anwendungsschicht und Zustandsverwaltung. Es hat Integrationen für React, Redux, Angular 2 und andere, z. B. React Native
-
Lokka: Sehr simpler JS-Client, welcher beim Senden von GraphQL-Abfragen und -Antworten hilft. Es hat knapp über 100 Zeilen Code, was zeigt, wie einfach ein GraphQL-Client sein kann.
-