🙅‍♀️ Warum GraphQL nicht im WordPress-Core sein sollte

Ja, du hast den Titel richtig gelesen. Obwohl ich selbst der Entwickler eines GraphQL-Servers für WordPress bin, habe ich meine Meinung dazu geändert, ob WordPress mit GraphQL ausgeliefert werden sollte oder nicht.

Bis vor Kurzem glaubte ich, dass GraphQL im WordPress-Core sein sollte. Die Logik war, dass Mitwirkende Zeit und Mühe damit verbrachten, Funktionalität für die WP REST API (Batch-Operationen) zu implementieren, die von Natur aus in GraphQL vorhanden ist.

In letzter Zeit habe ich jedoch einige neue Informationen erhalten, die mich zum Nachdenken gebracht haben, und ich glaube jetzt, dass WordPress nicht mit GraphQL ausgeliefert werden sollte, wegen der zusätzlichen Risiken.

Das sind meine Gründe.

​

1. Es erfüllt nicht die 80/20-Regel

Historisch gesehen wird eine bestimmte Funktionalität nur dann zum WordPress-Core hinzugefügt, wenn sie die 80/20-Regel erfüllt, was bedeutet, dass 80% oder mehr der Nutzer sie verwenden werden.

Wäre das bei GraphQL der Fall? Ich denke, die Antwort ist „nein", basierend auf dem Präzedenzfall der Einführung der WP REST API in WordPress 4.7.

In seinem Vortrag WordPress as Data, 5 Years In beschrieb K. Adam White (Hauptverantwortlicher für die anfängliche Entwicklung und Veröffentlichung der WP REST API), dass die Mitwirkenden erwartet hatten, dass die REST API nach ihrer Veröffentlichung mit dem Core weit verbreitet genutzt werden würde. Das geschah jedoch nicht: Entwickler erstellten WordPress-Websites weiterhin auf dieselbe Weise wie zuvor und schenkten „headless" oder der REST API wenig Aufmerksamkeit.

Die Situation änderte sich erst später, mit der Einführung des Gutenberg-Editors in WordPress 5.0, der auf der REST API basierte. Könnte Gutenberg dann die Hinzufügung von GraphQL zum WordPress-Core rechtfertigen?

​

2. Headless ist bereits über die REST API abgedeckt

Der WordPress-Editor kann mit einem nativen GraphQL-Server erweitert werden, sodass Block-Entwickler GraphQL (zusätzlich zur bestehenden REST API) zum Abrufen von Daten für ihre Blöcke verwenden können. Außerdem könnten Themes und Plugins GraphQL nutzen, um ihre eigenen internen Funktionen zu betreiben. Das sind triftige Gründe, GraphQL zum WordPress-Core hinzuzufügen.

WordPress hat jedoch bereits die REST API, und alles, was du mit GraphQL tun kannst, lässt sich auch mit REST erledigen. GraphQL zusätzlich zu REST einzuführen ist so, als würdest du einen BMW kaufen, obwohl du bereits einen Toyota fährst. Du wirst dein Ziel schneller erreichen, und das Fahrerlebnis wird ansprechender sein. Aber beide Autos bringen dich dorthin, wo du hin möchtest.

Da GraphQL keine bisher nicht verfügbare Funktionalität bietet, ist seine Aufnahme in den Core nicht vollständig gerechtfertigt. GraphQL würde zwar die Erfahrung bei der Interaktion mit der API verbessern, aber das könnte problemlos als Plugin-Bereich betrachtet werden.

​

3. WordPress-Themes und Plugins können webonyx/graphql-php verwenden

Öffentliche Plugins können nicht verlangen, dass eine Website WPGraphQL oder Gato GraphQL installiert, um das Plugin zu nutzen, da das ihre potenzielle Reichweite verringern würde. Daher können öffentliche Plugins sich nicht auf GraphQL verlassen, was wirklich schade ist.

Ich habe lange über dieses Problem nachgedacht und eine mögliche Lösung gefunden: die GraphQL API Private, eine eigenständige GraphQL-Engine, die Plugins für ihre eigene Verwendung einbetten können, verteilt als Composer-Paket. (Ich habe noch nicht mit der Arbeit an diesem Projekt begonnen.)

Dann jedoch wurde vor einigen Wochen ein GraphQL-betriebenes WordPress-Plugin veröffentlicht. Ich fragte mich, wie der Autor das gemacht hatte: Würde es WPGraphQL oder Gato GraphQL unter der Haube verwenden? Also schaute ich mir den Quellcode an, und wie sich herausstellte, verwendet es direkt webonyx/graphql-php!

Das ist eine interessante Lösung, die zeigt, dass Entwickler mit etwas Aufwand derzeit Zugang zu GraphQL für ihre Themes und Plugins haben.

Dieses Plugin verwendet GraphQL, um seine eigenen Datenentitäten abzurufen, und nicht die von WordPress (Beiträge, Nutzer, Kommentare usw.). Daher muss es das GraphQL-Schema, das das WordPress-Datenmodell enthält, nicht neu erstellen, wie es WPGraphQL und Gato GraphQL tun (und letztendlich die GraphQL API Private). Daher macht es Sinn, sich auf webonyx/graphql-php zu verlassen.

​

4. GraphQL birgt zusätzliche Risiken

Die drei oben genannten Punkte legen nahe, dass GraphQL WordPress verbessern würde, auch wenn es nicht extrem überzeugend ist. Vor diesem Hintergrund könnten wir GraphQL trotzdem zum WordPress-Core hinzufügen und entweder davon profitieren oder es ändert sich nichts.

Aber dieser 4. Punkt legt nahe, dass GraphQL nicht hinzugefügt werden sollte, wenn es WordPress keinen großen Mehrwert bringt, wegen seiner zusätzlichen Risiken.

GraphQL ist anfällig für folgende Angriffsvektoren (unter anderem):

• Der einzelne Endpunkt bietet Zugriff auf alle Informationen der Website, sodass private Daten unbeabsichtigt offengelegt werden könnten.
• Die queries können sehr komplex sein und die Web- und Datenbankserver überlasten.
• Dieselbe Mutation kann mehrmals in einer einzigen query ausgeführt werden, und mehrere queries können zusammen in einer einzigen Anfrage ausgeführt werden, was es Angreifern ermöglicht, durch viele Kombinationen von Nutzer/Passwort Zugang zum Back-End zu erlangen.

Diese Angriffe können wirklich schädlich sein. In seiner Präsentation Damn GraphQL - Defending and Attacking APIs gelang es dem Cybersicherheitsforscher Dolev Farhi, eine WordPress-Website in weniger als 30 Sekunden zum Absturz zu bringen, indem er den WPGraphQL-Endpunkt mit einem Batch komplexer queries angriff.

Das WPGraphQL-Team behob das Problem sofort. Aber wie können wir sicher sein, dass kein weiterer Exploit stattfinden kann? (Ich meine nicht nur WPGraphQL, sondern auch Gato GraphQL.)

Diese Angriffe können mit GraphQL passieren, nicht aber mit REST, weil GraphQL mächtiger als REST ist. Während in REST die query im Voraus definiert und auf dem Server gespeichert wird, wird sie in GraphQL zur Laufzeit vom Client bereitgestellt (es sei denn, man verwendet persisted queries).

Wenn Website-Admins bei der Konfiguration nachlässig sind, wer auf den Endpunkt zugreifen kann oder welche Daten offengelegt werden, können schlimme Dinge passieren. Und aufgrund der Popularität von WordPress, das von Millionen von Menschen genutzt wird, die nicht technikaffin sind, werden schlimme Dinge höchstwahrscheinlich passieren.

​

Fazit

Nur um sicherzugehen: Ich plädiere nicht dafür, GraphQL in WordPress nicht zu verwenden (natürlich nicht!), sondern dafür, GraphQL verantwortungsvoll einzusetzen. GraphQL ist mächtig, was bedeutet, dass es gefährlich ist. Wenn wir GraphQL verwenden, müssen wir sicherstellen, dass wir wissen, was wir tun.

GraphQL im WordPress-Core auszuliefern würde es in die Hände vieler Menschen legen, von denen viele sich seiner Risiken nicht bewusst sein und keine angemessenen Maßnahmen ergreifen werden. Das ist ein Rezept für ein potenzielles Desaster. Und daher bin ich jetzt der Meinung, dass es vermieden werden sollte.