SITIC Online Sharing, Mittwoch 26. Januar 2022, 10 – 12 Uhr

GraphQL APIs – Wozu sind sie wirklich gut?

Hintergrund

GraphQL wurde von Facebook 2015 öffentlich gemacht nachdem sie drei Jahre lang intern entwickelt und eingesetzt wurde. Mit dieser Innovation wollte Facebook die Anzahl der Anfragen, welche ein Client für das Zusammenfügen komponentenbasierten User Interfaces ausführt, reduzieren. Die Bündelung von Anfragen für granulare Daten ist vor allem für mobile Clients sinnvoll, die nicht viele parallele Anfragen ausführen können. Selbst als der ursprüngliche Motivator durch schnellere Endgeräte obsolete wurde, fand eine partielle Adaptierung dieser Technologie statt.

Betrachtet man die Stärke der Typisierung die GraphQL-APIs erreichen, siedelt sich GraphQL zwischen REST und SOAP an. Diese länger bekannten API-Technologien besetzen gewissermassen die Extreme auf der Typisierungs-Skala. REST als der Quasi-Standard für öffentliche APIs bietet eine hohe Flexibilität und wenig Kopplung, SOAP dagegen rigidere Validierung und erweiterte Standards für die Interaktion von Client und API-Server.

Verschiedene Adaptierungen von GraphQL gehen unterschiedlich weit:

  • API-Konsolidierung: Mehrere APIs, z.B. basierend auf REST werden mittels Graph-QL zu einer einzigen API zusammengeführt.
  • Spezifizierung der Kommunikation von Client-Server, aber auch zwischen Services: GraphQL-Schemata definieren (typisieren) alle Nachrichten und Interaktionen, ähnlich zu RPC Protokollen.
  • Kommunikation und Datenbank-Zugriffe: GraphQL wird End-to-End eingesetzt, manche der in GraphQL-Schemata definierten Typen werden auch persistierbar, z.B. in NoSQL-Datenbanken.

Zielsetzung

Wir werden eine Auswahl der folgenden Schlüsselfragen diskutieren, die von den Teilnehmenden priorisiert werden:

  1. In welchen Szenarien sind die obigen Adaptierungen sinnvoll?
  2. Ist die Selbst-Dokumentierung einer GraphQL-API ausreichend oder z.B. einer manuell geschriebenen REST-API Dokumentation unterlegen?
  3. Ist die Sicherheit von GraphQL-APIs schwerer zu garantieren?
  4. Wie ist die Verwaltung von Zugriffsrechten zu organisieren wenn GraphQL im Gegensatz zu REST-APIs unzählige, flexible Anfragen erlaubt?
  5. Was sind die grössten Nachteile beim Einsatz von GraphQL, unter anderem bezüglich Monitoring, Testing, Fehlerbehandlung, Caching? Welche Lösungen gibt es um diese Nachteile zu mitigieren?
  6. Wie können idempotente Anfragen in GraphQL realisiert werden?

Vorbereitung

Von den Teilnehmenden wird erwartet, dass sie sich anhand eines Fragenkatalogs vorbereiten. Die Fragen werden zusammen mit der Teilnahmebestätigung und den Zugangsdaten zum Online-Event zugestellt.

Teilnehmende

Willkommen sind Business IT Professionals, welche im Unternehmen Aufgaben der Digitalisierung, IT-Architektur oder DevOps wahrnehmen.

Moderation

Fachliche Moderation: Simon Wehrli
Technische Moderation: Florence Neumann

Agenda

(60’) Einführung: Nach einer allgemeinen Einführung in das Schema einer GraphQL-API und einer Demo der Benutzung vergleichen wir am Beispiel einer Mini-Applikation mit zwei APIs, wie sich die GraphQL- von einer REST-API unterscheidet.

(40’) Diskussion präferenzierter Fragen.

(20’) Priorisierung der Key-Takeaways.

Nachlese

Die Nachlese setzt den sinnvollen Einsatz von GraphQL im Architektur-Kontext aus den gewonnenen Erkenntnissen dar.

Anmeldung

Verbindliche Anmeldung bitte via Email an kurt.wehrli@sitic.org

Kosten

Für SITIC-Mitglieder ist die Teilnahme im Rahmen der Jahresmitgliedschaft unentgeltlich.
Nicht-Mitgliedern werden 375 CHF in Rechnung gestellt, der Zahlungseingang muss vor dem Sharing erfolgen.

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data.

GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.
Referenz