GraphQL es algo molesto

• GraphQL es excelente, pero parece un poco sobrevalorado
• Parece que los desarrolladores principiantes e intermedios terminan usando GraphQL por lo que ven en YouTube, y eso parece un error
• Ventajas
  • Permite describir fácilmente los datos que quieres
  • Ahorra ancho de banda. Puedes traer de una vez exactamente lo que quieres
  • Es fácil crear documentación para los consumidores de datos
  • Permite usar suscripciones más fácilmente
  • Hace posible agrupar llamadas a la API
• Desventajas
  • En la práctica es doloroso de usar. Según el backend que uses, si no te genera los tipos en tu lenguaje, tendrás que mantener dos o más sistemas de tipos
  • No soporta mapas/tablas/diccionarios. Esto es realmente importante. Aunque no quieras, en algún lado terminas usando {[key: string]: T}
  • No hay una forma clara de versionar la API. Al final terminas con cosas como MyQueryV1.01, MyQueryV1.02, MyQueryV1.03
• Si no estás resolviendo el conjunto de problemas/soluciones para el que Facebook pensó GraphQL, no uses GraphQL
• ¿Qué otras palabras sabias podrían compartir los desarrolladores senior para salvar a los juniors de caer en este pantano?

Comentarios de HN

• El mayor problema de GraphQL es que tienes que trabajar para defenderte de ataques DOS o de gente que intenta descargarse toda tu base de datos.
  • Es muy fácil crear consultas que pongan una carga excesiva sobre tu sistema.
  • Si quieres ver qué tipo de cosas hay que hacer, mira a Shopify. Aplican rate limits según la cantidad de datos devueltos y también manejan cursores y paginación. A diferencia de los bonitos ejemplos de GraphQL que se ven en internet, el esquema es enorme y feo
• GraphQL es una gran forma de resolver problemas organizacionales que tienen las grandes empresas tecnológicas
  • Por ejemplo, cuando el equipo que mantiene la API es distinto del equipo que pide cambios
  • Si la organización es grande, en esos casos podrías esperar una eternidad para hacer un cambio, y GraphQL reduce esa necesidad
  • Si tu organización es pequeña, ¿no sería mejor simplemente implementar tú mismo lo que hace falta?
• Intencionalmente o no, GraphQL permite que los desarrolladores frontend se desacoplen de sus dependencias hacia los desarrolladores backend y avancen más rápido
  • El desarrollador backend crea el modelo de datos y lo expone con GraphQL, y luego un desarrollador frontend que nunca ha conocido a ese backend puede usarlo de inmediato
  • Puede cambiar sobre la marcha lo que consulta y obtener lo que necesita
  • Hace que todos se muevan más rápido
  • Pero yo, como desarrollador backend, realmente odio GraphQL

[bichi]

GraphQL es medio molesto. Bueno, no tan molesto; sí fastidia un poco, pero como definitivamente reduce el costo de comunicación entre el equipo, es más eficiente usar ese tiempo para resolver las partes molestas. Y además, de verdad es feísimo. Aun así, yo recomiendo usar GraphQL. Porque nadie va a estar de acuerdo con eso de usar tRPC. La mayoría de la gente ni siquiera lo ha usado bien y rechaza una tecnología por pura suposición; y para resolver eso habría que imponerlo con muchísimo poder. Con una o dos tecnologías quizá se puede, pero si intentas imponer todo, terminas perdiendo más de lo que ganas, así que no se puede... Entonces, al final, lo más persuasivo que se puede lograr es GraphQL, snif snif. REST de porquería, esta sí que es una tecnología paleolítica horrible que de verdad genera un costo de comunicación enorme, snif snif.

[alucard]

Es la primera vez que un post de GeekNews me hace registrarme. Respondí en la parte de The bad.

Puede haber pros y contras desde la perspectiva del cliente y del servidor por separado, pero viéndolo en conjunto, incluso sabiendo que la mayor value proposition es que el esquema de GraphQL llena esa capa de abstracción faltante entre el servidor y el cliente, personalmente decir que en un producto general se consideraría REST me suena un poco a una conversación de otra época.
The bad

• It is actually a pain to use, depending on the backend you are using you'll have to manage
  two or more type systems if there are no code first generates in your language
  Al final, dicho de otra manera, ¿si se usa bien está bueno? code generation y esas cosas ya ni siquiera son un problema hoy en día; mira cuánto ha avanzado el tooling.
• It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be
  some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere
  También se menciona en Production Ready, pero si aprovechas las ventajas del Type System, parece que no hace falta preocuparse demasiado por esto. En vez de key: string, basta con especificar los campos exactos...
• No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
  GraphQL originalmente es versionless....
  Don't use Graphql unless you're managing a solution/problem set that facebook intended graphql for Invest your time in a simpler solution then running to GraphQL first
  Suena como decir que tampoco uses React a menos que estés resolviendo los problemas que Facebook quería resolver.

[bichi]

Hola, buen comentario. ¿Podríamos mantenernos en contacto? Necesito gente que piense igual. Es muy difícil convencer a otras personas (miembros del equipo).

[alucard]

Jajaja, vi el comentario tarde..!! En el Slack de GraphQL Korea uso el apodo Alucard :)

[sixmen]

Adopté GraphQL relativamente temprano, pero en ese momento había muchas explicaciones enfocadas en el backend. Por eso, creo que se generó la percepción de que sería algo bueno para el backend.

Después de batallar y probar de todo un poco, cuando la gente que llegó después a la empresa o quienes están en entrevista me preguntan, suelo explicarlo así: para el backend es pesado, pero para el frontend es bueno. :)

[bbulbum]

#Pero como desarrollador de backend, realmente odio GraphQL
Te entiendo..

[ifmkl]

Eso de usar cada cosa donde corresponde es exactamente lo que se me viene a la mente.

[kbumsik]

Sea intencional o no, GraphQL permite que los desarrolladores frontend se desacoplen de las exigencias hacia los desarrolladores backend y avancen más rápido.

Esa es la razón para usar GraphQL. En la especificación de GraphQL también se indica explícitamente que es para el frontend 1
Yo también empecé a usar GraphQL en una nueva startup, y definitivamente siento que ahora tengo que comunicarme menos veces con los ingenieros frontend por temas de la API que antes.

Antes de usar GraphQL de verdad, había problemas que ni siquiera imaginaba, y desde la perspectiva de un ingeniero backend sí puede ser algo doloroso, pero aun así me parece mucho mejor que romperse la cabeza intentando diseñar bien una REST API.

[hwasurr]

¡Ninguna tecnología es perfecta! Creo que vale la pena adoptarla si realmente necesitas esa tecnología o si resuelve otro problema más grande, al punto de justificar el costo de lidiar con sus desventajas. La idoneidad de una tecnología o herramienta siempre depende de la situación de quien la usa.

Por otro lado, también me da la impresión de que una de las razones por las que GraphQL recibe tantas críticas es que vende, por decirlo de algún modo, una imagen de que “es fácil”.

[jjpark78]

Recuerdo que al principio, cuando salió GraphQL y avanzábamos con un proyecto POC, no había motores que soportaran bien multipart, así que fue una experiencia complicada..

[gjen6s]

Yo también desde antes, cada vez que veía que usaban GraphQL en proyectos pequeños, pensaba mucho algo como: ¿no será esto demasiado overkill?.. Parece que todos pensamos parecido.

[xguru]

Solo trasladé los comentarios iniciales. Hay más de 400 comentarios, así que es difícil incluso leerlos todos.