Apollo, GraphQL, y cómo Redux me arruga la ropa

Hace año y chirolas que día a día laburo con React, Redux y compañía. Soy mucho más feliz, meter un feature modificando un reducer es mágico, pero para ser honesto siempre me hizo un poco de ruido el manejo de side effects.

Seguramente el problema sea que nunca lo terminé de entender del todo, pero me sigue sin cerrar que todos aceptemos que entender thunk y/o sagas sea un requerimiento para poder pegarle a un server en el stack más usado hoy en día.

Por esto mismo, quedé como el fan de Wanda cuando implementé por primera vez Apollo Client con React en la página de Tienda de Bombas (sí, me pagan con comida). De repente, dos de las cosas más tediosas y a la vez más importantes de mi aplicación, data fetching y mantenimiento del store, estaban resueltas.

Bancá. ¿Apollo? ¿GraphQL?

✋ Mala mía. GraphQL es una tecnología que permite que, dado un servidor GraphQL que expone un esquema, los clientes que se conecten a éste puedan ser ellos los responsables de decidir qué data pedir a través de una query con una sintaxis específica. Es la mayor diferencia contra una arquitectura REST, donde el servidor expone recursos que no necesariamente cumplen con los requerimientos de la vista (custom endpoints, sos vos?).

Apollo, por su parte, es un stack completo para JS compuesto por herramientas para crear un servidor de GraphQL (graphql-tool), un servidor standalone (graphql-server), y un cliente compatible con todos los frameworks de frontend (apollo-client).

Además, está impulsado por la misma gente que lleva adelante Meteor, donde la developer experience fue algo que siempre se destacó. La API simple de Apollo (en comparación a Relay) es un claro ejemplo de que sigue siendo una prioridad.

Data fetching

Apollo se encarga de mantener un store de Redux con la data actualizada de tus entidades en el cliente. De tu parte, simplemente tenés que declarar una query pidiendo la información que necesitás para tu componente.

Me estás jodiendo. ¿Un solo archivo? Sep, aunque usted no lo crea. Este componente, al pasar por el HOC de Apollo, va a pedir la data que le declaramos en la query (id, title y description de cada producto) y podemos asumir que nuestro componente la va a recibir si no hubo ningún error en la respuesta del servidor. Incluso tenemos un flag para saber si el request está en progreso (entre otras cosas), y mostrar un hermoso h1.

Mantenimiento del store

No es trivial el trabajo de mantener un store de Redux como si fuese una base de datos en el cliente. Incluso con librerías como normalizr la cosa sigue algo lejos de amigable para la comunidad. Empezamos poniendo redux para manejar el estado de nuestra aplicación, y terminamos implementando una DB con entidades relacionadas. ¯\_(ツ)_/¯

Con Apollo, sólo definís cómo se relacionan tus entidades una sola vez, en el esquema de tu servidor GraphQL (donde tiene más sentido) y en el cliente podés delegar este trabajo a Apollo. Incluso, desde hace algunas versiones, también te permite acceder al store que genera y modificarlo si lo creés necesario.

Conclusión

GraphQL, en conjunto con Apollo, nos permiten posponer la implementación de Redux hasta que realmente necesitemos usarlo para manejar el estado de la aplicación, y no de nuestros datos. Ahí es donde creo que sí se luce la simpleza de los actions y reducers.

Apollo está ganando terreno y desafiando a Relay como el cliente de GraphQL para JS, y gran parte de ese éxito es por su simpleza. 💪

No se trata de soluciones mágicas, sino de delegar para avanzar más rápido en lo que sea que realmente haga tu aplicación. GraphQL, por su flexibilidad en las queries y la firmeza de su tipado, habilita este tipo de herramientas y hace que la magia sea previsible.

Si todavía no te metiste en el mundo de GraphQL y tenés ganas, sumate a GraphQL Buenos Aires y al Slack de MeetupJS para enterarte cuando nos juntemos a aprender más. 👋