JavaScript

REST vs GraphQL, Guía Comparativa para Proyectos Frontend

Comparativa práctica entre REST y GraphQL desde una perspectiva frontend: cuándo elegir cada enfoque según las necesidades de tu proyecto.

Photo by Mohammad Rahmani / Unsplash

Introducción

La comunicación entre el frontend y los servicios backend es uno de los aspectos fundamentales que definen la arquitectura, rendimiento y experiencia de desarrollo de nuestras aplicaciones. Durante años, REST ha sido el estándar de facto para diseñar APIs, pero GraphQL ha ganado popularidad significativa como alternativa con un enfoque radicalmente diferente.

Esta guía comparativa analiza ambas tecnologías desde la perspectiva específica del desarrollador frontend, proporcionando los criterios necesarios para tomar decisiones informadas según las necesidades de tu proyecto. No se trata de declarar un ganador absoluto, sino de entender en qué contextos cada tecnología brilla con mayor intensidad.

Qué aprenderás en este artículo

Fundamentos arquitectónicos de REST y GraphQL
Análisis comparativo de ventajas y limitaciones
Criterios de decisión basados en casos de uso reales
Implementaciones prácticas con ejemplos de código
Consideraciones de rendimiento y optimización

Arquitecturas para consumo de APIs: Fundamentos

Antes de sumergirnos en la comparación detallada, es esencial entender los principios fundamentales que distinguen a estas arquitecturas.

REST: Transferencia de Estado Representacional

REST (Representational State Transfer) es un estilo arquitectónico que utiliza los métodos HTTP estándar para operar sobre recursos identificados mediante URLs. Su diseño se basa en principios como:

Interfaz uniforme: Recursos identificados claramente con URLs
Sin estado: Cada solicitud contiene toda la información necesaria
Sistema en capas: Los componentes intermediarios no afectan la comunicación
Almacenamiento en caché: Las respuestas deben definir si son cacheables

Una API RESTful típica organiza sus endpoints alrededor de recursos y utiliza los verbos HTTP (GET, POST, PUT, DELETE) para definir operaciones sobre ellos.

GET /articles/123      # Obtiene el artículo con ID 123
POST /articles         # Crea un nuevo artículo
PUT /articles/123      # Actualiza el artículo con ID 123
DELETE /articles/123   # Elimina el artículo con ID 123

GraphQL: Lenguaje de Consulta para APIs

GraphQL, desarrollado por Facebook en 2015, representa un cambio paradigmático en el diseño de APIs. No es un protocolo de transferencia como REST, sino un lenguaje de consulta con una especificación para recuperar exactamente los datos solicitados.

Sus principios fundamentales incluyen:

Consulta declarativa: El cliente especifica exactamente qué datos necesita
Punto de entrada único: Generalmente una sola URL para todas las operaciones
Sistema de tipos fuerte: Schema que define todos los datos disponibles y sus tipos
Jerarquía: Los datos se organizan en forma de grafo con relaciones claras

En lugar de múltiples endpoints, GraphQL utiliza un único endpoint donde se envían consultas que especifican los datos deseados:

query {
  article(id: "123") {
    title
    body
    author {
      name
      bio
    }
    comments {
      text
      user {
        name
      }
    }
  }
}

Diferencias arquitectónicas fundamentales

La diferencia esencial entre estas arquitecturas radica en dónde se coloca el control sobre los datos transferidos:

REST: El servidor define endpoints con estructuras de respuesta fijas
GraphQL: El cliente especifica exactamente qué datos necesita recuperar

Esta diferencia central tiene profundas implicaciones en aspectos como flexibilidad, rendimiento, complejidad de implementación y experiencia de desarrollo.

Análisis comparativo: Ventajas y desventajas

Analicemos en detalle las fortalezas y debilidades de cada enfoque desde una perspectiva frontend.

Fortalezas de REST

REST ha dominado el panorama de desarrollo web durante años por buenas razones. Su fortaleza principal radica en su simplicidad y familiaridad. Al aprovechar las características nativas de HTTP, resulta intuitivo para desarrolladores con experiencia en desarrollo web, lo que se traduce en una curva de aprendizaje relativamente baja.

El caché nativo es otra ventaja significativa. REST utiliza directamente el sistema de caché de HTTP, permitiendo almacenar respuestas completas con implementaciones estándar:

fetch('/api/articles/popular', {
  headers: {
    'If-None-Match': etag // Soporte nativo para caché
  }
})

Después de décadas como el estándar dominante, REST cuenta con un vasto ecosistema de herramientas, middleware, documentación y conocimiento compartido. Esta madurez significa que prácticamente cualquier problema que encuentres ya ha sido resuelto por alguien más. Adicionalmente, su naturaleza sin estado hace que las solicitudes sean independientes, facilitando la escalabilidad horizontal del servidor.

Limitaciones de REST

A pesar de sus ventajas, REST presenta limitaciones importantes para aplicaciones frontend modernas. El problema más significativo es la dificultad para obtener exactamente los datos necesarios, lo que genera dos problemas relacionados:

El overfetching ocurre cuando recibimos más datos de los que necesitamos, desperdiciando ancho de banda y aumentando la transferencia de datos. El underfetching sucede cuando necesitamos realizar múltiples solicitudes para obtener todos los datos requeridos. Por ejemplo, para mostrar una lista de artículos con sus autores:

// Primero obtenemos los artículos
const articlesResponse = await fetch('/api/articles');
const articles = await articlesResponse.json();

// Luego, para cada artículo, obtenemos su autor
for (const article of articles) {
  const authorResponse = await fetch(`/api/users/${article.authorId}`);
  article.author = await authorResponse.json();
}

Este enfoque resulta en múltiples round-trips al servidor o en recibir datos innecesarios, lo que impacta negativamente el rendimiento, especialmente en conexiones lentas.

Otra limitación significativa es su inflexibilidad ante cambios en la UI. Cuando la interfaz evoluciona y necesita datos diferentes, a menudo requiere cambios en el backend o crear nuevos endpoints específicos, lo que puede provocar proliferación de endpoints y fragmentación de la API. Además, la documentación de APIs REST generalmente debe mantenerse separadamente del código, aunque herramientas como Swagger/OpenAPI han mejorado esta situación.

Fortalezas de GraphQL

GraphQL surge como respuesta a muchas de las limitaciones de REST, con ventajas que resultan particularmente valiosas para aplicaciones frontend complejas. Su característica más destacada es la capacidad de solicitar exactamente los datos necesarios en una sola operación:

const query = `
  query {
    articles(limit: 10) {
      title
      excerpt
      author {
        name
        avatar
      }
    }
  }
`;

const response = await fetch('/graphql', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ query })
});

Esta capacidad elimina tanto el overfetching como el underfetching, optimizando la transferencia de datos y reduciendo la latencia percibida por el usuario.

GraphQL también proporciona mayor autonomía al equipo frontend. Los desarrolladores pueden modificar sus consultas cuando cambian los requisitos de la UI sin necesitar cambios en el backend, acelerando los ciclos de desarrollo y reduciendo la dependencia entre equipos.

El sistema de introspección y tipado fuerte es otra ventaja importante. GraphQL proporciona un sistema de tipos que permite validación automática de consultas, autocompletado en el desarrollo y generación automática de tipos para clientes. Esto mejora la experiencia de desarrollo y reduce errores en tiempo de ejecución.

La evolución de la API sin versiones es un beneficio adicional. Agregar campos nuevos no rompe clientes existentes, ya que solo solicitan lo que necesitan, permitiendo una evolución más suave de la API sin necesidad de mantener múltiples versiones.

Limitaciones de GraphQL

A pesar de sus ventajas, GraphQL también presenta desafíos importantes. La complejidad inicial es significativa; implementar GraphQL requiere una curva de aprendizaje más pronunciada y una configuración inicial más compleja, especialmente en el lado del servidor.

El manejo de caché es considerablemente más complejo. Al usar un único endpoint y consultas personalizadas, el caché a nivel HTTP es menos efectivo y requiere estrategias específicas como normalización de datos:

// Con Apollo Client
import { ApolloClient, InMemoryCache } from '@apollo/client';

const client = new ApolloClient({
  uri: '/graphql',
  cache: new InMemoryCache({
    typePolicies: {
      // Configuración de normalización y caché
    }
  })
});

Sin las limitaciones adecuadas, los clientes podrían construir consultas extremadamente anidadas que sobrecarguen el servidor:

# Consulta potencialmente costosa por su profundidad
query {
  articles {
    comments {
      author {
        followers {
          articles {
            comments {
              # ... y así sucesivamente
            }
          }
        }
      }
    }
  }
}

A diferencia de los códigos de estado HTTP en REST, GraphQL siempre devuelve 200 OK y encapsula los errores en la respuesta, lo que puede complicar su manejo y requiere implementaciones adicionales para una gestión efectiva de errores.

Criterios de decisión según el tipo de proyecto

La elección entre REST y GraphQL debe basarse en las características específicas de tu proyecto. Aquí presento criterios clave para orientar esta decisión.

Considera REST cuando:

1. El proyecto tiene interfaces simples con requisitos de datos estables

Para aplicaciones con flujos de trabajo predecibles y necesidades de datos consistentes, REST ofrece simplicidad y directrices claras sin la sobrecarga adicional de GraphQL.

💡 Pro tip
Las aplicaciones CRUD tradicionales con formularios y listados simples generalmente funcionan bien con REST sin la complejidad adicional de GraphQL.

2. El caché HTTP es crítico para el rendimiento

Si tu aplicación se beneficia significativamente del caché a nivel HTTP, especialmente para recursos que cambian con poca frecuencia, REST ofrece ventajas integradas.

3. El equipo tiene experiencia limitada con tecnologías modernas

Para equipos nuevos o con experiencia principalmente en arquitecturas tradicionales, REST puede ofrecer una ruta más accesible con menos conceptos nuevos que dominar.

4. Se requiere streaming de datos o transferencia de archivos

REST maneja naturalmente casos de uso como streaming y transferencia de archivos grandes, mientras que estos escenarios pueden ser más complejos en GraphQL.

Considera GraphQL cuando:

1. La aplicación tiene interfaces complejas con diversos requisitos de datos

Dashboards, feeds sociales o interfaces con visualización de datos complejos se benefician enormemente de la flexibilidad de consulta de GraphQL.

2. Desarrollo móvil con restricciones de ancho de banda

Las aplicaciones móviles con conexiones limitadas o inestables se benefician de la eficiencia en la transferencia de datos que ofrece GraphQL.

# Versión completa para desktop
query DesktopArticle {
  article(id: "123") {
    title
    fullBody
    coverImage { large medium small }
    author {
      name
      bio
      avatar
      socialLinks
    }
    comments {
      text
      date
      user { name avatar }
    }
    relatedArticles { title excerpt }
  }
}

# Versión optimizada para móvil
query MobileArticle {
  article(id: "123") {
    title
    excerpt
    coverImage { small }
    author {
      name
      avatar
    }
    commentCount
  }
}

3. Experiencia de desarrollo frontend prioritaria

Si la velocidad de desarrollo frontend y la autonomía del equipo son prioritarias, GraphQL reduce significativamente la dependencia de cambios en el backend.

4. La aplicación consume múltiples fuentes de datos

GraphQL excele como capa de agregación que unifica diferentes APIs, servicios o bases de datos detrás de una interfaz coherente.

Enfoque híbrido: Lo mejor de ambos mundos

En muchos casos, un enfoque híbrido puede ser la solución ideal:

Utilizar GraphQL para operaciones de UI complejas y variables
Mantener REST para operaciones simples, subida de archivos o streaming
Implementar GraphQL como capa sobre APIs REST existentes

⚠️ Advertencia
El enfoque híbrido aumenta la complejidad de mantenimiento y puede crear inconsistencias si no se diseña cuidadosamente la separación de responsabilidades.

Implementación práctica: Ejemplos comparativos

Para ilustrar las diferencias en implementación, comparemos cómo se abordaría un caso común: mostrar un listado de artículos con información de autor y comentarios.

Implementación con REST

Configuración del cliente

// Configuración simple con fetch
const API_BASE = 'https://api.example.com';

async function fetchData(endpoint) {
  const response = await fetch(`${API_BASE}${endpoint}`);
  if (!response.ok) {
    throw new Error(`Error: ${response.status}`);
  }
  return response.json();
}

Obtención de datos con múltiples peticiones

// Componente React que muestra artículos con autores
function ArticlesList() {
  const [articles, setArticles] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    async function loadArticles() {
      try {
        setLoading(true);
        
        // Obtener artículos
        const articlesData = await fetchData('/articles');
        
        // Para cada artículo, obtener su autor
        const articlesWithAuthors = await Promise.all(
          articlesData.map(async (article) => {
            const author = await fetchData(`/users/${article.authorId}`);
            
            // Para cada artículo, obtener sus comentarios
            const comments = await fetchData(`/articles/${article.id}/comments`);
            
            return { ...article, author, comments };
          })
        );
        
        setArticles(articlesWithAuthors);
      } catch (err) {
        setError(err.message);
      } finally {
        setLoading(false);
      }
    }
    
    loadArticles();
  }, []);

  if (loading) return <p>Cargando artículos...</p>;
  if (error) return <p>Error: {error}</p>;

  return (
    <div className="articles-list">
      {articles.map(article => (
        <ArticleCard 
          key={article.id} 
          article={article} 
        />
      ))}
    </div>
  );
}

Problemas potenciales de esta implementación

Múltiples round-trips: Cascada de peticiones que aumenta el tiempo de carga
Waterfall de datos: Dependencias secuenciales entre peticiones
Overfetching: Cada endpoint devuelve datos completos, incluso campos no utilizados
Acoplamiento: Cambios en la UI pueden requerir nuevos endpoints o modificaciones

Implementación con GraphQL

Configuración del cliente con Apollo

import { 
  ApolloClient, 
  InMemoryCache, 
  ApolloProvider, 
  gql, 
  useQuery 
} from '@apollo/client';

// Configuración del cliente GraphQL
const client = new ApolloClient({
  uri: 'https://api.example.com/graphql',
  cache: new InMemoryCache()
});

// Componente raíz que proporciona el cliente
function App() {
  return (
    <ApolloProvider client={client}>
      <ArticlesList />
    </ApolloProvider>
  );
}

Obtención de datos con una sola consulta

// Definir la consulta GraphQL
const GET_ARTICLES = gql`
  query GetArticles {
    articles(limit: 10, sortBy: "date") {
      id
      title
      excerpt
      createdAt
      author {
        id
        name
        avatar
      }
      comments {
        id
        text
        user {
          name
          avatar
        }
      }
    }
  }
`;

// Componente que muestra artículos
function ArticlesList() {
  const { loading, error, data } = useQuery(GET_ARTICLES);

  if (loading) return <p>Cargando artículos...</p>;
  if (error) return <p>Error: {error.message}</p>;

  return (
    <div className="articles-list">
      {data.articles.map(article => (
        <ArticleCard 
          key={article.id} 
          article={article} 
        />
      ))}
    </div>
  );
}

Ventajas de esta implementación

Una sola petición: Todos los datos necesarios se obtienen de una vez
Selección precisa: Solo se solicitan los campos requeridos
Relaciones incorporadas: Las entidades relacionadas se incluyen directamente
Flexibilidad: Modificar la consulta para diferentes requisitos de UI sin cambios en el backend

🔍 Detalle técnico
GraphQL ejecuta las consultas de forma paralela en el servidor, evitando el problema del "waterfall" de peticiones. El servidor resuelve todas las relaciones (artículos, autores, comentarios) en paralelo de manera optimizada.

Optimizaciones para cada enfoque

Optimización de REST

// Endpoint combinado que reduce peticiones
async function loadArticlesOptimized() {
  // Un endpoint que incluye la información relacionada
  const data = await fetchData('/articles?include=author,comments');
  setArticles(data);
}

Optimización de GraphQL

// Consulta con paginación y variables
const GET_ARTICLES_PAGINATED = gql`
  query GetArticles($limit: Int!, $offset: Int!) {
    articles(limit: $limit, offset: $offset) {
      id
      title
      # otros campos...
    }
  }
`;

function ArticlesList() {
  const { loading, error, data, fetchMore } = useQuery(GET_ARTICLES_PAGINATED, {
    variables: { limit: 10, offset: 0 }
  });
  
  function loadMore() {
    fetchMore({
      variables: { offset: data.articles.length },
      updateQuery: (prev, { fetchMoreResult }) => {
        if (!fetchMoreResult) return prev;
        return {
          articles: [...prev.articles, ...fetchMoreResult.articles]
        };
      }
    });
  }
  
  // Resto del componente...
}

Consideraciones de rendimiento y escala

El rendimiento es una consideración crítica para cualquier aplicación frontend. Veamos cómo cada enfoque maneja diferentes aspectos de rendimiento.

Tiempo hasta el primer byte (TTFB)

REST

Ventaja en solicitudes pequeñas y simples
Mayor latencia cuando se requieren múltiples recursos relacionados

GraphQL

Mayor sobrecarga inicial por procesamiento de consultas
Mejor rendimiento en consultas complejas con datos relacionados
El procesamiento del servidor puede ser más intensivo

Caché y optimización de red

Estrategias de caché en REST

Aprovecha directamente los mecanismos de HTTP:

// Ejemplo con headers de caché
fetch('/api/articles/popular', {
  headers: {
    'If-None-Match': etag,
    'If-Modified-Since': lastModified
  }
})

Estrategias de caché en GraphQL

Requiere implementación específica a nivel de aplicación:

import { ApolloClient, InMemoryCache } from '@apollo/client';

const client = new ApolloClient({
  uri: '/graphql',
  cache: new InMemoryCache({
    typePolicies: {
      Article: {
        // Configuración para identificación y fusión de entidades
        keyFields: ['id'],
        fields: {
          comments: {
            merge(existing = [], incoming) {
              return [...existing, ...incoming];
            }
          }
        }
      }
    }
  })
});

Paginación y carga de datos

Paginación en REST

// Paginación basada en offset
fetch('/api/articles?page=2&limit=20')

// Paginación basada en cursor
fetch('/api/articles?after=article123&limit=20')

Paginación en GraphQL

# Paginación con conexiones (estilo Relay)
query {
  articlesConnection(first: 10, after: "cursor123") {
    edges {
      node {
        id
        title
      }
      cursor
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

💡 Pro tip
La paginación basada en cursores es generalmente más robusta para ambas arquitecturas, ya que evita problemas cuando los datos cambian entre solicitudes de página.

Manejo de actualizaciones en tiempo real

REST con polling o webhooks

// Polling simple
setInterval(async () => {
  const newComments = await fetchData(`/articles/${id}/comments?since=${lastFetch}`);
  updateComments(newComments);
}, 5000);

GraphQL con suscripciones

const COMMENTS_SUBSCRIPTION = gql`
  subscription OnNewComment($articleId: ID!) {
    newComment(articleId: $articleId) {
      id
      text
      user {
        name
        avatar
      }
    }
  }
`;

function CommentsLiveSection({ articleId }) {
  // Configuración de la suscripción...
}

Conclusión: Eligiendo la arquitectura adecuada

No existe una solución universal para la comunicación frontend-backend. La decisión entre REST y GraphQL debe considerar múltiples factores específicos a tu proyecto.

Criterios de decisión clave

Complejidad de la UI: Interfaces complejas con datos variables favorecen a GraphQL
Experiencia del equipo: Considera la curva de aprendizaje y conocimientos existentes
Restricciones de rendimiento: Evalúa requisitos de ancho de banda y latencia
Tipos de operaciones: Algunas operaciones (streaming, archivos) son más naturales en REST
Evolución del proyecto: Proyectos con cambios frecuentes de UI se benefician de GraphQL

Enfoque pragmático

El pragmatismo debe guiar esta decisión. En muchos casos, un enfoque híbrido puede aprovechar las fortalezas de ambas arquitecturas:

Evalúa objetivamente los requisitos del proyecto
Considera implementar inicialmente la solución más simple que funcione
Refactoriza hacia la arquitectura óptima cuando el valor sea claro
No descartes usar ambas tecnologías para diferentes partes de la aplicación

✨ Mejora
Para proyectos existentes con APIs REST, considera implementar una capa de GraphQL en el frontend que actúe como BFF (Backend For Frontend). Herramientas como Apollo Federation o Hasura pueden ayudarte a construir esta capa gradualmente.

La elección entre REST y GraphQL no es permanente e irrevocable. A medida que tu aplicación evoluciona, reevalúa periódicamente si la arquitectura elegida sigue siendo la mejor para tus necesidades actuales.