🙅♀️ Waarom GraphQL niet in de kern van WordPress moet zitten
Update 01/05/2024: Bekijk de vergelijking Gato GraphQL vs WP REST API.
Ja, je hebt die titel goed gelezen. Hoewel ik zelf de maker ben van een GraphQL-server voor WordPress, ben ik van gedachten veranderd over de vraag of WordPress wel met GraphQL zou moeten worden meegeleverd.
Tot niet zo lang geleden geloofde ik dat GraphQL in de kern van WordPress moest zitten. De logica was dat bijdragers tijd en moeite staken in het implementeren van functionaliteit voor de WP REST API (batch-bewerkingen) die van nature aanwezig is in GraphQL.
Maar ik heb de laatste tijd nieuwe informatie gekregen die me aan het denken heeft gezet, en nu geloof ik dat WordPress niet met GraphQL moet worden meegeleverd, vanwege de extra risico's.
Dit zijn mijn redenen.
1. Het voldoet niet aan de 80/20-regel
Historisch gezien wordt bepaalde functionaliteit alleen aan de kern van WordPress toegevoegd als het voldoet aan de 80/20-regel, wat betekent dat 80% of meer van de gebruikers er gebruik van zal maken.
Zou dat het geval zijn met GraphQL? Ik denk van niet, op basis van het precedent van de introductie van de WP REST API in WordPress 4.7.
In zijn lezing WordPress as Data, 5 Years In beschreef K. Adam White (hoofdverantwoordelijke voor de initiële ontwikkeling en release van de WP REST API) dat de bijdragers verwachtten dat de REST API breed gebruikt zou worden zodra die met de kern werd uitgebracht. Maar dat gebeurde niet: ontwikkelaars bleven WordPress-sites op dezelfde manier maken als voorheen, met weinig aandacht voor "headless" of de REST API.
Het tij keerde pas later, met de introductie van de Gutenberg-editor in WordPress 5.0, die was gebaseerd op de REST API. Zou Gutenberg dan de toevoeging van GraphQL aan de kern van WordPress rechtvaardigen?
2. Headless wordt al ondersteund via de REST API
De WordPress-editor kan worden uitgebreid met een native GraphQL-server, zodat blok-ontwikkelaars GraphQL kunnen gebruiken (naast de bestaande REST API) om data op te halen voor hun blokken. Daarnaast kunnen thema's en plugins GraphQL gebruiken voor hun eigen interne functionaliteit. Dit zijn sterke argumenten om GraphQL aan de kern van WordPress toe te voegen.
WordPress heeft echter al de REST API, en wat je met GraphQL kunt doen, kun je ook doen met REST. GraphQL introduceren naast REST is vergelijkbaar met het kopen van een BMW terwijl je al in een Toyota rijdt. Je bereikt je bestemming sneller, en de rijervaring zal aantrekkelijker zijn. Maar beide auto's brengen je waar je naartoe wilt.
Omdat GraphQL geen eerder ontbrekende functionaliteit biedt, is de opname ervan in de kern niet volledig gerechtvaardigd. GraphQL zou de ervaring van het werken met de API zeker verbeteren, maar dat kan prima als plugin-terrein worden beschouwd.
3. WordPress-thema's en -plugins kunnen webonyx/graphql-php gebruiken
Publieke plugins kunnen niet vereisen dat een website WPGraphQL of Gato GraphQL installeert om de plugin te kunnen gebruiken, omdat dat hun potentieel bereik verkleint. Daardoor kunnen publieke plugins niet vertrouwen op GraphQL, en dat is echt jammer.
Ik heb lang over dit probleem nagedacht en bedacht een mogelijke oplossing: de GraphQL API Private, een op zichzelf staande GraphQL-engine die plugins voor eigen gebruik kunnen inbedden, verspreid als een Composer-pakket. (Ik ben nog niet begonnen aan dit project.)
Maar toen werd een paar weken geleden een GraphQL-aangedreven WordPress-plugin uitgebracht. Ik vroeg me af hoe de auteur dat had gedaan: zou het WPGraphQL of Gato GraphQL onder de motorkap gebruiken? Dus ik bekeek de broncode en het blijkt dat die direct webonyx/graphql-php gebruikt!
Dit is een interessante oplossing, die aantoont dat ontwikkelaars met een beetje moeite al toegang hebben tot GraphQL voor hun thema's en plugins.
Deze plugin gebruikt GraphQL om zijn eigen data-entiteiten op te halen, en niet die van WordPress (berichten, gebruikers, reacties, etc.). Daardoor hoeft het GraphQL-schema met het WordPress-datamodel niet opnieuw te worden gemaakt, zoals WPGraphQL en Gato GraphQL doen (en uiteindelijk de GraphQL API Private). Daarom is het gebruik van webonyx/graphql-php zinvol.
4. GraphQL brengt extra risico's met zich mee
De drie bovenstaande punten suggereren dat GraphQL WordPress zou verbeteren, ook al is het niet bijzonder overtuigend. In dat licht zouden we GraphQL toch aan de kern van WordPress kunnen toevoegen, en er ofwel baat bij hebben of er niets van merken.
Maar dit 4e punt suggereert dat als GraphQL niet veel waarde toevoegt aan WordPress, het niet moet worden toegevoegd vanwege de extra risico's.
GraphQL is vatbaar voor de volgende aanvalsvectoren (onder andere):
- Het enkele endpoint biedt toegang tot alle informatie van de website, waardoor privégegevens onbedoeld blootgesteld kunnen worden.
- De queries kunnen zeer complex zijn en de web- en databaseservers kunnen overbelasten.
- Dezelfde mutatie kan meerdere keren in één query worden uitgevoerd, en meerdere queries kunnen samen in één verzoek worden uitgevoerd, waardoor aanvallers kunnen proberen toegang te krijgen tot de back-end door veel combinaties van gebruikersnamen en wachtwoorden te proberen.
Deze aanvallen kunnen echt schadelijk zijn. In zijn presentatie Damn GraphQL - Defending and Attacking APIs slaagde de cybersecurity-onderzoeker Dolev Farhi erin een WordPress-site in minder dan 30 seconden neer te halen, door het WPGraphQL-endpoint aan te vallen met een reeks complexe queries.
Het WPGraphQL-team loste het probleem direct op. Maar hoe kunnen we zeker weten dat er geen ander misbruik mogelijk is? (Ik bedoel niet alleen WPGraphQL, maar ook Gato GraphQL.)
Deze aanvallen kunnen plaatsvinden met GraphQL, en niet met REST, omdat GraphQL krachtiger is dan REST. Terwijl in REST de query vooraf wordt gedefinieerd en op de server wordt opgeslagen, wordt die in GraphQL op runtime door de client aangeleverd (tenzij persisted queries worden gebruikt).
Als website-beheerders nalatig zijn bij het instellen wie toegang heeft tot het endpoint, of welke data er wordt blootgesteld, kunnen er slechte dingen gebeuren. En vanwege de populariteit van WordPress, dat door miljoenen mensen wordt gebruikt die niet technisch onderlegd zijn, zullen slechte dingen hoogstwaarschijnlijk ook daadwerkelijk gebeuren.
Conclusie
Voor alle duidelijkheid: ik pleit er niet voor om GraphQL niet te gebruiken in WordPress (natuurlijk niet!), maar om GraphQL verantwoord te gebruiken. GraphQL is krachtig, wat betekent dat het gevaarlijk is. Wanneer we GraphQL gebruiken, moeten we zeker weten dat we weten wat we doen.
GraphQL meesturen in de kern van WordPress zou het in handen leggen van veel mensen, van wie velen zich niet bewust zijn van de risico's en geen passende maatregelen nemen. Dat is een recept voor een potentiële ramp. En daarom ben ik nu van mening dat dit vermeden moet worden.