GraphQL vs. REST: El Fin del Desperdicio de Datos en las APIs

El problema del desperdicio de datos

Durante más de una década, la arquitectura REST ha sido uno de los estándares más extendidos para construir APIs y comunicar el frontend con el backend. Sin embargo, a medida que las aplicaciones web modernas se volvieron más complejas y el uso de datos móviles se disparó, ciertas limitaciones de REST comenzaron a hacerse notar.

Uno de los desafíos de REST radica en su estructura tradicional. Los datos suelen exponerse a través de endpoints fijos (por ejemplo, /api/usuarios/123). La estructura de la respuesta que devuelve ese endpoint a menudo está predefinida por el servidor, lo que puede generar ineficiencias de rendimiento.

Overfetching (Sobredescarga de datos)

Imaginemos que estamos construyendo una lista de contactos y el frontend solo necesita mostrar el nombre y la foto de perfil de cada usuario.

Al consultar un endpoint clásico de REST, el servidor podría devolvernos el objeto completo del usuario, incluyendo dirección, teléfono, historial de compras y fecha de registro. El navegador termina descargando y procesando un gran volumen de datos (payload) que la interfaz gráfica nunca va a utilizar, desperdiciando ancho de banda. (Aunque cabe aclarar que en REST se pueden implementar parámetros de filtro, esto a menudo requiere desarrollo adicional).

Underfetching (Subdescarga de datos)

El problema inverso ocurre cuando una sola vista necesita datos combinados. Si necesitamos mostrar el perfil del usuario y sus últimos tres pedidos, en una API REST tradicional probablemente tengamos que hacer peticiones HTTP a dos endpoints diferentes (/usuarios/123 y /usuarios/123/pedidos). Esto genera latencia adicional por los múltiples viajes al servidor.

La alternativa: GraphQL

Para brindar una solución estructurada a estos problemas, Facebook creó en 2012 (y abrió al público en 2015) GraphQL. A diferencia del enfoque tradicional de REST, GraphQL cambia el paradigma: la responsabilidad de definir la estructura exacta de los datos pasa del servidor al cliente.

En lugar de tener múltiples endpoints, una API GraphQL expone un único endpoint inteligente. El frontend le envía una consulta (query) escrita en el lenguaje de GraphQL, detallando qué campos necesita.

Si el frontend pide únicamente nombre y foto_perfil, el servidor procesa la solicitud (a través de sus resolvers) y devuelve un objeto JSON que contiene exactamente esos dos campos. Se reducen los datos innecesarios y, además, permite anidar consultas para obtener el usuario y sus pedidos en una sola petición.

GraphQL no vuelve obsoleto a REST. REST sigue siendo una arquitectura excelente, predecible y muy fácil de cachear a nivel de red para la mayoría de los servicios. Sin embargo, en aplicaciones con interfaces dinámicas donde la optimización del payload es vital, la flexibilidad de GraphQL lo convierte en una herramienta invaluable.