REST vs GraphQL: el costo real de cada uno
· 7 min
El debate REST vs GraphQL suele girar en torno a la ergonomía para el desarrollador, pero las contrapartidas de rendimiento de ambos lados son concretas y con frecuencia se subestiman.
El problema que GraphQL realmente resuelve
REST sufre de over-fetching y under-fetching: los formatos de respuesta fijos por endpoint obligan al cliente a recibir campos que no usa, o a hacer varias idas y vueltas para armar lo que necesita. GraphQL resuelve justo eso, dejando que el cliente elija los campos en cada solicitud.
El precio: N+1 controlado por el cliente
Una query GraphQL puede pedir relaciones anidadas a cualquier profundidad, y a menos que los resolvers del servidor hagan batching (como con DataLoader), cada campo anidado puede disparar una query por cada ítem del nivel superior, el mismo N+1 que ya sufren los ORMs, solo que ahora la forma de la consulta (y por lo tanto qué fanout dispara) la decide el cliente en cada solicitud, mucho más difícil de predecir y cachear del lado del servidor.
La caché HTTP se vuelve más difícil
REST se apoya en la caché HTTP (GET + URL como clave de caché, amigable con CDN) que no se traduce directamente a GraphQL, ya que la mayor parte del tráfico GraphQL es POST con un cuerpo de query. Cachear exige o bien queries persistidas, o una caché de aplicación con una clave compuesta por la query resuelta más las variables.
Cómo equilibrar esto en la práctica
El costo de GraphQL es manejable con batching de resolvers, límites de profundidad/complejidad de query para bloquear consultas anidadas patológicas, y queries persistidas para recuperar la cacheabilidad, pero nada de esto es gratis, es trabajo de ingeniería que REST no exige por defecto.