Por qué dejé GraphQL después de 6 años

• Después de usarlo durante 6 años desde 2018, fui un verdadero fanático de GraphQL, pero ahora tengo mis dudas
• Quiero explicar por qué ya no recomiendo GraphQL y cuál creo que es una mejor alternativa

Superficie de ataque

• GraphQL expone un lenguaje de consultas, lo que conlleva el riesgo de ampliar la superficie de ataque.
• Los problemas relacionados con la autorización son especialmente importantes.
  • Se necesitan verificaciones de autorización adecuadas para cada campo.
  • En una API REST, es más sencillo verificar los permisos por endpoint.

Autorización

• Hay que comprobar los permisos del usuario para cada campo.
• En una API REST, es más sencillo verificar los permisos por endpoint.

Limitación de velocidad

• Las consultas de GraphQL no tienen un límite de tamaño, por lo que pueden generar una carga muy grande en el servidor.
• Existe la posibilidad de estimar la complejidad de la consulta y limitar las que superen cierto nivel de complejidad.
• En una API REST, es más sencillo limitar la cantidad de solicitudes.

Análisis de consultas

• Una cadena de consulta malformada puede hacer que el servidor use memoria en exceso.
• Hay una forma de detener el análisis estableciendo un número máximo de errores.

Rendimiento

Obtención de datos y problema N+1

• Los resolvers de campos pueden llamar varias veces a fuentes de datos externas.
• Se puede resolver el problema usando el patrón Dataloader.
• En REST, es más sencillo resolver el problema N+1 desde el controlador.

Autorización y problema N+1

• El código de autorización puede provocar el problema N+1.
• En REST, este problema no ocurre.

Acoplamiento

• En un código base de GraphQL, la lógica de negocio queda fuertemente acoplada a la capa de transporte.
• Se necesitan pruebas de integración y es difícil depurar.

Complejidad

• Los distintos métodos para resolver los problemas de seguridad y rendimiento de GraphQL aumentan la complejidad del código base.
• Las soluciones REST por lo general son más simples.

Alternativas

• Se recomienda una API JSON REST que use OpenAPI 3.0+.
• Si hay clientes escritos en un lenguaje con tipos estáticos, OpenAPI puede ser una mejor opción.
• OpenAPI puede generar automáticamente código cliente con seguridad de tipos.

Opinión de GN⁺

• GraphQL es potente, pero requiere mucho esfuerzo para resolver los problemas de seguridad y rendimiento.
• La API REST es relativamente simple y, en muchos casos, puede ser más adecuada.
• OpenAPI puede aumentar la productividad del desarrollo al ofrecer seguridad de tipos y herramientas automatizadas.
• Al adoptar GraphQL, hay que considerar a fondo los problemas de seguridad y rendimiento.
• Es importante comparar las ventajas y desventajas de REST y GraphQL para elegir la tecnología adecuada para el proyecto.

[savvykang]

Por qué dejé de usar GraphQL después de 6 años

[yangeok]

Se viene la era del gran auge del rpc

[ahwjdekf]

Tal cual... no hay que lanzarse de cabeza y entusiasmarse solo porque salió algo fancy... ahora le toca al ORM. Tu turno tampoco está tan lejos...

[rockmkd]

Han pasado más de 20 años desde que apareció el ORM...

[cometkim]

En 2018, PQ ya no era algo tan nuevo (de hecho, se recomendaba desde que GraphQL se anunció por primera vez), así que sorprende que no lo hayan intentado durante 6 años...

[surfindia]

Implementar todo GraphQL a mano es difícil en términos de complejidad y estabilidad por todas las razones mencionadas arriba. Parece mejor desarrollar poniendo una capa como hasura o postgraphile sobre la base de datos, y según sea necesario agregar GraphQL o REST a esta capa.

[GN⁺]

Opiniones de Hacker News

• Después de adoptar GraphQL, pasaron por muchos problemas. Ya no quieren seguir usándolo debido a temas de permisos y rendimiento. Puede ser bueno si se usa solo en el frontend, pero su integración con el backend es compleja.
• Primero aprendieron REST y luego probaron gRPC, y les atrajo la idea de una API con seguridad de tipos. GraphQL no ofrece muchas ventajas y solo resulta útil cuando funciona como una base de datos.
• Trabajaron en dos proyectos con GraphQL; al principio empezaron pequeños, pero con el tiempo se volvieron complejos. Es difícil depurar y aparecen problemas de rendimiento. REST y RPC son más simples y fáciles de mantener.
• Como fundador de Hasura, vio la evolución del uso de GraphQL. GraphQL es muy difícil de construir si no hay una capa de datos. Usar GraphQL sobre REST es ineficiente. El principal caso de uso de GraphQL es cuando hay múltiples consumidores de datos.
• Los ingenieros de frontend guardan las consultas en una biblioteca central y las reutilizan, lo que equivale a usar GraphQL como si fuera REST.
• Por experiencia usando OpenAPI, GraphQL, JSON/HTTP y gRPC, limitar las consultas de GraphQL puede mitigar problemas de rendimiento y seguridad. Buf Connect es el punto medio más adecuado para la mayoría de los proyectos.
• Por la experiencia de usar GraphQL en Facebook, mucha gente no tiene realmente el problema que GraphQL intenta resolver. Facebook usa GraphQL para manejar versionado y modelos de objetos complejos.
• La razón por la que GraphQL funciona bien en Facebook es que todos los usuarios inician sesión y la seguridad está integrada en cada campo. Si hay una SPA y requisitos de inicio de sesión, GraphQL puede ser útil.
• Tras usar GraphQL, al principio parecía bueno, pero al final requirió mucho trabajo adicional y duplicación. Habría sido mejor empezar con endpoints tipo JSON-RPC e ir agregando las funciones necesarias.
• Al usar GraphQL en un proyecto pequeño, casi todo resultó positivo. Usaron Apollo Client y graphql-codegen para generar tipos y funciones para Vue 3. Hubo algunos problemas, pero permitió detectar muchos errores a nivel de tipos.