Muchas veces, cuando utilizas REST en tus integraciones, te encuentras con algunas limitaciones, ya sea en el backend o en el frontend. Estas limitaciones te hacen pensar en utilizar otros estilos de arquitectura, u otras soluciones, simplemente para no estropear la esencia del REST. ¿Una de estas soluciones podría ser GraphQL? ¿Por qué no?

¿Qué es el GraphQL?

GraphQL es un estándar de código abierto, creado por Facebook, que especifica un método para consultar datos de un servidor. Lo cierto es que la fuente de estos datos puede ser lo que quieras: base de datos SQL, objetos en un fichero, una API remota, etc.

La definición oficial dice que “GraphQL es un lenguaje de consulta diseñado para desarrollar aplicaciones cliente  proporcionando una sintaxis y un sistema intuitivos y flexibles para describir sus necesidades de datos e interacciones.

GitHub, Paypal, o SKY son algunas de las empresas, además de Facebook, obviamente, que utilizan GraphQL.

¿Cómo funciona?

En GraphQL la forma de la consulta informa al servidor como montar el contenido de la respuesta para que el cliente reciba solamente los datos que ha pedido.

Muy resumidamente, en GraphQL puedes decirle al servidor como quieres que sea el documento de respuesta, qué datos contiene y cómo está estructurado el JSON y el servidor te lo retorna “exactamente”. ¿Interesante, no?

¿Un ejemplo?

Imagina que quieres “los jugadores con posición de delantero, y además quieres ver la posición, su número y el nombre del jugador”.

Tu consulta sería algo así:

query($posicion: string){
	jugadores(posicion: $posicion){
		posicion
			camiseta{
				numero
				nombre
			}
		}
	}
}

{"posicion" : "delantero"}


{"data" : {
	"jugadores": [
		{
			"posicion": "delantero",
			"camiseta": {
				"numero": 10,
				"nombre": "Messi"
			}
		}
		]
	}
}

¿Pero, es GraphQL una alternativa a REST, o a SOAP por ejemplo? ¿O pueden complementarse?

Antes de responder a la pregunta, te comento que puedes utilizar GraphQL con frameworks como Symfony, Express o lenguajes de programación como Elixir. Miremos un momento por qué sería buena idea utilizar GraphQL.

1. Petición a la API por página

En REST, por ejemplo, es común hacer una petición a la API y posteriormente otra(s) para recuperar los datos adicionales. Por ejemplo si quieres los datos del jugador y después los datos de su equipo.  Con GraphQL la idea es que hagas una consulta con todos los campos que necesites y que el servidor te devuelva todo. De esta forma evitas múltiples peticiones para obtener lo mismo.

2. Mayor velocidad

Como hemos dicho antes, el cliente solo pide lo que necesita, entonces los paquetes son menores, lo que debería significar mayor velocidad. :) :)

3. Limpieza de datos

Si has trabajado con REST, sabes que algunas veces las cosas se pueden poner feas, o poco limpias debido a que tu cliente cree que necesita aquella implementación, pero no eres capaz de negociar, o convencerle de los límites de la herramienta.

La idea de GraphQL es la limpieza de los datos, en que las consultas idénticas deben retornar respuestas idénticas y que al mismo tiempo sea posible representar los datos con JSON.

Un modelo típico de GraphQL define una consulta con determinados campos y argumentos. Los campos que no están, no aparecen.

¿Cuál es el problema de GraphQL?

A pesar de todo esto, no todo es tan maravilloso con GraphQL y hay algunas razones por las cuales muchos profesionales, o organizaciones no se han decidido aún por el lenguaje.

Caché

Uno de estos problemas es que siempre que hagas una consulta debes recordar especificar lo que quieres. Por otro lado, GraphQL hablando de caché, no tiene una estructura de URLs que se puedan utilizar como identificador global único para que el cliente la aproveche de forma a construir una caché. Tendrías que utilizar otras técnicas, o herramientas como Relay para el mismo efecto.

Seguridad

La idea de que “peticiones idénticas deben retornar respuestas idénticas” me parece interesante. Pero, al mismo tiempo el sistema puede quedar abierto a ataques DDoS o “consultas caras” que pueden hacer caer tu servidor. Así que debes que tener mucho cuidado con las joins, por ejemplo, ya que si el cliente debe conocer el modelo de datos para hacer la petición, esto puede significar exponer tu estructura interna de datos. Otro problema es la monitorización de errores: puedes leer aquí o aquí algunas soluciones de como hacerlo de forma óptima.

Conclusión

En suma, es cierto que GraphQL ya existe desde hace algunos años, pero creo que su versión estable aún no es lo suficientemente madura. Hay mucho ruido sobre la herramienta - y otras parecidas - sin embargo, desde mi punto de vista es un ecosistema joven con algunos temas por resolver, pero con mucho potencial.

Hacer una comparación con REST, recordando siempre que REST es un estilo de arquitectura, no un estándar, tendría sentido a la hora de escoger entre rendimiento, eficiencia para objetos complejos y confiabilidad.

Como siempre, lo correcto será analizar bien los requerimientos del proyecto. Si tu cliente quiere realmente hacer una migración de una API existente a la API de GraphQL, hay que tener en cuenta este tipo de detalles, y ponderar que hay aplicaciones en que las tiene sentido utilizar GraphQL y otras en que GraphQL es solamente una herramienta más en tu caja de herramientas sin tener, necesariamente, que sustituir a REST.

¿Utilizas GraphQL en tus proyectos? ¿Cómo es tu experiencia?

Fuentes: