🙅‍♀️ Por qué GraphQL no debería estar en el core de WordPress

Sí, leíste bien ese título. Aunque yo mismo soy el creador de un servidor GraphQL para WordPress, he cambiado de opinión respecto a si WordPress debería venir con GraphQL o no.

Hasta no hace mucho, creía que GraphQL debería estar en el core de WordPress. La lógica era que los contribuidores estaban gastando tiempo y esfuerzo implementando funcionalidad para la WP REST API (operaciones en bulk) que es nativa de GraphQL.

Sin embargo, recientemente he aprendido información nueva que me hizo pensar de nuevo, y ahora creo que WordPress no debería venir con GraphQL, debido a los riesgos añadidos.

Estas son mis razones.

​

1. No satisface la regla 80/20

Históricamente, cierta funcionalidad se añade al core de WordPress solo si satisface la regla 80/20, lo que significa que el 80 % o más de los usuarios la usarán.

¿Sería ese el caso con GraphQL? Creo que la respuesta es "no", basándome en el precedente de la introducción de la WP REST API en WordPress 4.7.

En su charla WordPress as Data, 5 Years In, K. Adam White (lead principal del desarrollo inicial y release de la WP REST API) describió que los contribuidores esperaban que la REST API se usara ampliamente una vez se lanzase con el core. Pero eso no ocurrió: los desarrolladores siguieron creando sitios WordPress de la misma forma que antes, prestando poca atención a "headless" o a la REST API.

Las fortunas cambiaron solo más tarde, con la introducción del editor Gutenberg en WordPress 5.0, que se basaba en la REST API. ¿Podría entonces Gutenberg justificar la adición de GraphQL al core de WordPress?

​

2. Headless ya se satisface vía la REST API

El editor de WordPress puede mejorarse con un servidor GraphQL nativo, permitiendo a los desarrolladores de bloques usar GraphQL (además de la REST API existente) para obtener datos para sus bloques. Además, themes y plugins podrían hacer uso de GraphQL para potenciar su propia funcionalidad interna. Estas son razones fuertes para añadir GraphQL al core de WordPress.

Sin embargo, WordPress ya tiene la REST API, y lo que sea que puedas hacer con GraphQL también puede hacerse con REST. Introducir GraphQL además de REST es como comprar un BMW cuando ya conduces un Toyota. Llegarás a tu destino más rápido, y la experiencia de conducción será más atractiva. Pero ambos coches te llevarán a donde quieres ir.

Como GraphQL no proporcionará una funcionalidad previamente no disponible, entonces su inclusión en el core no está plenamente justificada. GraphQL ciertamente mejoraría la experiencia de interacción con la API, pero esto podría considerarse perfectamente terreno de plugins.

​

3. Los themes y plugins de WordPress pueden usar webonyx/graphql-php

Los plugins públicos no pueden requerir que un sitio web instale WPGraphQL o Gato GraphQL para usar el plugin, ya que eso disminuirá su alcance potencial. Como tal, los plugins públicos no pueden basarse en GraphQL, y es una verdadera pena.

Pensé mucho sobre este problema, y se me ocurrió una solución potencial: la GraphQL API Private, un motor GraphQL autocontenido que los plugins pueden embeber para su propio uso, distribuido como un paquete Composer. (Todavía no he empezado a trabajar en este proyecto.)

Pero entonces, hace unas semanas, se lanzó un plugin WordPress potenciado por GraphQL. Me pregunté cómo lo hizo el autor: ¿usaría WPGraphQL o Gato GraphQL bajo el capó? Así que comprobé su código fuente y, resulta que, ¡usa directamente webonyx/graphql-php!

Esta es una solución interesante, que demuestra que, con algo de esfuerzo, los desarrolladores actualmente sí tienen acceso a GraphQL para sus themes y plugins.

Este plugin usa GraphQL para obtener sus propias entidades de datos, y no las de WordPress (posts, usuarios, comentarios, etc). Entonces, no necesita recrear el esquema GraphQL que contiene el modelo de datos de WordPress, como hacen WPGraphQL y Gato GraphQL (y eventualmente la GraphQL API Private). Como tal, basarse en webonyx/graphql-php tiene sentido.

​

4. GraphQL presenta riesgos adicionales

Las tres cuestiones anteriores sugieren que GraphQL mejoraría WordPress, aunque no es extremadamente convincente. A esta luz, todavía podríamos añadir GraphQL al core de WordPress, y o bien beneficiarnos de él o no pasa nada.

Pero este 4º problema sugiere que, si GraphQL no añadirá mucho valor a WordPress, entonces no debería añadirse, debido a sus riesgos añadidos.

GraphQL es susceptible a los siguientes vectores de ataque (entre otros):

• El único endpoint proporciona acceso a toda la información del sitio web, por lo que podríamos tener datos privados expuestos involuntariamente.
• Las consultas pueden ser muy complejas y pueden saturar los servidores web y de base de datos.
• La misma mutation puede ejecutarse varias veces en una sola consulta, y se pueden ejecutar varias consultas juntas en una sola petición, permitiendo a los atacantes intentar acceder al back-end proporcionando muchas combinaciones de usuario/contraseña.

Estos ataques pueden ser realmente dañinos. En su presentación Damn GraphQL - Defending and Attacking APIs, el investigador de ciberseguridad Dolev Farhi consiguió tumbar un sitio WordPress en menos de 30 segundos, atacando el endpoint de WPGraphQL con un lote de consultas complejas.

El equipo de WPGraphQL arregló el problema inmediatamente. Pero ¿cómo podemos estar seguros de que no puede ocurrir otro exploit? (Me refiero no solo a WPGraphQL, sino también a Gato GraphQL.)

Estos ataques pueden ocurrir con GraphQL, y no con REST, porque GraphQL es más potente que REST. Mientras que en REST la consulta se define por adelantado y se almacena en el servidor, en GraphQL se proporciona en tiempo de ejecución por el cliente (a menos que se usen Persisted queries).

Si los admins del sitio web son descuidados configurando quién puede acceder al endpoint, o qué datos se exponen, entonces pueden ocurrir cosas malas. Y debido a la popularidad de WordPress, que es usado por millones de personas que no son expertas en tecnología, entonces lo más probable es que ocurran cosas malas.

​

Cerrando

Solo para asegurar: no estoy abogando por no usar GraphQL en WordPress (¡claro que no!), sino por usar GraphQL responsablemente. GraphQL es potente, lo que significa que es peligroso. Al usar GraphQL, necesitamos estar seguros de que sabemos lo que estamos haciendo.

Distribuir GraphQL en el core de WordPress lo pondría en manos de mucha gente, muchos de los cuales no serán conscientes de sus riesgos, y no tomarán las medidas apropiadas. Es una receta para un potencial desastre. Y como tal, es ahora mi opinión, debería evitarse.