3 beneficios de usar GraphQL en tu API que deberías tener en cuenta.
Todos sabemos que las APIs son el nuevo estándar cuando desarrollamos cualquier pieza de software. Todos los enfoques de paradigma más recientes se basan en una cantidad distribuida de componentes creados con un enfoque colaborativo en mente que necesitan trabajar juntos para proporcionar más valor a todo el ecosistema.
Hablando de la parte técnica, una API se ha convertido en sinónimo de usar REST/JSON para exponer esas APIs como un nuevo estándar. Pero esta no es la única opción incluso en el mundo de solicitud/respuesta sincrónica, y estamos comenzando a ver un cambio en esta selección por defecto de REST como la única opción en esta área.
GraphQL ha surgido como una alternativa que también funciona desde que Facebook lo introdujo en 2015. Durante estos cinco años de existencia, su adopción está creciendo fuera de las paredes de Facebook, pero esto todavía está lejos de los usos del público en general, como muestra el siguiente gráfico de Google Trends.
Pero creo que este es un gran momento para volver a mirar los beneficios que GraphQL puede proporcionar a tus APIs en tu ecosistema. Puedes comenzar un nuevo año introduciendo una tecnología que puede proporcionarte a ti y a tu empresa beneficios claros. Así que, echemos un vistazo a ellos.
1.- Estilo más flexible para satisfacer las necesidades de diferentes perfiles de clientes.
Quiero comenzar este punto con un pequeño salto al pasado cuando se introdujo REST. REST no siempre fue el estándar que usamos para crear nuestra API o Servicios Web, como lo llamábamos en ese momento. Un estándar del W3C, SOAP, era el líder de eso, y REST lo reemplaza, enfocándose en varios puntos.
Sin embargo, el peso del protocolo mucho más ligero que SOAP marca la diferencia, especialmente cuando los dispositivos móviles comienzan a ser parte del ecosistema.
Esa es la situación hoy en día, y GraphQL es un paso adicional en ese enfoque y la perspectiva de ser más flexible. GraphQL permite a cada cliente decidir qué parte de los datos les gustaría usar la misma interfaz para diferentes aplicaciones. Cada uno de ellos seguirá teniendo un enfoque optimizado porque pueden decidir qué les gustaría obtener en cada momento.
2.- Enfoque más desacoplado con el proveedor de servicios
Otro tema importante es la dependencia entre el consumidor de la API y el proveedor. Todos sabemos que diferentes paradigmas como los microservicios se centran en ese enfoque. Nuestro objetivo es obtener tanta independencia como sea posible entre nuestros componentes.
REST no proporciona un gran vínculo entre los componentes, eso es cierto. Aun así, la interfaz está fija al mismo tiempo, por lo que eso significa que cada vez que modificamos esa interfaz agregando un nuevo campo o cambiando uno, podemos afectar al consumidor incluso si no necesitan ese campo para nada.
GraphQL, por su característica de seleccionar los campos que me gustaría obtener, facilita mucho la evolución de la API en sí misma y al mismo tiempo proporciona mucha más independencia para los componentes porque solo los cambios que tienen un impacto claro en los datos que un cliente necesita pueden generar un efecto en ellos, pero el resto es completamente transparente para ellos.
3.- Especificación más estructurada y definida
Uno de los aspectos que definió el auge de REST como un protocolo ampliamente utilizado es la falta de estándares para estructurar y definir su comportamiento. Tuvimos varios intentos usando RAML o incluso solo «muestras como especificación», swagger, y finalmente una especificación OpenAPI. Pero ese tiempo de situación «no estructurada» genera que la API REST pueda hacerse de maneras muy diferentes.
Cada desarrollador o proveedor de servicios puede generar una API REST con un enfoque y filosofía diferentes que generan ruido y es difícil de estandarizar. GraphQL se basa en un Esquema GraphQL que define el tipo gestionado por la API y las operaciones que puedes hacer con él en dos grupos principales: consultas y mutaciones. Eso permite que todas las APIs de GraphQL, sin importar quién las esté desarrollando, sigan la misma filosofía ya que está incluida en el núcleo de la especificación en sí.
Resumen
Después de leer este artículo, probablemente estés diciendo, entonces eso significa que debería eliminar toda mi API REST y comenzar a construir todo en GraphQL. Y mi respuesta a eso es… ¡NO!
El objetivo de este artículo es que seas consciente de los beneficios que diferentes formas de definir API te están proporcionando para que puedas agregarlos a tu cinturón de herramientas, así que la próxima vez que crees una API pienses en estos temas descritos aquí y llegues a una conclusión que sea: mmm creo que GraphQL es la mejor opción para esta situación específica o al revés, no voy a obtener ningún beneficio en esta API específica, así que prefiero usar REST.
La idea es que ahora sepas aplicar a tu caso específico y elegir en base a eso porque nadie mejor que tú para decidir qué es lo mejor para tu caso de uso.