GraphQL

GraphQL

0:00 Im letzten Modul haben wir unsere Daten über REST nach außen gegeben. Dabei bestimmt der Server, was in der Antwort steht — der Aufrufer bekommt das ganze Objekt, ob er alles davon braucht oder nicht. Auf einem Mobilgerät mit schlechter Verbindung ist das spürbar. GraphQL dreht diese Rolle um: Der Aufrufer beschreibt, welche Felder er haben will, und bekommt genau die.

0:22 Kein Feld zu viel, und wo er sonst drei Anfragen gebraucht hätte, genügt eine. Wir zeigen in diesem Modul dieselben Werkbank-Daten noch einmal — auf diesem zweiten Weg. Und Sie werden sehen, wie wenig Code dafür nötig ist.

GraphQL in Quarkus

0:36 Sehen wir uns zunächst an, wie Quarkus an dieses Thema herangeht — und ob Sie dafür etwas grundsätzlich Neues lernen müssen. Die Erwartung wäre ja berechtigt: GraphQL kommt aus einer ganz anderen Ecke als die Java-Enterprise-Welt, es hat eine eigene Abfragesprache und ein eigenes Typsystem. Umso bemerkenswerter ist, wie wenig sich an Ihrer Arbeitsweise ändert. Das Muster, das Sie aus den ersten Modulen kennen, trägt auch hier.

1:01 Die Antwort ist beruhigend: Es bleibt beim bekannten Muster. Quarkus setzt auch hier auf einen Standard, nämlich MicroProfile GraphQL, und die Umsetzung liefert das SmallRye-Projekt. Entscheidend ist die Richtung, in der gearbeitet wird. GraphQL braucht ein Schema — eine formale Beschreibung dessen, was abfragbar ist. Sie schreiben dieses Schema aber nicht.

1:23 Sie annotieren Ihre Java-Methoden, und das Schema entsteht daraus. Der Vorteil liegt auf der Hand: Es kann nicht auseinanderlaufen. Wer schon einmal eine Schnittstellenbeschreibung gepflegt hat, die neben dem Code herlief und irgendwann log, weiß, warum das mehr als eine Bequemlichkeit ist. Der offensichtliche Gewinn ist der eine Endpunkt, der genau die angefragten Felder liefert.

1:46 Weniger offensichtlich, aber im Alltag genauso wertvoll: Sie bekommen ein Werkzeug zum Ausprobieren geschenkt. Die Dev UI von Quarkus bringt eine Oberfläche mit, in der Sie Abfragen tippen und sofort das Ergebnis sehen — mit Autovervollständigung, gespeist aus Ihrem eigenen Schema. Das ist ein bemerkenswerter Unterschied zu REST, wo man sich diese Erkundbarkeit erst mit zusätzlichen Werkzeugen dazukauft.

2:09 Und weil alles standardbasiert bleibt, gilt auch hier: kein proprietäres Framework, an das Sie sich binden. Fünf Annotationen, und drei davon tragen die ganze Last. Das Prinzip dahinter ist die Unterscheidung zwischen Lesen und Ändern — GraphQL nennt das Query und Mutation, und diese Trennung ist verbindlich, nicht bloß eine Konvention.

2:29 Anders als bei REST, wo Sie ein GET theoretisch auch etwas verändern lassen könnten, macht GraphQL die Absicht zum Bestandteil der Schnittstelle. Die beiden übrigen Annotationen sind Dokumentation im besten Sinne: Was Sie dort als Beschreibung oder Namen hinterlegen, landet im Schema und erscheint dem Aufrufer in der Oberfläche.

2:48 Das ist die Sorte Dokumentation, die nicht veraltet, weil sie im Code steht.

GraphQL umsetzen

2:53 Bauen wir das für unsere Leistungen. Der Umfang ist überschaubar — eine Erweiterung, zwei Klassen, ein paar Annotationen. Interessanter als der Code selbst ist eine Kleinigkeit, die zunächst nach unnötiger Doppelarbeit aussieht und in Wahrheit eine Sicherheitsentscheidung ist. Achten Sie darauf, wenn wir gleich den Eingabetyp bauen; ich erkläre dort, welchen Fehler diese scheinbare Doppelung strukturell unmöglich macht.

3:17 Eine Erweiterung, zwei Pakete, zwei Klassen — mehr ist es nicht. Der interessante Schritt ist der dritte: ein eigener Typ für die Eingabe, der aussieht wie unsere Entität, aber keine ID hat. Das wirkt nach unnötiger Doppelung, ist aber eine bewusste Trennung, und ich erkläre gleich, warum. Der letzte Schritt ist der, den ich Ihnen ans Herz lege: Probieren Sie es in der Dev UI aus.

3:40 Nicht mit einem Kommandozeilenwerkzeug, nicht mit einem Testskript — einfach die Adresse aufrufen und eine Abfrage tippen. Sie sehen dabei Ihr eigenes Schema und verstehen in fünf Minuten mehr als aus jeder Beschreibung. Hier ist die Begründung für den eigenen Eingabetyp. Wenn Sie Ihre Entität direkt für Eingaben verwenden, kann der Aufrufer eine ID mitschicken — und Sie müssen bei jedem Aufruf daran denken, sie wegzuwerfen.

4:06 Vergessen Sie es einmal, überschreibt jemand einen fremden Datensatz. Ein Typ ohne ID macht diesen Fehler unmöglich, und zwar strukturell, nicht durch Disziplin. Das ist der Unterschied zwischen einer Regel, an die man sich halten muss, und einer, die man nicht brechen kann. Die kleine Methode, die daraus eine Entität baut, hält den Rest sauber: Die Umwandlung steht an einer Stelle, statt in jedem Aufruf einzeln.

4:30 Wenig Code, viel Wirkung. Eine Annotation an der Klasse sagt, dass hier eine GraphQL-Schnittstelle liegt; eine an der Methode macht daraus eine Abfrage. Was Sie dabei nicht tun, ist bezeichnend: Sie schreiben nirgends, welche Felder eine Leistung hat. Das leitet sich aus dem Rückgabetyp ab. Und Sie schreiben auch nicht, welche Felder ausgeliefert werden — das entscheidet der Aufrufer bei jeder Anfrage neu.

4:54 Beachten Sie außerdem, dass hier ein Service dazwischensteht und nicht das Repository direkt. So bleibt die Transaktionsgrenze in der Fachschicht statt in der Schnittstelle — dieselbe Trennung, die wir bei REST schon hatten. Das Gegenstück zum Lesen. Diese Methode ändert etwas, und die Annotation macht das zu einem festen Bestandteil des Schemas — kein Aufrufer kann sich versehentlich darüber täuschen.

5:19 Der Aufruf selbst bleibt kurz, weil die Umwandlung vom Eingabetyp in die Entität dort passiert, wo sie hingehört. Wenn morgen ein Feld dazukommt, ändern Sie eine Stelle und nicht drei. Damit haben Sie das vollständige Muster gesehen: Lesen, Schreiben, Eingabetyp. Alles Weitere ist Wiederholung — und genau das üben Sie jetzt.

GraphQL für Kunde und Anbieter

5:40 Damit kommen wir zur Abschlussaufgabe des Seminars: dasselbe Muster, zwei weitere Entitäten, diesmal ohne Vorlage. Sie haben alle Bausteine gesehen — Eingabetyp, Abfrage, Änderung — und übertragen sie jetzt selbst. Das ist bewusst eine Wiederholung und keine neue Hürde. Wenn Ihre Lösung am Ende beinahe langweilig aussieht, ist das kein Mangel, sondern das Ziel: Ein Muster, das sich zuverlässig wiederholen lässt, ist mehr wert als ein cleverer Einzelfall.

6:08 Sie kennen jetzt alle Bausteine — Eingabetyp, Abfrage, Änderung — und übertragen sie auf Kunde und Anbieter. Das Erfolgskriterium ist bewusst nicht "der Code kompiliert", sondern "es läuft in der Dev UI". Dieser Unterschied ist wichtiger, als er klingt: Eine Schnittstelle, die man nicht ausprobiert hat, ist eine Vermutung.

6:27 Klicken Sie sich durch, schicken Sie eine Abfrage ab, legen Sie einen Datensatz an und holen Sie ihn wieder. Erst dann wissen Sie, dass das Schema stimmt. Nehmen Sie sich die Zeit — es dauert keine fünf Minuten und erspart Ihnen später eine unangenehme Überraschung. Die Lösung ist erwartbar, und das ist ein gutes Zeichen.

6:47 Derselbe Aufbau wie beim Eingabetyp für Leistungen, nur mit anderen Feldern: Ein Anbieter hat einen Namen und eine Mailadresse, eine ID gibt es hier ebenso wenig, und die Umwandlungsmethode arbeitet nach demselben Prinzip. Wenn Ihre Lösung genauso aussieht, haben Sie das Muster verstanden. Genau darum ging es — nicht um Erfindungsreichtum, sondern um Wiedererkennen.

7:08 Gute Architektur zeigt sich daran, dass die zweite und dritte Umsetzung langweilig sind. Zum Abschluss noch ein Detail, das in der Praxis zählt: die Benennung von Parametern. Was Sie dort angeben, erscheint dem Aufrufer im Schema und in der Autovervollständigung. Nehmen Sie sich die Sekunde und schreiben Sie einen Namen hin, den jemand versteht, der Ihren Code nie gesehen hat.

7:31 Damit endet das Seminar inhaltlich fast — halten wir fest: Dieselben Daten, zwei Schnittstellen, beide standardbasiert, und der Aufwand für die zweite war überschaubar. Im letzten Modul werfen wir noch einen Blick darauf, was passiert, wenn es richtig viel Last wird: reaktive Verarbeitung, Messaging und Observability.