GraphQL vs. REST: El Fin del Desperdicio de Datos en las APIs
Durante más de una década, la arquitectura REST ha sido el estándar indiscutido 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ó, las limitaciones de REST comenzaron a afectar el rendimiento.
El principal problema de REST radica en su rigidez. En esta arquitectura, los datos se exponen a través de endpoints fijos (por ejemplo, /api/usuarios/123). La estructura de la respuesta que devuelve ese endpoint está predefinida por el servidor, lo que genera dos problemas críticos de rendimiento.
Overfetching (Sobredescarga de datos)
Imaginá que estás construyendo una lista de contactos y el frontend solo necesita mostrar el nombre y la foto de perfil de cada usuario.
Al consultar el endpoint de REST, el servidor no puede filtrar la respuesta. Te devolverá el objeto completo del usuario, incluyendo su dirección, teléfono, historial de compras, fecha de registro y tokens de sesión. El navegador termina descargando y procesando una gran cantidad de datos (payload) que la interfaz gráfica nunca va a utilizar, desperdiciando ancho de banda y memoria.
Underfetching (Subdescarga de datos)
El problema inverso ocurre cuando una sola vista de la aplicación necesita datos combinados. Si necesitás mostrar el perfil del usuario y sus últimos tres pedidos, en REST probablemente tengas que hacer dos peticiones HTTP distintas a dos endpoints diferentes (/usuarios/123 y /usuarios/123/pedidos). Esto genera latencia adicional por los múltiples viajes de ida y vuelta al servidor.
La Solución: GraphQL
Para resolver estos problemas de ineficiencia, Facebook desarrolló GraphQL. A diferencia de REST, GraphQL cambia por completo el paradigma de comunicación: la responsabilidad de definir la estructura 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 a este endpoint una consulta (query) escrita en un lenguaje específico, detallando exactamente los campos que necesita.
Si el frontend pide únicamente nombre y foto_perfil, el servidor procesa la solicitud y devuelve un objeto JSON que contiene milimétricamente esos dos campos. Ni un byte de más, ni un byte de menos. Además, permite anidar consultas, obteniendo los datos del usuario y sus pedidos en una sola petición HTTP.
Conclusión
GraphQL no hace que REST sea obsoleto. REST sigue siendo una arquitectura excelente, predecible y muy fácil de cachear a nivel de red para servicios simples. Sin embargo, en aplicaciones modernas con interfaces dinámicas, donde la optimización del peso de las respuestas y la reducción de peticiones son vitales para la experiencia del usuario, la precisión quirúrgica de GraphQL lo convierte en una herramienta invaluable.
