🙅‍♀️ Pourquoi GraphQL ne devrait pas être dans le core de WordPress

Oui, vous avez bien lu ce titre. Même si je suis moi-même le créateur d'un serveur GraphQL pour WordPress, j'ai changé d'avis concernant l'opportunité ou non que WordPress soit livré avec GraphQL.

Il n'y a pas si longtemps, je croyais que GraphQL devrait être dans le core de WordPress. La logique était que les contributeurs dépensaient du temps et des efforts à implémenter des fonctionnalités pour la WP REST API (opérations en lot) qui sont natives à GraphQL.

Cependant, j'ai récemment appris de nouvelles informations qui m'ont fait réfléchir, et je crois maintenant que WordPress ne devrait pas être livré avec GraphQL, en raison des risques supplémentaires.

Voici mes raisons.

​

1. Cela ne satisfait pas la règle 80/20

Historiquement, une certaine fonctionnalité n'est ajoutée au core de WordPress que si elle satisfait la règle 80/20, ce qui signifie que 80 % ou plus des utilisateurs l'utiliseront.

Serait-ce le cas avec GraphQL ? Je pense que la réponse est « non », en me basant sur le précédent de l'introduction de la WP REST API dans WordPress 4.7.

Dans sa conférence WordPress as Data, 5 Years In, K. Adam White (principal responsable du développement initial et de la publication de la WP REST API) a décrit que les contributeurs s'attendaient à ce que la REST API soit largement utilisée une fois publiée avec le core. Mais cela ne s'est pas produit : les développeurs ont continué à créer des sites WordPress de la même manière qu'auparavant, en prêtant peu d'attention au « headless » ou à la REST API.

La situation a changé seulement plus tard, avec l'introduction de l'éditeur Gutenberg dans WordPress 5.0, qui était basé sur la REST API. Gutenberg pourrait-il alors justifier l'ajout de GraphQL au core de WordPress ?

​

2. Le headless est déjà satisfait via la REST API

L'éditeur WordPress peut être amélioré avec un serveur GraphQL natif, permettant aux développeurs de blocs d'utiliser GraphQL (en plus de la REST API existante) pour récupérer des données pour leurs blocs. De plus, les thèmes et plugins pourraient utiliser GraphQL pour alimenter leur propre fonctionnalité interne. Ce sont de bonnes raisons d'ajouter GraphQL au core de WordPress.

Cependant, WordPress dispose déjà de la REST API, et tout ce que vous pouvez faire avec GraphQL peut également être fait avec REST. Introduire GraphQL en plus de REST, c'est comme acheter une BMW alors que vous conduisez déjà une Toyota. Vous arriverez à destination plus vite, et l'expérience de conduite sera plus agréable. Mais les deux voitures vous emmèneront là où vous voulez aller.

Comme GraphQL ne fournira pas une fonctionnalité préalablement indisponible, son inclusion dans le core n'est pas pleinement justifiée. GraphQL améliorerait certainement l'expérience d'interaction avec l'API, mais cela pourrait parfaitement être considéré comme relevant du domaine des plugins.

​

3. Les thèmes et plugins WordPress peuvent utiliser webonyx/graphql-php

Les plugins publics ne peuvent pas exiger qu'un site web installe WPGraphQL ou Gato GraphQL pour utiliser le plugin, car cela diminuerait leur portée potentielle. En tant que tel, les plugins publics ne peuvent pas s'appuyer sur GraphQL, et c'est vraiment dommage.

J'ai beaucoup réfléchi à ce problème, et j'ai trouvé une solution potentielle : la GraphQL API Private, un moteur GraphQL autonome que les plugins peuvent intégrer pour leur propre usage, distribué comme un package Composer. (Je n'ai pas encore commencé à travailler sur ce projet.)

Mais ensuite, il y a quelques semaines, un plugin WordPress propulsé par GraphQL a été publié. Je me suis demandé comment l'auteur l'avait fait : utiliserait-il WPGraphQL ou Gato GraphQL sous le capot ? J'ai donc examiné son code source et, il s'avère qu'il utilise directement webonyx/graphql-php !

C'est une solution intéressante, qui démontre qu'avec un peu d'effort, les développeurs ont actuellement accès à GraphQL pour leurs thèmes et plugins.

Ce plugin utilise GraphQL pour récupérer ses propres entités de données, et non celles de WordPress (articles, utilisateurs, commentaires, etc.). Il n'a donc pas besoin de recréer le schéma GraphQL contenant le modèle de données WordPress, comme le font WPGraphQL et Gato GraphQL (et éventuellement la GraphQL API Private). En tant que tel, s'appuyer sur webonyx/graphql-php a du sens.

​

4. GraphQL présente des risques supplémentaires

Les trois problèmes ci-dessus suggèrent que GraphQL améliorerait WordPress, même si ce n'est pas extrêmement convaincant. Dans cette perspective, nous pourrions quand même ajouter GraphQL au core de WordPress, et en bénéficier ou ne rien changer.

Mais ce 4ème problème suggère que, si GraphQL n'apportera pas beaucoup de valeur à WordPress, il ne devrait pas être ajouté, en raison de ses risques supplémentaires.

GraphQL est susceptible aux vecteurs d'attaque suivants (parmi d'autres) :

• Le endpoint unique donne accès à toutes les informations du site web, de sorte que nous pourrions avoir des données privées exposées involontairement.
• Les requêtes peuvent être très complexes et peuvent surcharger les serveurs web et de base de données.
• La même mutation peut être exécutée plusieurs fois dans une seule requête, et plusieurs requêtes peuvent être exécutées ensemble dans une seule demande, permettant aux attaquants de tenter d'accéder au back-end en fournissant de nombreuses combinaisons d'utilisateur/mot de passe.

Ces attaques peuvent être vraiment dommageables. Dans sa présentation Damn GraphQL - Defending and Attacking APIs, le chercheur en cybersécurité Dolev Farhi a réussi à faire tomber un site WordPress en moins de 30 secondes, en attaquant le endpoint WPGraphQL avec un lot de requêtes complexes.

L'équipe WPGraphQL a corrigé le problème immédiatement. Mais comment pouvons-nous être sûrs qu'aucun autre exploit ne peut se produire ? (Je veux dire non seulement WPGraphQL, mais Gato GraphQL aussi.)

Ces attaques peuvent se produire avec GraphQL, et pas avec REST, parce que GraphQL est plus puissant que REST. Alors qu'en REST la requête est définie à l'avance et stockée dans le serveur, en GraphQL elle est fournie à l'exécution par le client (à moins d'utiliser des Persisted queries).

Si les administrateurs de sites web sont négligents dans la configuration de qui peut accéder au endpoint, ou quelles données sont exposées, de mauvaises choses peuvent arriver. Et en raison de la popularité de WordPress, qui est utilisé par des millions de personnes qui ne sont pas expertes en technologie, de mauvaises choses se produiront très probablement.

​

En conclusion

Juste pour être clair : je ne plaide pas pour ne pas utiliser GraphQL dans WordPress (bien sûr que non !), mais pour utiliser GraphQL de manière responsable. GraphQL est puissant, ce qui signifie qu'il est dangereux. Lors de l'utilisation de GraphQL, nous devons nous assurer que nous savons ce que nous faisons.

Livrer GraphQL dans le core de WordPress le mettrait entre les mains de nombreuses personnes, dont beaucoup ne seront pas conscientes de ses risques et ne prendront pas les mesures appropriées. C'est une recette pour un désastre potentiel. Et en tant que tel, c'est maintenant mon opinion, cela devrait être évité.