GraphQL o REST es la primera decisión técnica que toca cualquier proyecto web que vaya a consumir datos de varias fuentes: catálogo, CRM, reservas, pasarela de pagos. La escoge casi siempre el desarrollador por costumbre, sin mirar qué necesita realmente el negocio que la paga. Este artículo es para quien tiene que aprobar esa decisión o convivir con ella: responsables de marketing que piden integraciones y equipos técnicos que las construyen. Se explica qué cambia entre las dos arquitecturas, cuándo compensa migrar y qué dice la adopción real este año.
GraphQL no sustituye a REST: conviene cuando una misma pantalla necesita combinar datos de varias fuentes en una sola petición, como un panel de leads que cruza CRM, web y anuncios. Si tu web solo lista contenido y recibe formularios, una API REST bien cacheada sigue siendo la opción más barata de mantener.
GraphQL o REST, qué resuelve cada arquitectura
REST organiza una API en endpoints: uno para los artículos, otro para los leads, otro para el stock. Cada petición trae una estructura fija que decide el servidor, así que una pantalla que necesita datos de tres recursos distintos lanza tres peticiones o un endpoint hecho a medida para esa pantalla. Es el modelo que lleva usando la web desde los años 2000 y el que cubre, según su propia documentación técnica, la gran mayoría de integraciones sencillas.
GraphQL cambia el reparto: un único endpoint recibe una consulta en la que el cliente declara exactamente los campos que necesita, y el servidor resuelve esa consulta cruzando los tipos que tenga definidos en su esquema. Elimina el overfetching (traer campos que nadie pinta) y el underfetching (encadenar varias llamadas para montar una sola pantalla). El coste es que ese esquema hay que diseñarlo, documentarlo y mantenerlo, y no todos los equipos tienen quien lo haga.
Cuándo una API REST clásica sigue siendo suficiente
La mayoría de webs corporativas no necesitan GraphQL. Si el sitio publica contenido, recibe formularios y como mucho sincroniza con un CRM o un ERP, una API REST bien diseñada —con cacheo HTTP, paginación y versión en la URL— resuelve el 90% de los casos sin añadir una pieza más que mantener. Es también la opción con más desarrolladores disponibles en el mercado local: montar un equipo que sepa diseñar esquemas GraphQL con garantías cuesta más caro y tarda más en encontrarse en Barcelona que montar uno que trabaje con REST. Quien quiera una segunda opinión antes de decidir puede apoyarse en una consultoría de sistemas IT en Barcelona que ya haya visto los dos modelos en producción.
Webs de servicios con pocas integraciones
Una consultora, un despacho o una clínica con web corporativa normalmente conecta tres piezas: el formulario de contacto, un calendario de citas y, como mucho, el CRM donde cae el lead. Tres endpoints REST bastan y se entienden en una tarde por cualquier desarrollador nuevo que entre al proyecto. Meter GraphQL aquí añade un esquema que nadie más va a tocar, una capa de resolución que hay que vigilar y un punto de fallo extra sin que el negocio note ninguna mejora: la pantalla sigue tardando lo mismo porque el cuello de botella no estaba en la forma de pedir los datos.
GraphQL compensa cuando agregas, no cuando publicas
El caso que justifica GraphQL es el contrario: una pantalla —un panel interno, una app, un buscador de propiedades— que necesita cruzar en una sola carga datos de varias fuentes que antes de tener API ya vivían separadas. Ahí un endpoint agregador evita que el navegador lance diez peticiones en cascada y que cada equipo que consume datos tenga que aprenderse diez contratos distintos. Esta misma lógica de agregar fuentes es la que decide si tu web conviene en WordPress o headless: cuanto más agregues, más sentido tiene separar el frontend del origen de los datos.
Paneles que cruzan CRM, web y anuncios
Una inmobiliaria que gestiona varios portales, su propia web y el CRM de captación necesita, en una sola pantalla de gestión, el estado de cada inmueble, los leads que ha generado y el gasto en anuncios que lo trajo. Pedir eso con REST obliga a llamar a tres sistemas y montar la mezcla en el cliente; con GraphQL esa mezcla se resuelve en el servidor con una sola consulta, y el equipo de marketing que consulta el panel no necesita saber que detrás hay tres proveedores distintos con tres formatos distintos. El esfuerzo de construir el esquema se paga una vez y lo usan todas las pantallas que vengan después.
Un esquema GraphQL es el contrato que describe, tipo por tipo, qué datos existen y cómo se relacionan entre sí: es lo que permite que el cliente pida justo lo que necesita sin que el servidor tenga que adivinarlo.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Qué pierde GraphQL en materia de caché HTTP
REST hereda gratis el cacheo que ya trae el protocolo HTTP: cabeceras como «Cache-Control» o «ETag», descritas en el estándar RFC 9110 del IETF, permiten que un proxy, un CDN o el propio navegador guarden la respuesta de un endpoint sin tocar el servidor en cada petición. Un listado de artículos que cambia una vez al día se sirve así casi gratis.
GraphQL normalmente responde a peticiones POST contra un único endpoint, y ese verbo no es cacheable por defecto bajo ese mismo estándar. Para recuperar algo parecido al cacheo de REST hace falta añadir persisted queries o una capa de caché propia por consulta, que es trabajo de infraestructura que con REST viene de serie. Es el argumento técnico más sólido a favor de REST cuando el contenido cambia poco y el tráfico es alto, como el blog o el catálogo público de una web corporativa.
La adopción real de GraphQL en 2026
El informe State of the API de Postman sitúa a REST como el estilo que usa la inmensa mayoría de equipos de desarrollo, por encima del 90%, mientras que GraphQL aparece ya en algo más de uno de cada tres, normalmente combinado con REST y no sustituyéndolo. El patrón que describe el informe coincide con lo que se ve en proyectos de aquí: GraphQL entra como capa de agregación por encima de sistemas que ya existían, casi nunca como reemplazo completo de una API que ya funciona.
Ese dato tiene una lectura práctica para quien tiene que aprobar presupuesto: adoptar GraphQL no es modernizar la web por modernizarla, es resolver un problema concreto de integración. Si ese problema ya está resuelto —por ejemplo porque la integración con el CRM ya funciona con webhooks y REST— migrar solo añade coste sin quitar ningún dolor real.
Según el sector, cambia la arquitectura que conviene
La decisión cambia según cuántas fuentes de datos tenga que cruzar cada pantalla, y eso varía mucho de un sector a otro. Algunos ejemplos con los que nos encontramos en Barcelona:
- Ecommerce: catálogo, stock, pasarela de pago y CRM de fidelización suelen vivir en sistemas distintos; un agregador tipo GraphQL delante de todos ellos evita que la ficha de producto dependa de la disponibilidad de cuatro servicios a la vez.
- Inmobiliario: varios portales, CRM de captación y anuncios: el panel de gestión es el caso de libro para GraphQL, visto más arriba.
- Servicios profesionales (asesorías, clínicas, despachos): formulario, calendario y poco más; REST clásico sobra para lo que piden.
- Industrial: catálogo técnico conectado a un ERP con fichas de producto complejas; aquí pesa más la calidad de los datos estructurados que la arquitectura de la API que los sirve.
- Hostelería y turismo: motor de reservas, disponibilidad en tiempo real y precios dinámicos de varias fuentes; la agregación vuelve a justificar GraphQL si hay más de un canal de venta.
No hay una respuesta única por sector, pero sí una pregunta que vale para todos: ¿cuántos sistemas distintos tiene que tocar una sola pantalla para pintarse? Con uno o dos, REST. Con tres o más que cambian con frecuencia, GraphQL empieza a pagar su propio mantenimiento.
Preguntas frecuentes sobre GraphQL y REST
¿Se pueden mezclar GraphQL y REST en la misma web?
Sí, y es lo más habitual: una capa GraphQL puede convivir delante de varios servicios REST que sigan funcionando igual, actuando solo como punto de agregación para las pantallas que lo necesiten. No hace falta reescribir nada que ya funcione para empezar a usarlo donde aporte.
¿Cuánto tarda en notarse la mejora al pasar a GraphQL?
En paneles con tres o más integraciones la mejora se nota desde la primera versión: menos peticiones en cascada y una pantalla que carga en una sola llamada en vez de en cinco. En una web de contenido simple, en cambio, no hay mejora que notar porque el cuello de botella nunca estuvo ahí.
¿Hace falta cambiar de equipo técnico para usar GraphQL?
No hace falta cambiar de equipo, pero sí sumar quien diseñe y mantenga el esquema: es un rol distinto al de quien monta endpoints REST. Muchas agencias lo resuelven formando a alguien del propio proyecto, no con una contratación nueva, salvo en plataformas con tráfico muy alto.
¿GraphQL es menos seguro que REST por tener un solo endpoint?
No es menos seguro, pero exige controles distintos: limitar la profundidad y la complejidad de las consultas para que nadie pida, en una sola petición, datos que deberían costar diez llamadas. Sin ese límite, un único endpoint mal protegido expone más que varios endpoints REST bien segmentados.
