GraphQL vs. REST: ¿qué estilo de API y cuándo?

REST es un estilo de API con muchos endpoints fijos; GraphQL es un lenguaje de consultas donde los clientes piden a un endpoint solo los campos que necesitan. La comparación trata en realidad de quién decide la forma de la respuesta: en REST el servidor la decidió en tiempo de diseño; en GraphQL el cliente la decide en cada solicitud. Todo lo demás — caché, versionado, errores, rendimiento — se desprende de esa única inversión.

Puntos clave

La misma pantalla, de las dos formas

Una pantalla de perfil necesita un usuario, sus cinco posts más recientes y el conteo de seguidores. REST habla en recursos:

GET /users/42               → 38 campos, necesitabas 3    (overfetching)
GET /users/42/posts?limit=5 → segundo round trip          (underfetching)
GET /users/42/followers     → tercer round trip

GraphQL habla en una sola pregunta con forma:

POST /graphql
query {
  user(id: 42) {
    name
    avatarUrl
    posts(first: 5) { title likes }
    followers { totalCount }
  }
}
→ un solo round trip, exactamente esos campos, nada más

La brecha se estrecha más de lo que sugieren los titulares: una API REST bien diseñada también soporta selección de campos — y los query builders de los SDKs la vuelven un hábito de primera clase:

// JavaScript / Node.js — Back4app JS SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
const query = new Parse.Query('Article');
query.equalTo('status', 'published');
query.select('title', 'views');        // field selection, GraphQL-style
const articles = await query.find();   // lean payload over the REST API
// The same backend also speaks real GraphQL: query { articles { ... } }

// Flutter / Dart — Back4app Flutter SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
final query = QueryBuilder<ParseObject>(ParseObject('Article'))
  ..whereEqualTo('status', 'published')
  ..keysToReturn(['title', 'views']);   // field selection, GraphQL-style
final response = await query.query();   // lean payload over the REST API

// iOS / Swift — Back4app Swift SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
let query = Article.query("status" == "published")
  .select("title", "views")             // field selection, GraphQL-style
query.find { result in
  if case .success(let articles) = result { render(articles) }
}

// Android / Kotlin — Back4app Android SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
val query = ParseQuery.getQuery<ParseObject>("Article")
query.whereEqualTo("status", "published")
query.selectKeys(listOf("title", "views"))  // field selection, GraphQL-style
query.findInBackground { articles, e -> if (e == null) render(articles) }

GraphQL vs. REST de un vistazo

Las partes que las páginas de comparación omiten

El problema N+1 se mudó, no murió. Una query de GraphQL por posts-con-autores dispara ingenuamente una llamada de resolver por post — la misma patología N+1 que los ORMs hicieron famosa, ahora del lado del servidor. La cura estándar es el batching: un loader por solicitud junta los IDs de autor y los trae en una sola consulta. Adoptar GraphQL sin estrategia de batching es adoptar el peor bug de rendimiento de REST en una nueva dirección.

Los errores son una decisión de operaciones. “200 con un array de errors” significa que los dashboards, las alertas y la lógica de CDN construidas sobre códigos de estado quedan ciegas por defecto. Los equipos que prosperan con GraphQL tratan la observabilidad de errores como parte de la adopción, no como una idea tardía.

Las consultas sin límites necesitan límites. Un endpoint flexible significa que una query puede recorrer el grafo entero — la guía oficial de seguridad recomienda límites de profundidad, presupuestos de costo por query y allowlists de persisted queries para los clientes propios. Los endpoints fijos de REST hacían implícito el control de costo; GraphQL lo convierte en tu trabajo.

Casos de uso comunes

• GraphQL: apps móviles en redes lentas, dashboards que cosen muchas entidades, productos con clientes web + móvil + partners que divergen en necesidades de datos, iteración rápida del frontend contra un schema estable.
• REST: APIs públicas para desarrolladores, entrega de contenido cacheable, superficies de webhooks e integraciones, transferencia de archivos, llamadas servicio-a-servicio donde gana la simplicidad.
• Ambos (la norma enterprise): REST o RPC entre servicios de backend; una capa GraphQL agregándolos para los frontends — el patrón backend-for-frontend con schema.

¿Deberías elegir GraphQL o REST? Matriz de decisión

El default honesto: empieza con REST, agrega GraphQL cuando el dolor de moldear datos multi-cliente llegue de verdad — y si tu plataforma genera ambos desde un mismo esquema, la elección deja de ser arquitectónica y se vuelve por solicitud.

Limitaciones y trade-offs

• REST: over/underfetching en pantallas densas en datos, migraciones de versión, deriva de formas de respuesta entre equipos y N endpoints de documentación.
• GraphQL: el caché exige maquinaria, el control de costo exige vigilancia, los resolvers exigen disciplina de batching y el patrón 200-con-errors exige rehacer la observabilidad.
• Ambos: ninguno arregla un mal modelo de datos — un dominio confuso produce una API confusa en cualquier estilo, como la propia tesis de REST insinúa en voz baja: las restricciones siempre trataron de la arquitectura de abajo.

GraphQL y REST en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Disuelve el dilema de este artículo de raíz: ambos estilos de API se generan desde el mismo schema — endpoints REST cacheables por URL y una API GraphQL tipada con consultas anidadas — más SDKs cuya selección de campos (las pestañas de código de arriba) entrega el beneficio estrella de GraphQL sobre cualquiera de los dos transportes. Elige por cliente, cambia por pantalla y no escribas la capa de API en absoluto.