Si hay una herramienta que en los últimos años ha causado mucho ruido entre los desarrolladores y desarrolladores de APIs, esta ha sido GraphQL. En este artículo, no pretendo hacer una comparación directa entre GraphQL y otro estilo de arquitectura, como por ejemplo REST, pero nombrar tres de las características de GraphQL que hace que muchos desarrolladores estén dejando a sus estilos de arquitectura de siempre, para adoptar a GraphQL. ¿Es GraphQL la tecnología API del futuro?
¿Qué es GraphQL?
GraphQL es un estándar de código abierto, creado por Facebook, que especifica un método para consultar datos de un servidor. La fuente de estos datos puede ser una base de datos SQL, objetos en un fichero, o una API remota.
¿Quien lo utiliza?
Además de Facebook, AirBnB, Yelp, o GitHub serian otros de los exemplos de organizaciones que ya están utilizando GraphQL en producción.
¿Pero, por qué es GraphQL tan querido por muchos desarrolladores?
1. Permite un rápido desarrollo de tu producto
Uno de los objetivos de GraphQL es facilitar la vida de tus desarrolladores y al mismo tiempo mejorar la productividad de tus equipos. Hay desarrolladores que reclaman porque GraphQL no tiene algunas características que REST tiene de forma nativa. Lo cierto es que bibliotecas como Urql, Relay, Apollo, o GraphQL Faker permiten tener características como el almacenamiento en caché, o interacciones en tiempo real y de forma “fácil”. Esto permite acelerar el desarrollo de tu producto. Con GraphQL, tus desarrolladores frontend pueden incluso diseñar, o hacer cambios en la interfaz de usuario sin tocar código en el backend. ¿Qué te parece? En una API REST necesitas hacer reajustes para que el cliente pueda acceder a los nuevos datos.
2. Pretende acabar con el overfetching y el underfetching
Uno de los temas com más polémica sobre las APIs de REST es que algunas veces generan overfetching, y otras underfetching. Básicamente lo que quieren decir con overfeching es que el cliente está recuperando datos que no son necesarios y esto afecta el rendimiento de la aplicación, como ya hemos comentado otras veces. ¿Si hago una petición de un usuario y solamente quiero su nombre, y email porqué el endpoint tiene que enviarme también su dirección y otros datos personales? - Se preguntaría un programador pro-GraphQl.
Underfetching estaría en el lado opuesto, en que el cliente tiene que hacer peticiones adicionales porque el primer endpoint no ha devuelto la información suficiente.
Si has trabajado en proyectos con APIs REST creo que sabes de lo que estoy hablando. GraphQL también quiere resolver este problema, por eso no se basa en estructuras de datos fijas y permite que sea el cliente a decidir cómo tienen que ser los objetos que devuelva la API.
3. GraphQL usa un esquema fuertemente tipado
Para que no haya problemas en el punto anterior, y porque la mayoría de las APIs hacen lo que quieren con sus operaciones, ya por no hablar sobre la documentación de la API, o el hecho de muchas veces el desarrollador tiene que pelarse contra medio mundo para saber cómo atacar la API, las APIs de GraphQL tienen un esquema fuertemente tipado. Un esquema de GraphQL es la columna vertebral de las APIs de GraphQL. Esta característica es lo que permite definir las operaciones de la API, sus argumentos y sus respuestas. De esta forma, un esquema es un contrato que especifica lo que puede hacer una API. Y no solo eso, su documentación puede ser auto-generada con base en el esquema que define la API.
Conclusión
Para terminar - tienes mucha más información en el sitio web oficial de GraphQL, si no, lo comentamos aquí, pero desde mi punto de vista, es evidente que las limitaciones de REST han dado origen a GraphQL y muchos equipos ven a esta herramienta como aquella alternativa, o solución cuando el tiempo es importante, tu API es un servicio desechable y solamente un cliente la va a consumir. Otros la ven como el futuro de las APIs sobretodo por su flexibilidad y consistencia entre las APIs.
Creo que lo importante, como siempre, es entender los beneficios de los diferentes estilos de arquitectura y sus implicaciones y, como comentamos la semana pasada, diferentes productos pueden requerir diferentes estilos. Siempre dependerá de las necesidades y objetivos del negocio.
¿Crees que GraphQL es la tecnología API del futuro? ¿Te planteas dejar REST o SOAP y usar GraphQL?
Fotografía: Pixabay
Fuentes:
