¿Qué es GraphQL vs REST APIs? Consultas, Mutaciones y Tipado
Cómo Facebook revolucionó el consumo de datos móviles resolviendo los problemas de Over-fetching y Under-fetching con un único endpoint.
GraphQL es un lenguaje de consulta (Query Language) y un entorno de ejecución para APIs creado por Facebook (Meta) en 2012 y publicado como código abierto en 2015. A diferencia de una API REST tradicional —donde cada recurso tiene su propia URL fija y el servidor decide qué datos devolver—, en GraphQL existe **un único endpoint HTTP** (habitualmente `/graphql`) y el **cliente especifica con precisión milimétrica qué campos necesita recibir**. GraphQL resuelve los dos dolores de cabeza históricos de las APIs REST en dispositivos móviles: 1. **Over-fetching (Sobredescarga)**: Quieres mostrar solo el nombre de un usuario en pantalla, pero la API REST te devuelve un objeto JSON gigantesco de 80 campos con dirección, teléfono, historial y metadatos inútiles. 2. **Under-fetching (Subdescarga)**: Para armar la pantalla de perfil necesitas consultar `/users/1`, luego `/users/1/posts`, y luego `/posts/5/comments`. Tienes que disparar 3 o 4 peticiones de red consecutivas con latencias sumadas. En GraphQL, pides todo en una sola consulta estructurada.
- ✓Un Solo Viaje de Red (Single Roundtrip): Obtén datos de múltiples entidades relacionadas en una única petición HTTP POST.
- ✓Esquema Estrictamente Tipado (SDL): El cliente y el servidor comparten un contrato tipado infalible con autocompletado y validación en tiempo de compilación.
- ✓Evolución sin Versionado de URL: No necesitas crear `/v1/`, `/v2/` ni `/v3/`. Puedes marcar campos antiguos como `@deprecated` y agregar campos nuevos sin romper clientes antiguos.
- •Elimina el consumo innecesario de batería y megabytes en aplicaciones móviles iOS y Android.
- •Permite a desarrolladores frontend crear nuevas pantallas sin pedirle al equipo de backend que cree nuevos endpoints específicos.
- •Facilita la agregación de múltiples microservicios backend detrás de un único grafo unificado (Federation).
- **API REST es un Menú Ejecutivo Fijo**: Entras al restaurante y pides el 'Combo #1' (el endpoint `/usuarios`). El mozo te trae obligatoriamente una hamburguesa con cebolla, papas fritas y una gaseosa gigante. Si tú solo querías probar un bocado de carne y odias la cebolla, no puedes pedirle que te quite las papas ni que no traiga la gaseosa; te entregan la bandeja entera te guste o no. - **GraphQL es un Buffet Personalizado con un Formulario**: El mozo te entrega una hoja en blanco. Tú escribes: *'Por favor, tráigame solo 100 gramos de carne magra y 3 hojas de lechuga'*. El mozo va a la cocina y te sirve en el plato **únicamente lo que anotaste en la lista**, ni un gramo más, ni un gramo menos.
Explicación Paso a Paso del Tema
Estructura de una Consulta (Query) en GraphQL
Para solicitar el nombre y correo de un usuario junto a los títulos de sus últimos 2 artículos, se redacta una consulta limpia.
Observa cómo la respuesta JSON del servidor calca exactamente la forma de la petición.
query ObtenerPerfilUsuario {
user(id: "42") {
name
email
articles(limit: 2) {
title
slug
}
}
}| Parámetro / Flag | Tipo / Rol | Significado y Uso |
|---|---|---|
| query | Operación | Operación de solo lectura (equivalente al método GET en HTTP). |
| user(id: "42") | Campo con argumento | Campo raíz del esquema al que se le pasan parámetros de filtrado. |
Las mutaciones (`mutation`) se utilizan para crear, actualizar o eliminar datos (equivalentes a POST, PUT, DELETE en REST).
Definir el Esquema con Schema Definition Language (SDL)
Todo servidor GraphQL se rige por un esquema tipado estricto que describe los tipos, campos y relaciones disponibles.
El signo de exclamación `!` indica que un campo es obligatorio (non-nullable).
type Article {
id: ID!
title: String!
slug: String!
readTimeMinutes: Int
}
type User {
id: ID!
name: String!
email: String!
articles(limit: Int): [Article!]!
}
type Query {
user(id: ID!): User
}| Parámetro / Flag | Tipo / Rol | Significado y Uso |
|---|---|---|
| ID! | Tipo escalar | Identificador único obligatorio serializado como cadena de texto. |
| [Article!]! | Lista tipada | Arreglo no nulo que contiene objetos de tipo Article obligatorios. |
No implementar límite de profundidad en las consultas (Query Depth Limiting): un atacante podría enviar una consulta infinitamente anidada (`user { friends { friends { friends... } } }`) y saturar la base de datos.
El Problema del N+1 en GraphQL y cómo Solucionarlo
Si un resolver busca un usuario y luego ejecuta una consulta SQL por cada artículo del usuario en un bucle, generará 100 consultas a la base de datos para 100 artículos (el infame problema N+1).
Para solucionarlo se utiliza **DataLoader**: una utilidad que agrupa y cachea peticiones en memoria para ejecutar una sola consulta `SELECT * FROM articles WHERE id IN (...)`.
Herramientas modernas como Prisma ORM o Hasura resuelven el problema N+1 de forma automática a nivel de motor de base de datos.
Casos Prácticos Reales en Producción
Situaciones de ingeniería reales sin mención de presupuestos ficticios.
1La App Móvil de Twitter (X) y la Optimización de Red en Países Emergentes
Twitter experimentaba altas tasas de rebote en mercados con conexiones 3G lentas porque su API REST requería múltiples llamadas para mostrar un solo Tweet con su autor, métricas y respuestas.
Adoptaron GraphQL para que el cliente móvil solicite únicamente los campos visibles en la pantalla en un solo payload comprimido.
Fichas Nemotécnicas de Conceptos Clave
Glosario rápido para recordar los términos fundamentales de la lección.
Problema en APIs donde el servidor devuelve muchos más datos de los que el cliente realmente necesita para renderizar la pantalla.
Problema en APIs donde un endpoint no devuelve suficientes datos, obligando al cliente a realizar múltiples peticiones consecutivas.
Función en el backend encargada de buscar y devolver los datos de un campo específico del esquema en la base de datos o API externa.
¿Qué es GraphQL vs REST APIs? Consultas, Mutaciones y Tipado
Selecciona una opción para autoevaluarte al instante. La respuesta se califica de inmediato.
¿Qué problema resuelve GraphQL frente a las tradicionales APIs REST?
¿Cuántos endpoints HTTP públicos se utilizan habitualmente en una arquitectura GraphQL estándar?
¿Qué es el 'Problema del N+1' en un servidor GraphQL?
Preguntas Frecuentes (FAQ)
¿GraphQL reemplaza a REST por completo?
No. REST sigue siendo extraordinario y más simple para operaciones directas, subida binaria de archivos pesados y aprovechamiento de la caché HTTP nativa de navegadores y CDNs (gracias a URLs únicas cacheables con GET). Muchos sistemas exitosos combinan ambos según el caso de uso.
¿Cómo se cachean las respuestas en GraphQL si siempre usa peticiones POST?
A diferencia de REST donde las CDNs cachean URLs por método GET, en GraphQL se utilizan cachés normalizadas en el cliente (como Apollo Client o URQL) y técnicas en el servidor como 'Persisted Queries' o extensiones de caché de Edge.