Arquitectura · 21 de octubre de 2026 · Daniel Murillo

REST vs GraphQL: cuándo necesitas flexibilidad

GraphQL no reemplaza REST en todos los casos. Cuándo la flexibilidad de consulta aporta valor y qué coste operativo implica.

GraphQL no existe para reemplazar REST en todos los casos. Existe para resolver un problema concreto: permitir que el cliente describa los datos que necesita dentro de un esquema definido.

Introducción

Una pantalla móvil puede necesitar tres campos de un recurso, mientras que un panel administrativo requiere relaciones, estadísticas y detalles adicionales. Con REST, estas necesidades suelen resolverse mediante endpoints, filtros y proyecciones. GraphQL ofrece otro enfoque: el cliente formula una consulta y selecciona los campos que quiere recibir.

La flexibilidad es valiosa, pero no gratuita. GraphQL introduce un esquema, resolvers, políticas de complejidad y una estrategia de caché diferente. Elegir entre REST y GraphQL significa evaluar el equilibrio entre flexibilidad, simplicidad, rendimiento y operación.

1. Cómo piensa REST

REST suele organizar la API alrededor de recursos:

GET /api/products/123
GET /api/products/123/reviews
GET /api/products/123/inventory

Este modelo es fácil de entender, documentar, proteger y almacenar en caché mediante HTTP, especialmente cuando las respuestas son GET identificables y tienen políticas de caché apropiadas.

La dificultad aparece cuando una pantalla necesita combinar información de muchos recursos. El cliente puede hacer varias solicitudes, o el backend puede ofrecer un endpoint compuesto diseñado para esa vista.

2. Cómo piensa GraphQL

GraphQL expone un esquema y permite que el cliente solicite los campos que necesita:

query ProductDetails {
  product(id: "123") {
    id
    name
    price
    reviews {
      rating
    }
  }
}

La respuesta contiene la estructura solicitada. Esto puede reducir la transferencia de campos innecesarios y facilitar que distintos clientes consuman datos distintos sin crear un endpoint para cada combinación.

Sin embargo, GraphQL no elimina el trabajo del servidor. Cada campo puede activar lógica de resolución y consultas a la base de datos. Una sola solicitud HTTP puede resultar más costosa que varias solicitudes REST simples.

3. El problema N+1 y DataLoader

Imaginemos que una consulta solicita cien pedidos y el cliente de cada pedido. Si el resolver ejecuta una consulta individual por cliente, la petición puede generar más de cien consultas a la base de datos.

DataLoader y técnicas de batching permiten agrupar las cargas de datos relacionadas y reutilizar resultados dentro de una operación.

También conviene diseñar resolvers que aprovechen consultas eficientes, índices y límites de resultados. GraphQL no hace automáticamente eficientes las consultas internas.

4. Proteger la API de consultas costosas

La flexibilidad de GraphQL puede permitir consultas demasiado profundas o con listas muy grandes. En una API pública, conviene considerar:

Límites de profundidad y complejidad.
Tamaño máximo de listas y paginación.
Timeouts y cancelación.
Autorización apropiada para los datos solicitados.
Límites de concurrencia.
Consultas persistidas cuando sean útiles.
Métricas por operación y resolver.

No todas las consultas tienen el mismo coste. Contar solamente el número de solicitudes HTTP puede ocultar el trabajo real que realiza el servidor.

5. Caché: un modelo diferente

En REST, una URL GET y sus encabezados pueden servir como una identidad natural para una respuesta cacheable. En GraphQL, varias consultas pueden pedir combinaciones distintas de campos y variables, por lo que la caché requiere más diseño.

Estrategias habituales:

Caché normalizada de entidades en el cliente.
Caché de resultados de resolvers.
Consultas persistidas.
Caché HTTP para operaciones compatibles.
Identificación correcta de variables, permisos y contexto del usuario.

Las consultas GraphQL enviadas mediante GET pueden beneficiarse de caché HTTP si la implementación lo permite. Las mutaciones no deben ejecutarse mediante GET.

La caché debe evitar mezclar resultados de usuarios con permisos diferentes y tener una estrategia de invalidación coherente.

6. Compresión y tamaño de respuesta

Las respuestas GraphQL suelen ser JSON y pueden comprimirse con Gzip o Brotli cuando el cliente y la infraestructura lo soportan. Pero si la respuesta ya es pequeña, la compresión puede no aportar mucho. Si el servidor está limitado por CPU, un nivel agresivo puede empeorar la latencia.

La selección de campos reduce datos innecesarios; la compresión reduce los bytes restantes. Son técnicas complementarias, no sustitutas.

7. ¿GraphQL es más rápido que REST?

No necesariamente. Puede reducir viajes de red y exceso de datos en interfaces complejas. También puede producir consultas costosas, dificultar la caché HTTP convencional y añadir trabajo de resolución.

REST puede ofrecer endpoints compuestos, proyecciones y caché HTTP eficiente. Una implementación REST bien diseñada puede ser más sencilla y rápida para operaciones estables.

La comparación debe medir la operación completa: solicitudes, trabajo de base de datos, serialización, bytes transmitidos, CPU y latencias p95/p99.

8. Cuándo elegir cada uno

Prefiere REST cuando:

Los recursos y operaciones son relativamente estables.
La API es pública o se integra con muchos sistemas.
La caché HTTP convencional es importante.
La simplicidad operativa y la facilidad de depuración son prioridades.
La mayoría de los clientes necesitan estructuras de datos similares.

Considera GraphQL cuando:

Web, móvil y otros clientes necesitan diferentes combinaciones de campos.
Las pantallas agregan datos de varias entidades.
La flexibilidad reduce una cantidad significativa de solicitudes o datos innecesarios.
El equipo puede operar un esquema, controlar la complejidad y observar los resolvers.

También es posible combinar ambos: REST para operaciones sencillas o integraciones públicas y GraphQL para una capa de consulta orientada a clientes. La decisión debe responder al dominio y a las necesidades reales, no a una preferencia de moda.

Conclusión

GraphQL existe para dar flexibilidad a la consulta de datos. Esa flexibilidad puede simplificar clientes y reducir transferencia innecesaria, pero necesita límites, resolvers eficientes y una estrategia de caché.

REST sigue siendo una opción excelente cuando el modelo de recursos es claro y las capacidades HTTP ofrecen una solución sencilla.

Elige GraphQL cuando la flexibilidad de las consultas resuelva un problema real. No lo adoptes solo porque una única solicitud parezca más elegante que varias.

En esta serie

Referencias

Índice

Arquitectura · 21 de octubre de 2026 · Daniel Murillo

REST vs GraphQL: cuándo necesitas flexibilidad

GraphQL no reemplaza REST en todos los casos. Cuándo la flexibilidad de consulta aporta valor y qué coste operativo implica.

GraphQL no existe para reemplazar REST en todos los casos. Existe para resolver un problema concreto: permitir que el cliente describa los datos que necesita dentro de un esquema definido.

Introducción

1. Cómo piensa REST

REST suele organizar la API alrededor de recursos:

GET /api/products/123
GET /api/products/123/reviews
GET /api/products/123/inventory

Este modelo es fácil de entender, documentar, proteger y almacenar en caché mediante HTTP, especialmente cuando las respuestas son GET identificables y tienen políticas de caché apropiadas.

2. Cómo piensa GraphQL

GraphQL expone un esquema y permite que el cliente solicite los campos que necesita:

query ProductDetails {
  product(id: "123") {
    id
    name
    price
    reviews {
      rating
    }
  }
}

3. El problema N+1 y DataLoader

DataLoader y técnicas de batching permiten agrupar las cargas de datos relacionadas y reutilizar resultados dentro de una operación.

También conviene diseñar resolvers que aprovechen consultas eficientes, índices y límites de resultados. GraphQL no hace automáticamente eficientes las consultas internas.

4. Proteger la API de consultas costosas

La flexibilidad de GraphQL puede permitir consultas demasiado profundas o con listas muy grandes. En una API pública, conviene considerar:

Límites de profundidad y complejidad.
Tamaño máximo de listas y paginación.
Timeouts y cancelación.
Autorización apropiada para los datos solicitados.
Límites de concurrencia.
Consultas persistidas cuando sean útiles.
Métricas por operación y resolver.

No todas las consultas tienen el mismo coste. Contar solamente el número de solicitudes HTTP puede ocultar el trabajo real que realiza el servidor.

5. Caché: un modelo diferente

Estrategias habituales:

Caché normalizada de entidades en el cliente.
Caché de resultados de resolvers.
Consultas persistidas.
Caché HTTP para operaciones compatibles.
Identificación correcta de variables, permisos y contexto del usuario.

Las consultas GraphQL enviadas mediante GET pueden beneficiarse de caché HTTP si la implementación lo permite. Las mutaciones no deben ejecutarse mediante GET.

La caché debe evitar mezclar resultados de usuarios con permisos diferentes y tener una estrategia de invalidación coherente.

6. Compresión y tamaño de respuesta

La selección de campos reduce datos innecesarios; la compresión reduce los bytes restantes. Son técnicas complementarias, no sustitutas.

7. ¿GraphQL es más rápido que REST?

REST puede ofrecer endpoints compuestos, proyecciones y caché HTTP eficiente. Una implementación REST bien diseñada puede ser más sencilla y rápida para operaciones estables.

La comparación debe medir la operación completa: solicitudes, trabajo de base de datos, serialización, bytes transmitidos, CPU y latencias p95/p99.

8. Cuándo elegir cada uno

Prefiere REST cuando:

Los recursos y operaciones son relativamente estables.
La API es pública o se integra con muchos sistemas.
La caché HTTP convencional es importante.
La simplicidad operativa y la facilidad de depuración son prioridades.
La mayoría de los clientes necesitan estructuras de datos similares.

Considera GraphQL cuando:

Web, móvil y otros clientes necesitan diferentes combinaciones de campos.
Las pantallas agregan datos de varias entidades.
La flexibilidad reduce una cantidad significativa de solicitudes o datos innecesarios.
El equipo puede operar un esquema, controlar la complejidad y observar los resolvers.

Conclusión

REST sigue siendo una opción excelente cuando el modelo de recursos es claro y las capacidades HTTP ofrecen una solución sencilla.

Elige GraphQL cuando la flexibilidad de las consultas resuelva un problema real. No lo adoptes solo porque una única solicitud parezca más elegante que varias.

En esta serie

Referencias

Índice

Arquitectura · 21 de octubre de 2026 · Daniel Murillo

REST vs GraphQL: cuándo necesitas flexibilidad

GraphQL no reemplaza REST en todos los casos. Cuándo la flexibilidad de consulta aporta valor y qué coste operativo implica.

GraphQL no existe para reemplazar REST en todos los casos. Existe para resolver un problema concreto: permitir que el cliente describa los datos que necesita dentro de un esquema definido.

Introducción

1. Cómo piensa REST

REST suele organizar la API alrededor de recursos:

GET /api/products/123
GET /api/products/123/reviews
GET /api/products/123/inventory

Este modelo es fácil de entender, documentar, proteger y almacenar en caché mediante HTTP, especialmente cuando las respuestas son GET identificables y tienen políticas de caché apropiadas.

2. Cómo piensa GraphQL

GraphQL expone un esquema y permite que el cliente solicite los campos que necesita:

query ProductDetails {
  product(id: "123") {
    id
    name
    price
    reviews {
      rating
    }
  }
}

3. El problema N+1 y DataLoader

DataLoader y técnicas de batching permiten agrupar las cargas de datos relacionadas y reutilizar resultados dentro de una operación.

También conviene diseñar resolvers que aprovechen consultas eficientes, índices y límites de resultados. GraphQL no hace automáticamente eficientes las consultas internas.

4. Proteger la API de consultas costosas

La flexibilidad de GraphQL puede permitir consultas demasiado profundas o con listas muy grandes. En una API pública, conviene considerar:

Límites de profundidad y complejidad.
Tamaño máximo de listas y paginación.
Timeouts y cancelación.
Autorización apropiada para los datos solicitados.
Límites de concurrencia.
Consultas persistidas cuando sean útiles.
Métricas por operación y resolver.

No todas las consultas tienen el mismo coste. Contar solamente el número de solicitudes HTTP puede ocultar el trabajo real que realiza el servidor.

5. Caché: un modelo diferente

Estrategias habituales:

Caché normalizada de entidades en el cliente.
Caché de resultados de resolvers.
Consultas persistidas.
Caché HTTP para operaciones compatibles.
Identificación correcta de variables, permisos y contexto del usuario.

Las consultas GraphQL enviadas mediante GET pueden beneficiarse de caché HTTP si la implementación lo permite. Las mutaciones no deben ejecutarse mediante GET.

La caché debe evitar mezclar resultados de usuarios con permisos diferentes y tener una estrategia de invalidación coherente.

6. Compresión y tamaño de respuesta

La selección de campos reduce datos innecesarios; la compresión reduce los bytes restantes. Son técnicas complementarias, no sustitutas.

7. ¿GraphQL es más rápido que REST?

REST puede ofrecer endpoints compuestos, proyecciones y caché HTTP eficiente. Una implementación REST bien diseñada puede ser más sencilla y rápida para operaciones estables.

La comparación debe medir la operación completa: solicitudes, trabajo de base de datos, serialización, bytes transmitidos, CPU y latencias p95/p99.

8. Cuándo elegir cada uno

Prefiere REST cuando:

Los recursos y operaciones son relativamente estables.
La API es pública o se integra con muchos sistemas.
La caché HTTP convencional es importante.
La simplicidad operativa y la facilidad de depuración son prioridades.
La mayoría de los clientes necesitan estructuras de datos similares.

Considera GraphQL cuando:

Web, móvil y otros clientes necesitan diferentes combinaciones de campos.
Las pantallas agregan datos de varias entidades.
La flexibilidad reduce una cantidad significativa de solicitudes o datos innecesarios.
El equipo puede operar un esquema, controlar la complejidad y observar los resolvers.

Conclusión

REST sigue siendo una opción excelente cuando el modelo de recursos es claro y las capacidades HTTP ofrecen una solución sencilla.

Elige GraphQL cuando la flexibilidad de las consultas resuelva un problema real. No lo adoptes solo porque una única solicitud parezca más elegante que varias.