RPC-Aufrufe, REST und GraphQL, klar erklärt

In der modernen Softwareentwicklung existieren Anwendungen selten isoliert. Sie kommunizieren, tauschen Daten aus und lösen Aktionen ineinander aus, wodurch riesige, miteinander verbundene Ökosysteme entstehen. Diese Kommunikation wird durch Application Programming Interfaces (APIs) orchestriert, die die Regeln und Protokolle für die Interaktion verschiedener Softwarekomponenten definieren. Im Laufe der Jahrzehnte sind mehrere Architekturstile und Protokolle entstanden, um diese Inter-Service-Kommunikation zu erleichtern. Zu den prominentesten gehören Remote Procedure Calls (RPC), Representational State Transfer (REST) und GraphQL.

Das Verständnis dieser drei Paradigmen ist für jeden Entwickler oder Architekten, der verteilte Systeme entwirft, von entscheidender Bedeutung. Jedes hat seine eigene Philosophie, Stärken, Schwächen und idealen Anwendungsfälle. Dieser Artikel zielt darauf ab, RPC, REST und GraphQL klar zu erklären und sich mit ihren Kernkonzepten, Betriebsmechanismen, Vorteilen, Nachteilen und den Szenarien zu befassen, in denen jedes glänzt.

Die Grundlage: Client-Server-Kommunikation

Bevor wir in die Einzelheiten eintauchen, ist es wichtig, das grundlegende Modell zu verstehen, dem sie alle dienen: die Client-Server-Kommunikation. In diesem Modell benötigt ein Client (z. B. ein Webbrowser, eine mobile App, ein anderer Server) einige Daten oder möchte eine Aktion ausführen. Gleichzeitig hostet ein Server (eine Remote-Maschine oder ein Prozess) die Daten oder die Logik zur Ausführung der Aktion. Der Client sendet eine Anfrage an den Server, und der Server sendet eine Antwort zurück. Die Mechanismen, die wir gleich besprechen werden – RPC, REST und GraphQL – sind verschiedene Möglichkeiten, diese Anfragen und Antworten zu strukturieren.

RPC: Aufrufen von Funktionen über Netzwerke

Was ist RPC?

Remote Procedure Call stellt eines der frühesten und direktesten Paradigmen für die Interprozesskommunikation dar. Die grundlegende Idee ist, eine Anfrage an einen Remote-Server so aussehen zu lassen und zu betreiben, als wäre es ein lokaler Funktions- oder Prozeduraufruf. Die Client-Anwendung ruft eine scheinbar lokale Funktion (die "Prozedur") auf, aber die Ausführung dieser Funktion erfolgt tatsächlich auf einem Remote-Server. Die Komplexität der Netzwerkkommunikation wird sorgfältig abstrahiert, was der verteilten Programmierung eine Einfachheit verleiht, die der traditionellen Ein-Maschinen-Programmierung ähnelt.

Wie RPC funktioniert:

Der RPC-Prozess entfaltet sich durch eine Abfolge koordinierter Schritte, die darauf ausgelegt sind, die Remote-Ausführung transparent zu machen. Zunächst besitzt der Client einen "Stub" oder "Proxy" für die Remote-Prozedur. Dieser Stub spiegelt die Signatur der eigentlichen Remote-Prozedur wider. Wenn die Client-Anwendung diesen Stub aufruft, wird die Logik nicht lokal ausgeführt. Stattdessen nimmt der Client-Stub die an die Funktion übergebenen Parameter und "marshaliert" oder "serialisiert" sie. Dieser kritische Schritt wandelt die Parameter von ihrer In-Memory-Darstellung in ein für die Netzwerkübertragung geeignetes Format um, z. B. binär, XML oder JSON.

Nach dem Marshalling werden diese serialisierten Parameter, zusammen mit einer Kennung für die aufzurufende spezifische Prozedur, über das Netzwerk an den Server gesendet. Auf der Serverseite wartet ein "Skeleton" oder serverseitiger Stub und empfängt die eingehende Anfrage. Dieses Server-Skeleton übernimmt dann die Aufgabe des "Unmarshallings" oder "Deserialisierens" der empfangenen Daten und wandelt sie zurück in die Parameter, die die eigentliche Serverprozedur erwartet.

Mit den erfolgreich rekonstruierten Parametern ruft das Server-Skeleton die designierte Prozedur auf dem Server auf und übergibt ihm die ungemarshalten Parameter. Sobald die Prozedur ihre Ausführung abgeschlossen hat, werden ihr Rückgabewert zusammen mit allen aufgetretenen Ausnahmen vom Server-Skeleton gemarshallt. Diese serialisierte Antwort wird dann über das Netzwerk zurück an den Client-Stub übertragen. Beim Empfang der Antwort unmarshaliert der Client-Stub sie und wandelt die Daten zurück in einen Rückgabewert, den die Client-Anwendung leicht verstehen kann. Schließlich gibt der Client-Stub diesen Wert an den ursprünglichen aufrufenden Code zurück und vollendet so die Illusion, dass ein lokaler Funktionsaufruf durchgeführt wurde.

Hauptmerkmale von RPC:

RPC-APIs sind typischerweise aktionsorientiert. Sie sind um Verben oder Befehle herum konzipiert, wie z. B. addUser(userDetails) oder calculatePrice(itemId, quantity). Der Hauptfokus liegt auf "welche Aktionen Sie ausführen können".

Traditionell weisen Clients und Server in RPC-Systemen eine enge Kopplung auf. Der Client benötigt oft explizites Wissen über die spezifischen Funktionsnamen und die genauen Parametersignaturen, die auf dem Server verfügbar sind. Folglich erfordern Änderungen auf der Serverseite häufig entsprechende Änderungen auf der Clientseite.

RPC-Frameworks stellen üblicherweise Tools zur Generierung von Client-Stubs und Server-Skeletten in verschiedenen Programmiersprachen aus einer gemeinsam genutzten Interface Definition Language (IDL) bereit. Beispiele für IDLs sind CORBA IDL, Protocol Buffers (.proto-Dateien) oder Apache Thrift IDL. Diese Code-Generierungsfähigkeit erleichtert die Interoperabilität.

In Bezug auf die Effizienz sind viele RPC-Protokolle, insbesondere solche, die Binärformate verwenden, auf optimale Leistung in Bezug auf Datengröße und Verarbeitungsgeschwindigkeit ausgelegt.

Entwicklung: gRPC

Während frühere RPC-Implementierungen wie XML-RPC oder Java RMI bestimmte Einschränkungen aufwiesen, hat das RPC-Paradigma mit dem Aufkommen moderner Frameworks wie gRPC (Google RPC) eine deutliche Wiederbelebung erfahren. gRPC führt erhebliche Verbesserungen ein. Es verwendet vorwiegend Protocol Buffers als IDL und für die Nachrichtenserialisierung. Protocol Buffers bieten einen sprachunabhängigen, plattformneutralen, erweiterbaren Mechanismus zur Serialisierung strukturierter Daten, der oft als eine kompaktere, schnellere und einfachere Alternative zu XML beschrieben wird.

Darüber hinaus arbeitet gRPC über HTTP/2, was erweiterte Funktionen wie Multiplexing (ermöglicht mehrere Anfragen und Antworten über eine einzige Verbindung), Server-Push-Funktionen und Header-Komprimierung ermöglicht. Diese Funktionen tragen zusammen zu einer verbesserten Leistung und reduzierten Latenz bei.

Eine bemerkenswerte Stärke von gRPC ist die Unterstützung verschiedener Streaming-Modi. Dazu gehören Unary (ein einfaches Anfrage-Antwort-Muster), Server-Streaming (wobei der Client eine Anfrage sendet und der Server mit einem Stream von Nachrichten antwortet), Client-Streaming (wobei der Client einen Stream von Nachrichten sendet und der Server eine einzelne Antwort ausgibt) und bidirektionales Streaming (wobei sowohl Client als auch Server unabhängig voneinander einen Stream von Nachrichten senden können).

Schließlich bietet gRPC robuste Tools für die Code-Generierung, die die automatische Erstellung von Client- und Server-Code in einer Vielzahl beliebter Programmiersprachen ermöglichen.

Vorteile von RPC (insbesondere modernes RPC wie gRPC):

• Leistung: Es kann außergewöhnlich leistungsfähig sein, insbesondere bei der Verwendung von Binärprotokollen wie Protocol Buffers in Verbindung mit HTTP/2. Geringe Latenz ist ein herausragender Vorteil.
• Einfachheit (für Entwickler): Die Abstraktion eines Remote-Aufrufs als lokale Funktion kann die Entwicklungsaufwände erheblich vereinfachen, insbesondere für interne Microservices.
• Stark typisierte Verträge: IDLs erzwingen einen klaren, eindeutigen Vertrag zwischen Client und Server, was dazu beiträgt, Integrationsfehler während der Kompilierzeit zu erkennen.
• Streaming-Funktionen: Es zeichnet sich in Szenarien aus, die einen Echtzeit-Datenfluss oder die Übertragung großer Datensätze erfordern.
• Code-Generierung: Die automatische Generierung von Client-Bibliotheken und Server-Stubs reduziert die Menge an Boilerplate-Code, den Entwickler schreiben müssen.

Nachteile von RPC:

• Enge Kopplung: Selbst bei Verwendung von IDLs erfordern Änderungen an Prozedursignaturen oft die Neuerstellung und erneute Bereitstellung von Client- und Server-Code.
• Auffindbarkeit: Im Gegensatz zu REST gibt es keine standardisierte Methode zum Auffinden verfügbarer Prozeduren oder ihrer Strukturen ohne vorherigen Zugriff auf die IDL oder die zugehörige Dokumentation.
• Weniger browserfreundlich (historisch): Traditionelle RPC-Mechanismen waren nicht so einfach direkt in Webbrowser zu integrieren wie REST. Während gRPC-Web darauf abzielt, diese Lücke zu schließen, erfordert es typischerweise eine Proxy-Schicht.
• Firewall-Traversal: Nicht-HTTP-basierte RPC-Mechanismen könnten manchmal auf Schwierigkeiten mit Firewalls stoßen, die vorwiegend so konfiguriert sind, dass sie HTTP-Datenverkehr zulassen. gRPC mildert dieses Problem durch die Verwendung von HTTP/2 weitgehend.

Wann RPC verwendet werden soll:

Erwägen Sie RPC für die interne Microservice-Kommunikation, bei der Leistung und geringe Latenz kritische Designziele sind. Es eignet sich auch gut für Anwendungen, die komplexes, hochleistungsfähiges Streaming von Daten erfordern. Wenn ein klar definierter, stark typisierter Vertrag zwischen Diensten gewünscht wird, bietet RPC erhebliche Vorteile. Polyglotte Umgebungen, in denen die Code-Generierung für mehrere Sprachen die Entwicklung rationalisieren kann, profitieren ebenfalls von RPC. Schließlich ist RPC, insbesondere gRPC mit Protocol Buffers, in netzwerkbeschränkten Umgebungen, in denen die Effizienz der Nachrichtengröße von größter Bedeutung ist, ein starker Kandidat.

REST: Ressourcen und Hypermedia

Was ist REST?

REST oder Representational State Transfer ist kein Protokoll oder ein starres Standard, sondern ein Architekturstil für die Gestaltung von Netzwerkanwendungen. Es wurde von Roy Fielding in seiner Dissertation im Jahr 2000 akribisch definiert. REST nutzt geschickt die bestehenden Funktionen und Protokolle von HTTP und legt den Schwerpunkt auf einen zustandslosen, client-serverbasierten, zwischenspeicherbaren Kommunikationsmodus. Das zentrale Konzept dreht sich darum, dass Ressourcen (Dateneinheiten) eindeutig durch URLs identifiziert werden und Interaktionen mit diesen Ressourcen mithilfe von Standard-HTTP-Methoden durchgeführt werden.

Kernprinzipien von REST (Einschränkungen):

Der REST-Architekturstil wird durch mehrere Leitprinzipien definiert:

Ein grundlegendes Prinzip ist die Client-Server-Architektur. Dies schreibt eine klare Trennung der Verantwortlichkeiten vor. Der Client ist für die Aspekte der Benutzeroberfläche und der Benutzererfahrung verantwortlich, während der Server Datenspeicherung, Geschäftslogik und die Bereitstellung der API selbst verwaltet.

Eine weitere entscheidende Einschränkung ist die Zustandslosigkeit. Jede vom Client an den Server gesendete Anfrage muss alle Informationen enthalten, die der Server benötigt, um diese Anfrage zu verstehen und zu verarbeiten. Der Server behält zwischen einzelnen Anfragen keinen Client-Kontext (Sitzungsstatus) bei. Jeder für eine Sitzung relevante Zustand wird auf der Clientseite verwaltet.

Cachebarkeit ist ebenfalls ein wichtiges Prinzip. Vom Server generierte Antworten müssen sich explizit als entweder zwischenspeicherbar oder nicht zwischenspeicherbar definieren. Dies ermöglicht es Clients und Zwischensystemen (wie Content Delivery Networks oder CDNs), Antworten zwischenzuspeichern, was die Leistung und Skalierbarkeit erheblich verbessern kann.

REST-Systeme sind als geschichtetes System konzipiert. Dies bedeutet, dass ein Client typischerweise nicht feststellen kann, ob er direkt mit dem Endserver oder mit einem Vermittler (wie einem Load Balancer oder Proxy) entlang des Kommunikationspfads verbunden ist. Zwischenserver können die Systemskalierbarkeit durch die Erleichterung des Load Balancing und die Bereitstellung gemeinsamer Caches verbessern.

Die Einschränkung der einheitlichen Schnittstelle unterscheidet REST wohl am meisten und dient dazu, die Architektur zu vereinfachen und zu entkoppeln. Diese Einschränkung wird weiter in mehrere Untereinschränkungen unterteilt.

Erstens, Identifizierung von Ressourcen: Alle konzeptionellen Ressourcen werden innerhalb von Anfragen mithilfe von URIs (Uniform Resource Identifiers), typischerweise URLs, identifiziert. Beispielsweise identifiziert /users/123 eindeutig eine bestimmte Benutzerressource.

Zweitens, Manipulation von Ressourcen durch Darstellungen: Clients interagieren mit Ressourcen nicht durch direktes Aufrufen von Methoden auf ihnen, sondern durch den Austausch von Darstellungen dieser Ressourcen. Eine Darstellung kann in verschiedenen Formaten vorliegen, z. B. JSON, XML oder HTML. Der Client gibt seine bevorzugten Formate mithilfe von Accept-Headern an, während der Server das Format der gesendeten Darstellung mithilfe des Content-Type-Headers angibt.

Drittens, Selbstbeschreibende Nachrichten: Jede ausgetauschte Nachricht muss genügend Informationen enthalten, um zu beschreiben, wie sie verarbeitet werden soll. Beispielsweise liefern HTTP-Header wie Content-Type und Content-Length Metadaten über den Nachrichtentext, und Statuscodes informieren den Client über das Ergebnis seiner Anfrage.

Viertens, Hypermedia als Motor des Anwendungszustands (HATEOAS): Dieses Prinzip, das oft als der anspruchsvollste und manchmal am wenigsten implementierte Aspekt von REST angesehen wird, schreibt vor, dass Serverantworten Links (Hypermedia) enthalten sollten. Diese Links führen den Client, indem sie angeben, welche Aktionen er als Nächstes ausführen oder auf welche zugehörigen Ressourcen er zugreifen kann. Dies ermöglicht es Clients, die API dynamisch zu navigieren, anstatt sich auf fest codierte URIs zu verlassen. Beispielsweise könnte eine Antwort für eine Benutzerressource Links zum Anzeigen ihrer Bestellungen oder zum Aktualisieren ihrer Profildetails enthalten.

Eine optionale Einschränkung ist Code on Demand. Dies ermöglicht es Servern, die Funktionalität eines Clients vorübergehend zu erweitern oder anzupassen, indem ausführbarer Code, z. B. JavaScript-Snippets, übertragen wird.

Wie REST funktioniert:

In einem RESTful-System wird alles als Ressource konzeptualisiert (z. B. ein Benutzer, ein Produkt, eine Bestellung). Jede Ressource wird eindeutig durch eine URI identifiziert. Beispielsweise könnte GET /users eine Liste von Benutzern abrufen, während GET /users/123 den spezifischen Benutzer mit der ID 123 abruft.

Standard HTTP-Methoden (Verben) werden verwendet, um Aktionen für diese Ressourcen auszuführen. GET wird verwendet, um eine Ressource abzurufen. POST erstellt typischerweise eine neue Ressource oder kann verwendet werden, um einen Prozess auszulösen, wobei Daten für die neue Ressource im Anfragetext gesendet werden. PUT wird verwendet, um eine vorhandene Ressource zu aktualisieren, was normalerweise einen vollständigen Ersatz der Daten der Ressource erfordert und idempotent ist (mehrere identische Anfragen haben die gleiche Wirkung wie eine einzelne Anfrage). DELETE entfernt eine Ressource. PATCH ermöglicht Teilaktualisierungen einer vorhandenen Ressource. HEAD ruft Metadaten über eine Ressource ab, ähnlich wie GET, jedoch ohne den Antworttext. OPTIONS wird verwendet, um Informationen über die Kommunikationsoptionen für die Zielressource abzurufen.

Statuscodes, die Teil des HTTP-Standards sind, werden verwendet, um das Ergebnis einer Anfrage anzuzeigen. Beispiele sind 200 OK, 201 Created für erfolgreiche Erstellung, 400 Bad Request für Clientfehler, 404 Not Found, wenn eine Ressource nicht existiert, und 500 Internal Server Error für serverseitige Probleme.

In Bezug auf Datenformate hat sich JSON (JavaScript Object Notation) aufgrund seiner Leichtigkeit und einfachen Analyse zum vorherrschenden Format für den Datenaustausch in REST-APIs entwickelt. XML, HTML oder sogar reiner Text können jedoch ebenfalls verwendet werden.

Vorteile von REST:

• Einfachheit und Vertrautheit: Es nutzt gut verstandene HTTP-Standards und macht es relativ einfach zu erlernen, zu implementieren und zu nutzen.
• Zustandslosigkeit: Dies vereinfacht das Serverdesign und verbessert die Skalierbarkeit, da Server zwischen Anfragen keine Client-Sitzungsinformationen verwalten müssen.
• Cachebarkeit: HTTP-Caching-Mechanismen können direkt und effektiv verwendet werden, um die Leistung zu verbessern und die Serverlast zu reduzieren.
• Entkopplung: Der Client und der Server sind entkoppelt. Solange die Ressourcen-URI und der Methodenvertrag konsistent bleiben, können sich die zugrunde liegenden Implementierungen auf beiden Seiten unabhängig voneinander weiterentwickeln.
• Auffindbarkeit (mit HATEOAS): Wenn HATEOAS ordnungsgemäß implementiert ist, können Clients dynamisch verfügbare Aktionen ermitteln und durch Ressourcen navigieren, wodurch die API flexibler und entwicklungsfähiger wird.
• Weite Akzeptanz und Tooling: Es gibt ein riesiges Ökosystem von Tools, Bibliotheken, Client-SDKs und Gateways, die RESTful-APIs unterstützen. Es ist von Natur aus browserfreundlich.
• Für Menschen lesbar: URIs sind oft so konzipiert, dass sie für Menschen lesbar sind, und gängige Datenformate wie JSON sind für Entwickler leicht zu untersuchen und zu debuggen.

Nachteile von REST:

• Over-Fetching und Under-Fetching: Dies sind häufige Probleme.
• Over-Fetching tritt auf, wenn ein Endpunkt mehr Daten zurückgibt, als der Client tatsächlich für eine bestimmte Aufgabe benötigt. Um beispielsweise eine Liste von Benutzernamen anzuzeigen, könnte ein /users-Endpunkt vollständige Benutzerobjekte einschließlich Adressen, Telefonnummern und anderer Details für jeden Benutzer zurückgeben, von denen die meisten möglicherweise ungenutzt sind.
• Under-Fetching tritt auf, wenn ein Client mehrere Anfragen an verschiedene Endpunkte stellen muss, um alle Daten zu sammeln, die er für eine vollständige Ansicht benötigt. Um beispielsweise die Details eines Benutzers und seine letzten Beiträge abzurufen, muss ein Client möglicherweise zuerst /users/{id} aufrufen und dann einen separaten Aufruf an /users/{id}/posts tätigen.
• Mehrere Round Trips: Das Problem des Under-Fetching führt oft zu mehreren Netzwerk-Roundtrips, was die Latenz erhöhen und sich negativ auf die Benutzererfahrung auswirken kann, insbesondere in mobilen oder unzuverlässigen Netzwerken.
• Herausforderungen bei der Versionierung: Die Weiterentwicklung von REST-APIs, ohne vorhandene Clients zu unterbrechen, kann eine Herausforderung sein. Gängige Strategien umfassen die URI-Versionierung (z. B. /v1/users), die Verwendung benutzerdefinierter Anforderungsheader für die Versionierung oder die Verwendung der Medientyp-Versionierung (über Accept-Header). Jeder Ansatz hat seine eigenen Komplexitäten und Kompromisse.
• HATEOAS wird oft vernachlässigt: Obwohl es ein Kernprinzip von REST ist, wird HATEOAS häufig nicht vollständig implementiert. Dies schränkt die wahre Auffindbarkeit und dynamische Entwicklungsfähigkeit ein, die REST anstrebt.
• Keine starke Typisierung Out-of-the-Box: Im Gegensatz zu RPC-Systemen, die IDLs verwenden, stützt sich REST auf Konventionen und externe Dokumentation (wie OpenAPI/Swagger-Spezifikationen) zur Definition von API-Verträgen. Diese werden nicht immer zur Kompilierzeit erzwungen, was möglicherweise zu Integrationsproblemen führt.

Wann REST verwendet werden soll:

REST ist eine ausgezeichnete Wahl für öffentlich zugängliche APIs, bei denen eine breite Akzeptanz, einfache Integration und Interoperabilität wichtig sind. Es eignet sich gut für ressourcenorientierte Anwendungen, bei denen Standard-CRUD-Operationen (Create, Read, Update, Delete) für Entitäten die primäre Interaktionsform darstellen. Wenn die Nutzung von HTTP-Caching für Leistung und Skalierbarkeit von entscheidender Bedeutung ist, ist die Ausrichtung von REST auf HTTP-Standards ein erheblicher Vorteil. Situationen, die Zustandslosigkeit und horizontale Skalierbarkeit erfordern, profitieren ebenfalls stark vom RESTful-Architekturstil. Wenn außerdem die Auffindbarkeit durch Hypermedia (HATEOAS) gewünscht wird, damit Clients die API dynamisch navigieren können, bietet REST den Rahmen dafür.

GraphQL: Eine Abfragesprache für Ihre API

Was ist GraphQL?

GraphQL ist eine Abfragesprache, die speziell für APIs entwickelt wurde, und sie umfasst auch eine serverseitige Laufzeit zur Ausführung dieser Abfragen unter Verwendung eines Typsystems, das Sie für Ihre Daten definieren. Ursprünglich von Facebook entwickelt und 2015 anschließend Open Source gestellt, wurde GraphQL konzipiert, um einige der inhärenten Einschränkungen in RESTful-Architekturen direkt anzugehen, insbesondere die Zwillingsprobleme des Over-Fetching und Under-Fetching von Daten. Es ermöglicht Clients, genau die Daten anzufordern, die sie benötigen, nicht mehr und nicht weniger, typischerweise innerhalb eines einzigen Anfrage-Antwort-Zyklus.

Kernkonzepte von GraphQL:

Die Architektur von GraphQL basiert auf mehreren grundlegenden Konzepten.

Ein Eckpfeiler ist die Schema Definition Language (SDL). GraphQL-APIs werden rigoros durch ein starkes Typsystem definiert. Der Server veröffentlicht ein Schema, das alle Datentypen, die ein Client abfragen darf, sowie die komplizierten Beziehungen, die zwischen diesen Datentypen bestehen, akribisch beschreibt. Dieses Schema dient als verbindlicher Vertrag zwischen dem Client und dem Server. Innerhalb der SDL definieren Sie verschiedene Konstrukte:

• Typen beschreiben die Objekte, die Sie abrufen können, und ihre Felder (z. B. type User { id: ID!, name: String, email: String, posts: [Post] }).
• Abfragen definieren die Einstiegspunkte für Datenabrufoperationen (z. B. type Query { user(id: ID!): User, posts: [Post] }).
• Mutationen definieren die Einstiegspunkte für Datenmodifikationsoperationen – Erstellen, Aktualisieren oder Löschen von Daten (z. B. type Mutation { createUser(name: String!, email: String!): User }).
• Abonnements definieren, wie Clients Echtzeit-Updates erhalten können, wenn sich bestimmte Daten auf dem Server ändern (z. B. type Subscription { newPost: Post }).

Ein weiteres Unterscheidungsmerkmal ist die typische Verwendung eines Single Endpoint. Im Gegensatz zu REST, das üblicherweise mehrere URLs verwendet, um verschiedene Ressourcen und Operationen darzustellen, stellen GraphQL-APIs in der Regel nur einen Endpunkt (z. B. /graphql) bereit. Alle Anfragen, ob es sich um Abfragen zum Abrufen von Daten, um Mutationen zum Ändern von Daten oder um Abonnements für Echtzeit-Updates handelt, werden an diesen einzelnen Endpunkt weitergeleitet, in der Regel über eine HTTP-POST-Anfrage.

Zentral für die Leistungsfähigkeit von GraphQL ist das Konzept der Client-Specified Queries. Die Client-Anwendung erstellt eine Abfragezeichenfolge, die explizit angibt, welche Daten sie genau benötigt. Dies kann nicht nur Felder für ein primäres Objekt, sondern auch Felder für verwandte Objekte umfassen, wodurch komplexe Datenbeziehungen durchlaufen werden. Der Server verarbeitet dann diese Abfrage und antwortet mit einem JSON-Objekt, dessen Struktur genau die Struktur der vom Client übermittelten Abfrage widerspiegelt.

Wie GraphQL funktioniert:

Die Interaktion in einem GraphQL-System folgt einem klar definierten Ablauf. Es beginnt mit der Schema Definition, bei der der Server seine Datenfunktionen mithilfe der SDL von GraphQL definiert.

Anschließend wird die Client Query erstellt. Der Client formuliert eine GraphQL-Abfragezeichenfolge, in der die spezifischen Datenfelder detailliert beschrieben werden, die er benötigt. Zum Beispiel:GraphQL

query GetUserDetails {
  user(id: "123") {
    id
    name
    email
    posts { # Fetch related posts
      title
      content
    }
  }
}

Diese Abfrage wird dann in einer Anfrage an den Server gesendet, normalerweise als JSON-Payload innerhalb einer HTTP-POST-Anfrage, die auf den einzelnen GraphQL-Endpunkt abzielt.

Beim Empfang der Anfrage beginnt die Server Processing. Dies beinhaltet mehrere Teilschritte. Der Server analysiert und validiert zuerst die eingehende Abfrage, indem er ihre Syntax überprüft und sicherstellt, dass sie dem definierten Schema entspricht. Wenn sie gültig ist, wechselt die Abfrage zur Ausführung. Der Server führt die Abfrage aus, indem er "Resolver"-Funktionen aufruft. Jedes im GraphQL-Schema definierte Feld wird von einer entsprechenden Resolver-Funktion unterstützt. Ein Resolver ist ein Code-Fragment, das für das Abrufen der Daten für sein spezifisches Feld verantwortlich ist. Diese Resolver können Daten aus verschiedenen Quellen abrufen, z. B. Datenbanken, anderen internen oder externen APIs oder sogar statischen Daten.

Schließlich formuliert und sendet der Server eine Antwort an den Client. Diese Antwort ist ein JSON-Objekt, dessen Struktur die Form der ursprünglichen Abfrage widerspiegelt und nur die Daten enthält, die explizit angefordert wurden. Für die obige Beispielabfrage könnte die Antwort wie folgt aussehen:JSON

{
  "data": {
    "user": {
      "id": "123",
      "name": "Alice Wonderland",
      "email": "alice@example.com",
      "posts": [
        {
          "title": "My First Post",
          "content": "Hello world!"
        },
        {
          "title": "GraphQL is Cool",
          "content": "Learning about GraphQL..."
        }
      ]
    }
  }
}

Vorteile von GraphQL:

• Kein Over-Fetching oder Under-Fetching: Clients fordern genau die Daten an, die sie benötigen, was zu einer hocheffizienten Datenübertragung führt und die verschwendete Bandbreite reduziert.
• Einzelne Anfrage für mehrere Ressourcen: Verwandte Daten, auch über verschiedene konzeptionelle Ressourcen hinweg, können in einer einzigen Abfrage abgerufen werden, wodurch die Anzahl der Netzwerk-Roundtrips erheblich reduziert wird.
• Stark typisiertes Schema: Das Schema dient als klarer und maßgeblicher Vertrag zwischen Client und Server. Diese starke Typisierung ermöglicht leistungsstarke Entwicklertools wie Auto-Vervollständigung, statische Analyse und Abfragevalidierung und fungiert auch als eine Form der Selbstdokumentation.
• Entwicklungsfähigkeit: Es wird einfacher, APIs weiterzuentwickeln, ohne auf Versionierung zurückzugreifen. Das Hinzufügen neuer Felder oder Typen zum Schema unterbricht keine vorhandenen Clients, da sie nur die Daten erhalten, die sie explizit anfordern. Das Veralten alter Felder ist ebenfalls einfacher.
• Echtzeitdaten mit Abonnements: GraphQL enthält integrierte Unterstützung für Echtzeit-Updates über Abonnements, sodass Clients auf bestimmte Datenänderungen auf dem Server hören können.
• Introspektiv: GraphQL-APIs sind von Natur aus introspektiv. Clients können das Schema selbst abfragen, um die verfügbaren Typen, Felder, Abfragen, Mutationen und Abonnements zu ermitteln, was die Erkundung und dynamische Client-Generierung erleichtert.

Nachteile von GraphQL:

• Komplexität: Das Einrichten und Verwalten eines GraphQL-Servers kann im Vergleich zu einfachen REST-APIs komplexer sein, insbesondere in Bezug auf die Implementierung der Resolver-Logik, das Schema-Design und die Leistungsoptimierung.
• Caching: HTTP-Caching-Mechanismen sind in GraphQL im Vergleich zum ressourcenbasierten Caching von REST weniger einfach direkt anzuwenden. Während es ausgefeilte clientseitige Caching-Lösungen (wie Apollo Client oder Relay) gibt, erfordern serverseitiges und intermediäres Caching unterschiedliche Strategien, und das Caching auf Feldebene kann kompliziert sein.
• Datei-Uploads: Die GraphQL-Spezifikation behandelt Datei-Uploads nicht nativ. Dies erfordert typischerweise Workarounds, z. B. die Verwendung separater REST-Endpunkte für die Dateiverarbeitung oder die Implementierung von Multipart-Request-Processing-Bibliotheken neben GraphQL.
• Ratenbegrenzung: Die Implementierung einer effektiven Ratenbegrenzung kann komplexer sein, da die "Kosten" oder die Ressourcenintensität einer GraphQL-Abfrage nicht sofort ersichtlich sind, nur indem man sie betrachtet; eine tief verschachtelte oder komplexe Abfrage kann sehr teuer in der Ausführung sein. Dies erfordert oft Mechanismen zur Abfragekostenanalyse.
• Lernkurve: Es gibt eine Lernkurve, die mit dem Verständnis von GraphQL-Konzepten, der Beherrschung von Schema-Design-Best Practices und der Beherrschung der Abfragesprache selbst verbunden ist.
• Leistungsfallen: Schlecht geschriebene Resolver oder übermäßig komplexe, tief verschachtelte Abfragen können zu Leistungsproblemen führen, z. B. dem N+1-Problem (wobei das Abrufen einer Liste von Elementen und ihren untergeordneten Elementen zu einer Abfrage für die Liste und N zusätzlichen Abfragen für die untergeordneten Elemente jedes Elements führt), wenn sie nicht sorgfältig mit Techniken wie Datenladern behandelt werden.

Wann GraphQL verwendet werden soll:

GraphQL eignet sich besonders gut für Anwendungen mit unterschiedlichen Clients, wie z. B. Webanwendungen, mobile Apps und IoT-Geräte, die alle unterschiedliche Datenanforderungen haben können. Es glänzt in Situationen, in denen die Minimierung der Datenübertragung und die Reduzierung der Anzahl der Netzwerk-Roundtrips von entscheidender Bedeutung sind, beispielsweise in mobilen Anwendungen, die in langsamen oder unzuverlässigen Netzwerken arbeiten. Für komplexe Systeme, in denen Clients Daten aus mehreren zugrunde liegenden Quellen abrufen oder tief verschachtelte Ressourcenbeziehungen navigieren müssen, bietet GraphQL eine elegante Lösung. Wenn ein stark typisierter API-Vertrag, robuste Selbstdokumentationsfunktionen und API-Entwicklungsfähigkeit von hohem Wert sind, bietet GraphQL diese Vorteile. Anwendungen, die Echtzeit-Updates über Abonnements benötigen, können die native Unterstützung von GraphQL für diese Funktion nutzen. Letztendlich ist GraphQL eine ausgezeichnete Wahl, wenn Sie Clients mehr Leistung und Flexibilität bei der Art und Weise geben möchten, wie sie Daten abrufen, und Anfragen an ihre genauen Bedürfnisse anpassen möchten.

RPC vs. REST vs. GraphQL: Ein vergleichender Blick