Mis impresiones de GraphQL
En estas últimas semanas he estado trabajando en una nueva aplicación de cursos en línea y decidí utilizar GraphQL, principalmente con el objetivo de aprender. En este post quiero plasmar mis impresiones sobre esta tecnología que cada vez adquiere más fuerza.
Nota: si aún no has escuchado o trabajado con GraphQL este no es el post para ti. En ese caso te recomendaría empezar por aprenderlo primero.
Debo decir que GraphQL me pareció un proyecto muy interesante pero no creo que sea un reemplazo de REST.
La parte de consulta me pareció muy innovadora y útil cuando uno necesita consultar información de muchas partes diferentes (ya sean tablas, documentos u otros API’s). En REST es necesario crear endpoints independientes para cada recurso y es posible que desde el frontend se deban hacer varios llamados al servidor.
Algo más que me gustó es la interfaz gráfica que viene incluida llamada GraphiQL, que permite listar y probar los queries y mutations.
Sin embargo, lo de las mutaciones se nota que es algo que agregaron después y que sería mejor haberlo dejado por fuera. Además las mutaciones son una gran lista de métodos sin ningún tipo de agrupación u organización.
El manejo de errores no es muy bueno e incluso he visto muchos proyectos que terminan usando los mismos códigos de respuesta HTTP.
En GraphQL el tema de autorización se vuelve truculento porque puede que alguien consulte recursos a los que no tiene acceso. ¿Devolvemos información parcial? ¿Mostramos un error? GraphQL devuelve los dos pero eso es super confuso. REST nos permite manejar la autorización de forma granular.
GraphQL no tiene versionamiento. Los cambios se deben marcar con deprecated y después definir una fecha en la que se va a remover el campo. No es agradable estar revisando qué marcaron como deprecated y estar actualizando los clientes antes de que remuevan los campos. Sin embargo, esto es algo que pueden implementar relativamente fácil.
El tema del schema me pareció muy interesante y útil para equipos grandes, es una forma de documentación y rigurosidad, pero para proyectos pequeños o personales puede ser una carga adicional (un poco como utilizar TypeScript que realmente tiene sus ventajas y desventajas).
En el fondo lo que menos me gustó de GraphQL es que no hace uso de la semántica del protocolo HTTP, que para un Web API tiene todo el sentido del mundo. Lo que más me gusta de REST es que uno puede reutilizar la lógica de HTTP: los encabezados, los códigos de respuesta, etc.
Personalmente siento que GraphQL podría ser una mejora a REST en los casos en que realmente se necesite algo así: un endpoint que reciba los queries (sin las mutaciones), pero seguir utilizando la autorización y el versionamiento por HTTP.
Yo me imagino en una empresa como Facebook lo difícil que debe ser pedir un nuevo endpoint que traiga información del servidor de varias fuentes y en una estructura definida. En este caso GraphQL tiene todo el sentido del mundo. Sin embargo, para la mayoría de empresas y proyectos crear un nuevo endpoint no es un problema y sí facilita la autorización y el manejo de errores.
Por ejemplo, en mi proyecto tenía que cargar el curriculum del curso que está compuesto de secciones, donde cada sección tiene unas lecciones. Al principio me pareció genial poder crear una query en GraphQL y poder traer las dos cosas al mismo tiempo. Sin embargo, al final pensé que era más fácil crear un endpoint /curriculum que me trajera lo que necesitaba.
GraphQL por debajo siempre hace un POST al servidor con el query en el body porque, en principio, el GET no debería recibir ningún cuerpo. Sin embargo, una mejora a HTTP sería permitir enviar información en el cuerpo GET y que esto también lo tenga en cuenta para el caching.
Otra mejora que podría tener HTTP es tener métodos propios, una de las restricciones que tenemos ahora es que sólo podemos utilizar los métodos por defecto que nos da el protocolo, entonces cuando uno necesita hacer algo diferente aun CRUD (que es la mayoría de casos) le toca agregar la operación en el cuerpo o en la URL. Pero sería útil, por ejemplo, en un sistema de blog tener verbos como DRAFT y PUBLISH.
En conclusión, GraphQL me parece un proyecto muy interesante para un caso de uso muy específico, pero definitivamente no un reemplazo de REST.
Desafortunadamente terminé quitándolo de mi aplicación. Creo que lo utilizaría en una empresa grande donde diferentes equipos me piden información con diferentes estructuras (p.e. un equipo quiere que incluya ciertos campos o recursos anidados, otros me piden otros diferentes, etc.). Sin embargo, no utilizaría las mutaciones, creo que REST sigue siendo una mejor opción.
