REST o GraphQL: pedir menos datos puede invertir el resultado

REST suele tener ventaja en una lectura simple que entrega casi todos los campos necesarios. GraphQL puede responder antes cuando el cliente pide solo una pequeña parte de una lista: una respuesta más corta puede compensar el trabajo de procesar la consulta. El resultado depende también de la concurrencia, de cómo se obtienen las relaciones y de la caché.

La documentación de consultas de GraphQL explica que el cliente selecciona campos y recibe una respuesta con la forma de esa selección. Esa capacidad reduce datos sobrantes cuando la API REST comparada devuelve objetos completos. Si REST ya permite proyectar campos o dispone de un endpoint ajustado a la vista, la diferencia de volumen puede estrecharse.

Un registro: la ruta simple favorece a REST

En la evaluación con NestJS y PostgreSQL, la lectura de un pedido con 8.000 usuarios virtuales concurrentes promedió 9,67 ms en REST y 72,83 ms en GraphQL al solicitar todos los campos. Son tiempos de las aplicaciones y configuraciones ensayadas, no velocidades inherentes a cada arquitectura.

Con 1.000 usuarios virtuales, las medias para ese pedido fueron 3,37 ms en REST y 4,49 ms en GraphQL completo. Los investigadores ejecutaron el generador de carga y ambos servicios en un mismo portátil, por lo que la prueba redujo la influencia de la latencia de red. Cada nivel de carga se repitió seis veces; una aplicación distribuida, con otra base de datos o resolvers distintos, puede producir tiempos diferentes.

Cuando el cliente usa casi todo el objeto, seleccionar campos apenas reduce la respuesta. GraphQL conserva el coste de analizar y ejecutar la operación, mientras que un endpoint REST específico puede recorrer una ruta más directa. Esto explica la ventaja observada en esa lectura, sin convertirla en una recomendación para cualquier consulta o implementación.

Una lista parcial puede cambiar el orden

La selección de campos tuvo otro efecto al pedir 500 pedidos bajo una carga de 24.000 usuarios virtuales. GraphQL limitado al identificador promedió 9,8 s; REST, 19,7 s; y GraphQL con todos los campos, más de 42 s. Las respuestas recibidas ocuparon, respectivamente, 9,8 kB, 167 kB y 188 kB. La variante limitada devolvió muchos menos datos y fue la más rápida de las tres en ese escenario.

El texto del estudio atribuye a la consulta limitada una reducción del 58 % frente a REST, pero los tiempos publicados de 9,8 s y 19,7 s equivalen a una reducción cercana al 50 %. Los decimales adicionales que aparecen en el artículo tampoco explican esa diferencia. Los tiempos y el orden de los resultados son más útiles aquí que el porcentaje declarado.

La comparación requiere además distinguir la tarea: recibir solo identificadores no satisface a una pantalla que necesita nombres, importes y detalles. Si esos campos se solicitan después, habrá que contar el tiempo y el tráfico de las nuevas peticiones. Para una lista que realmente muestra pocos atributos, en cambio, la fracción de campos consumidos puede importar más que el nombre de la arquitectura. REST también puede reducir la respuesta mediante una proyección de campos o un recurso diseñado para esa lista.

Relaciones: ahorrar viajes no basta

Los pedidos relacionados con sus detalles, productos y proveedores plantean un coste distinto. En el experimento, la variante REST distribuida entre varios endpoints necesitó ocho solicitudes. Bajo la carga máxima, promedió 16.806 ms, frente a 7.520 ms de GraphQL completo y 6.578 ms de GraphQL con una selección reducida. Un endpoint REST que reunía esas relaciones en una sola respuesta bajó la media a 2.420 ms.

Ese último resultado muestra por qué conviene comparar diseños funcionalmente equivalentes. GraphQL evitó viajes entre cliente y servidor frente al REST de múltiples endpoints; REST recuperó la ventaja cuando la agregación se hizo dentro del servidor. El coste de construir esa respuesta agregada, así como la flexibilidad para atender otras combinaciones de datos, también forma parte de la elección. Es el intercambio entre menos solicitudes y más complejidad.

Una consulta anidada puede ocultar trabajo en la base de datos. La guía de rendimiento de GraphQL describe el problema N+1: resolver cada elemento relacionado por separado multiplica los accesos internos, y agruparlos puede reducirlos. La implementación del estudio incluyó DataLoader; eso no garantiza que otra API con los mismos campos haga el mismo número de consultas. Para una vista anidada importan tanto los viajes HTTP como las operaciones de sus resolvers.

La caché altera la ruta medida

Una respuesta reutilizada evita parte del trabajo que domina una prueba contra el servidor de origen. La guía de caché HTTP de MDN explica que una respuesta almacenada puede atender solicitudes posteriores sin volver a procesarlas en el origen. Un GET de REST con una respuesta estable puede beneficiarse de ello; su latencia con acierto de caché describe una ruta distinta de la de una consulta calculada de nuevo.

GraphQL también puede usar GET para consultas cuando la implementación lo admite, junto con encabezados adecuados y operaciones persistidas. La reutilización depende de la operación, sus variables y los datos que cambian por usuario. Una respuesta personalizada exige una política que impida compartirla indebidamente. Por eso, al comparar cargas reales, conviene separar aciertos y fallos de caché y mantener la misma política de compresión: ambos factores modifican el coste de transferir y generar una respuesta.

Una plantilla para comparar tu API

La decisión arquitectónica se aclara con las operaciones que el producto necesita, no con una única cifra publicada. Esta plantilla conserva la diferencia entre lectura simple, lista parcial y objeto relacionado:

1. Define las tres operaciones con datos y filtros equivalentes. Añade una variante que pida el objeto completo para saber cuánto ahorra realmente la selección de campos.
2. Prepara para cada operación una ruta REST existente o viable y una consulta GraphQL que entreguen la misma información útil. Si enfrentas una respuesta completa a otra limitada, registra esa diferencia como parte del resultado.
3. Mantén iguales la base de datos, el volumen de registros, la autenticación, la compresión y la política de caché. Prueba varios niveles de concurrencia acordes con el tráfico esperado.
4. Registra la mediana y la latencia de cola, el tamaño de petición y respuesta, las operaciones completadas por segundo y las consultas a la base de datos. Cuando el servicio use caché, mide por separado las respuestas reutilizadas y las calculadas en origen.

Para una lectura breve de un recurso, un REST ajustado a la necesidad del cliente puede conservar la ruta más rápida. Si las vistas piden subconjuntos muy distintos de listas grandes, la selección de campos de GraphQL merece medirse; si reúnen relaciones, compara también un endpoint REST agregado y el trabajo de los resolvers. Solo una prueba con información equivalente permite saber si el ahorro de datos supera el coste adicional de obtenerlos.

Lee también:

• REST o GraphQL: ahorrar solicitudes puede aumentar la complejidad
• Tu empresa puede vigilar el correo, pero debe explicar por qué lo hace
• Airtable o Smartsheet: automatizar mucho puede invertir el ahorro