NUCBA - Formación profesional digital

Hace unos meses, un dev de NUCBA me contó que llevaba seis meses con un proyecto que no lograba escalar. El problema no era el código, era que había elegido GraphQL para una API interna que solo necesitaba endpoints simples. Se había comido el marketing.

Esta historia se repite todo el tiempo. Devs que usan REST cuando necesitan flexibilidad, o GraphQL cuando necesitan simplicidad. Ambos son herramientas, pero cada uno resuelve problemas diferentes.

El problema real: elegir sin entender el contexto

REST y GraphQL no compiten. Resuelven problemas distintos:

REST es predecible y simple. Funciona genial cuando tenés endpoints claros y sabés exactamente qué datos necesita cada cliente.

GraphQL es flexible y potente. Brilla cuando múltiples clientes necesitan datos diferentes del mismo backend, o cuando querés evitar múltiples requests.

La clave está en entender cuál necesitás para tu contexto específico.

Cuándo REST es tu mejor opción

APIs internas y microservicios

Si estás construyendo comunicación entre microservicios o APIs internas, REST probablemente sea tu mejor opción.

// Endpoint REST simple y claro
GET /api/orders/123
{
  "id": 123,
  "status": "completed",
  "total": 2500,
  "customer_id": 456
}

¿Por qué funciona? Porque en este contexto:

Sabés exactamente qué datos necesitás
Los endpoints son específicos y claros
No necesitás flexibilidad, necesitás consistencia
El caching es directo con herramientas como Redis

Aplicaciones con flujos simples

Un e-commerce básico, un blog, un CRUD administrativo. Si tu app hace una cosa y la hace bien, REST te va a dar menos dolores de cabeza.

Equipos pequeños o con poca experiencia en GraphQL

REST tiene menos overhead mental. Un dev junior puede entender un endpoint REST en minutos. GraphQL requiere entender resolvers, schemas, queries anidadas.

Cuándo GraphQL vale la pena

Múltiples clientes con necesidades diferentes

Tenés una app móvil que necesita datos básicos, un dashboard web que necesita todo, y un widget que solo quiere dos campos:

# Mobile app - solo lo básico
query {
  user(id: "123") {
    name
    avatar
  }
}

# Dashboard - necesita todo
query {
  user(id: "123") {
    name
    email
    avatar
    orders {
      id
      total
      status
    }
    preferences {
      theme
      notifications
    }
  }
}

Con REST necesitarías múltiples endpoints o endpoints que devuelven datos que no usás.

Relaciones complejas entre datos

Si tu dominio tiene muchas relaciones y necesitás navegar entre ellas, GraphQL te ahorra requests:

query {
  course(id: "react-pro") {
    title
    instructor {
      name
      courses {
        title
        studentsCount
      }
    }
    students {
      name
      completedLessons
    }
  }
}

Con REST esto serían al menos 4 requests diferentes.

Frontend teams que necesitan autonomía

Si tenés equipos frontend que quieren iterar rápido sin depender del backend para cada cambio, GraphQL les da esa flexibilidad.

Los costos ocultos de cada opción

REST: simplicidad con limitaciones

Ventajas:

HTTP caching out-of-the-box
Herramientas maduras (Postman, curl, etc.)
Fácil de debuggear
Menos overhead en el servidor

Costos:

Over-fetching: traés datos que no necesitás
Under-fetching: necesitás múltiples requests
Versionado de API puede ser complejo

GraphQL: flexibilidad con complejidad

Ventajas:

Una sola request para datos complejos
Introspección automática
Tipado fuerte
Evolución de schema sin breaking changes

Costos:

Caching más complejo
Queries maliciosas pueden sobrecargar el servidor
Curva de aprendizaje mayor
Debugging más complejo

Casos reales donde uno claramente gana

Netflix: GraphQL para la diversidad de dispositivos

Netflix usa GraphQL porque tienen docenas de clientes diferentes (TV, móvil, web, diferentes versiones) que necesitan datos diferentes del mismo contenido.

GitHub: REST para la API pública

GitHub mantiene su API REST porque es simple para los desarrolladores externos. Sabés que GET /repos/owner/repo te da la info del repositorio. Punto.

NUCBA: híbrido según el contexto

En NUCBA usamos REST para APIs internas (pagos, notificaciones) y GraphQL para el frontend de cursos donde necesitamos flexibilidad en los datos del estudiante.

Cómo decidir en tu proyecto

Hacete estas preguntas:

¿Cuántos clientes van a consumir esta API? Uno → REST. Múltiples → considerá GraphQL.
¿Las relaciones entre datos son simples o complejas? Simples → REST. Complejas → GraphQL.
¿Tu equipo tiene experiencia con GraphQL? No → empezá con REST.
¿Necesitás caching agresivo? Sí → REST te facilita la vida.
¿Los clientes necesitan datos muy diferentes? Sí → GraphQL te ahorra requests.

No es una decisión permanente

Podés empezar con REST y migrar endpoints específicos a GraphQL cuando lo necesites. No es todo o nada.

Muchas empresas usan ambos: REST para operaciones simples y GraphQL para queries complejas de datos relacionados.

Preguntas frecuentes

¿Puedo usar GraphQL solo para queries y REST para mutations?

Sí, es una estrategia común. GraphQL para leer datos complejos, REST para operaciones que necesitan ser predecibles (pagos, creación de usuarios).

¿GraphQL es más lento que REST?

Depende. Una query GraphQL bien optimizada puede ser más rápida que múltiples requests REST. Una query mal hecha puede ser un desastre de performance.

¿Necesito Apollo o puedo usar GraphQL vanilla?

Podés usar GraphQL sin Apollo. Apollo facilita caching y state management, pero no es obligatorio para empezar.

¿Usás REST cuando necesitarías GraphQL? El problema es más común de lo que pensás