🙅‍♀️ Perché GraphQL non dovrebbe essere nel core di WordPress

Sì, hai letto bene il titolo. Anche se sono io stesso il creatore di un server GraphQL per WordPress, ho cambiato idea riguardo all'opportunità o meno che WordPress venga distribuito con GraphQL.

Fino a non molto tempo fa, credevo che GraphQL dovesse essere nel core di WordPress. La logica era che i contributori stavano spendendo tempo ed energie per implementare funzionalità per la WP REST API (operazioni in batch) che sono native in GraphQL.

Tuttavia, di recente ho appreso alcune nuove informazioni che mi hanno fatto riflettere, e ora credo che WordPress non dovrebbe essere distribuito con GraphQL, a causa dei rischi aggiuntivi.

Queste sono le mie ragioni.

​

1. Non soddisfa la regola dell'80/20

Storicamente, una determinata funzionalità viene aggiunta al core di WordPress solo se soddisfa la regola dell'80/20, il che significa che l'80% o più degli utenti la utilizzerà.

Sarebbe questo il caso di GraphQL? Penso che la risposta sia "no", basandomi sul precedente dell'introduzione della WP REST API in WordPress 4.7.

Nel suo intervento WordPress as Data, 5 Years In, K. Adam White (principale responsabile dello sviluppo iniziale e del rilascio della WP REST API) ha descritto che i contributori si aspettavano che la REST API venisse ampiamente utilizzata una volta rilasciata con il core. Ma ciò non è accaduto: gli sviluppatori hanno continuato a creare siti WordPress nello stesso modo di prima, prestando poca attenzione al "headless" o alla REST API.

La situazione è cambiata solo più tardi, con l'introduzione dell'editor Gutenberg in WordPress 5.0, che era basato sulla REST API. Gutenberg potrebbe quindi giustificare l'aggiunta di GraphQL al core di WordPress?

​

2. Il headless è già soddisfatto tramite la REST API

L'editor di WordPress può essere migliorato con un server GraphQL nativo, consentendo agli sviluppatori di blocchi di utilizzare GraphQL (oltre alla REST API esistente) per recuperare i dati per i loro blocchi. Inoltre, temi e plugin potrebbero utilizzare GraphQL per alimentare le proprie funzionalità interne. Queste sono valide ragioni per aggiungere GraphQL al core di WordPress.

Tuttavia, WordPress dispone già della REST API, e tutto ciò che puoi fare con GraphQL può essere fatto anche con REST. Introdurre GraphQL oltre a REST è come comprare una BMW quando si guida già una Toyota. Arriverai a destinazione più velocemente, e l'esperienza di guida sarà più piacevole. Ma entrambe le auto ti porteranno dove vuoi andare.

Poiché GraphQL non fornirà una funzionalità prima non disponibile, la sua inclusione nel core non è pienamente giustificata. GraphQL migliorerebbe certamente l'esperienza di interazione con l'API, ma questo potrebbe essere perfettamente considerato di competenza dei plugin.

​

3. I temi e i plugin di WordPress possono utilizzare webonyx/graphql-php

I plugin pubblici non possono richiedere che un sito web installi WPGraphQL o Gato GraphQL per utilizzare il plugin, poiché ciò ne ridurrebbe la potenziale diffusione. Pertanto, i plugin pubblici non possono fare affidamento su GraphQL, ed è davvero un peccato.

Ho riflettuto a lungo su questo problema, e ho trovato una potenziale soluzione: la GraphQL API Private, un motore GraphQL autonomo che i plugin possono integrare per il proprio uso, distribuito come pacchetto Composer. (Non ho ancora iniziato a lavorare su questo progetto.)

Ma poi, alcune settimane fa, è stato rilasciato un plugin WordPress alimentato da GraphQL. Mi sono chiesto come l'autore l'avesse fatto: avrebbe usato WPGraphQL o Gato GraphQL sotto il cofano? Ho quindi esaminato il suo codice sorgente e, a quanto pare, utilizza direttamente webonyx/graphql-php!

Questa è una soluzione interessante, che dimostra che, con un po' di impegno, gli sviluppatori hanno attualmente accesso a GraphQL per i loro temi e plugin.

Questo plugin utilizza GraphQL per recuperare le proprie entità di dati, e non quelle di WordPress (articoli, utenti, commenti, ecc.). Quindi non ha bisogno di ricreare lo schema GraphQL contenente il modello di dati di WordPress, come fanno WPGraphQL e Gato GraphQL (ed eventualmente la GraphQL API Private). Pertanto, fare affidamento su webonyx/graphql-php ha senso.

​

4. GraphQL presenta rischi aggiuntivi

I tre problemi sopra suggeriscono che GraphQL migliorerebbe WordPress, anche se non in modo estremamente convincente. In quest'ottica, potremmo comunque aggiungere GraphQL al core di WordPress, e trarne beneficio o non cambiare nulla.

Ma questo 4° problema suggerisce che, se GraphQL non apporterà molto valore a WordPress, allora non dovrebbe essere aggiunto, a causa dei suoi rischi aggiuntivi.

GraphQL è suscettibile ai seguenti vettori di attacco (tra gli altri):

• L'endpoint unico fornisce accesso a tutte le informazioni del sito web, quindi potremmo avere dati privati esposti involontariamente.
• Le query possono essere molto complesse e possono sovraccaricare i server web e di database.
• La stessa mutation può essere eseguita più volte in una singola query, e più query possono essere eseguite insieme in una singola richiesta, permettendo agli attaccanti di tentare di accedere al back-end fornendo molte combinazioni di utente/password.

Questi attacchi possono essere davvero dannosi. Nella sua presentazione Damn GraphQL - Defending and Attacking APIs, il ricercatore di cybersicurezza Dolev Farhi è riuscito a far cadere un sito WordPress in meno di 30 secondi, attaccando l'endpoint WPGraphQL con un batch di query complesse.

Il team di WPGraphQL ha corretto il problema immediatamente. Ma come possiamo essere sicuri che nessun altro exploit possa verificarsi? (Intendo non solo WPGraphQL, ma anche Gato GraphQL.)

Questi attacchi possono verificarsi con GraphQL, e non con REST, perché GraphQL è più potente di REST. Mentre in REST la query è definita in anticipo e memorizzata nel server, in GraphQL viene fornita a runtime dal client (a meno di non usare le persisted queries).

Se gli amministratori dei siti web sono negligenti nel configurare chi può accedere all'endpoint, o quali dati vengono esposti, possono accadere cose brutte. E a causa della popolarità di WordPress, che è utilizzato da milioni di persone non esperte di tecnologia, le cose brutte si verificheranno molto probabilmente.

​

Conclusione

Solo per essere chiari: non sto sostenendo di non usare GraphQL in WordPress (ovviamente no!), ma di usare GraphQL in modo responsabile. GraphQL è potente, il che significa che è pericoloso. Quando usiamo GraphQL, dobbiamo assicurarci di sapere cosa stiamo facendo.

Distribuire GraphQL nel core di WordPress lo metterebbe nelle mani di molte persone, molte delle quali non saranno consapevoli dei suoi rischi e non prenderanno le misure appropriate. È una ricetta per un potenziale disastro. E pertanto, è ora la mia opinione, dovrebbe essere evitato.