GraphQL Apollo Federation Subscriptions
Como empresa de desarrollo GraphQL, aprovechamos que GraphQL elimina el exceso y el defecto de datos recuperados (over-fetching y under-fetching) al permitir que los clientes pidan exactamente los datos que necesitan, con lo que se reducen las idas y vueltas a la API, el tamaño de las respuestas y la complejidad del frontend. Diseñamos esquemas GraphQL, optimizamos el rendimiento de los resolvers (DataLoader, límite de profundidad de consultas), implementamos suscripciones en tiempo real y creamos gateways GraphQL federados para clientes de EE. UU. y la UE sobre backends en Node.js, Python y Java.
Como empresa de desarrollo GraphQL, aprovechamos que GraphQL elimina el exceso y el defecto de datos recuperados (over-fetching y under-fetching) al permitir que los clientes pidan exactamente los datos que necesitan, con lo que se reducen las idas y vueltas a la API, el tamaño de las respuestas y la complejidad del frontend. Diseñamos esquemas GraphQL, optimizamos el rendimiento de los resolvers (DataLoader, límite de profundidad de consultas), implementamos suscripciones en tiempo real y creamos gateways GraphQL federados para clientes de EE. UU. y la UE sobre backends en Node.js, Python y Java.
Retos
Las consultas GraphQL anidadas provocan llamadas N+1 a la base de datos, una por cada elemento padre. Implementamos DataLoader en todos los resolvers de listas para agrupar las llamadas a la base de datos en una sola consulta por tipo y por solicitud.
La introspección activada en producción expone todo el modelo de datos a los atacantes. Desactivamos la introspección en producción y añadimos un límite de profundidad de consulta (máximo 7 niveles) y un análisis de complejidad de consulta (puntuación máxima 1000).
Los esquemas GraphQL no tienen versiones: deprecar campos exige coordinarse con todos los clientes. Usamos directivas @deprecated, supervisamos el uso de los campos obsoletos en Apollo Studio y mantenemos un calendario de retirada de campos acordado con los equipos cliente.
Los supergrafos de Apollo Federation con más de 10 subgrafos plantean retos de trazado distribuido y fallos de composición del esquema. Estructuramos los límites de los subgrafos por dominio, probamos la composición en el CI e implementamos el trazado distribuido a nivel de gateway.
Las suscripciones basadas en WebSocket mantienen estado y no escalan horizontalmente sin un backend de pub/sub. Usamos Redis pub/sub como capa de transporte de las suscripciones, de modo que cualquier instancia del gateway pueda atender cualquier suscripción.
El RGPD exige que los datos personales (PII) de la UE solo se devuelvan a quienes estén autorizados. Implementamos directivas de campo a nivel de resolver (@auth, @redact) que comprueban las claims del contexto JWT antes de devolver los campos con PII, y no en la capa HTTP.
Soluciones
Diseño de esquemas guiado por el dominio, con paginación al estilo Relay, tipos de conexión y validación de entradas, pensado para evolucionar a largo plazo sin romper a los clientes.
Introspección desactivada, límites de profundidad y complejidad de consulta, consultas persistidas para los clientes de producción, validación del contexto JWT y directivas @auth a nivel de campo.
Agrupación con DataLoader para todos los patrones de resolvers N+1, caché de consultas en Redis para los resolvers costosos y análisis de complejidad de consultas para detectar las operaciones caras antes de que lleguen a producción.
Supergrafo federado a partir de varios subgrafos: referencias a entidades, directivas @key, pruebas de composición de subgrafos en el CI y trazado distribuido a nivel de gateway.
Suscripciones WebSocket con backend de Redis pub/sub: escalables horizontalmente, con reconexión automática y deduplicación de suscripciones en el cliente.
Estrategia de migración incremental: un gateway GraphQL envuelve los endpoints REST existentes mediante RESTDataSource y se va sustituyendo gradualmente por resolvers nativos a medida que migra el backend.
Stack
GraphQL, Apollo Server 4, Apollo Federation 2, DataLoader, GraphQL Yoga, Strawberry (Python), Netflix DGS (Java), WebSockets (suscripciones), PostgreSQL, Redis, Sentry.
Cumplimiento
Alineado con el RGPD · límite de profundidad de consultas · autorización por campo · enmascaramiento de datos personales (PII) en los resolvers
Casos
Plataforma social en producción, en App Store y Google Play, activa en EE. UU. y la UE, con Radar geolocalizado, mensajería cifrada y economía virtual.
Clientes nativos de firma electrónica para iOS y Android con un CRM en Symfony + React para un despacho de abogados internacional: onboarding con KYC y una cadena de evidencias defendible para asuntos de EE. UU. y la UE.
App multiplataforma de noticias deportivas y portal web: CMS mediante un bot de Telegram en lugar de un panel de administración a medida y un pipeline de publicación en Markdown.
Por qué YuSMP
Diseñamos el esquema GraphQL como un contrato de producto antes de escribir los resolvers, para que la API responda a las necesidades del frontend y no a la comodidad del backend.
N+1 es el problema de producción más habitual en GraphQL. Implementamos DataLoader en cada resolver de listas desde el primer día, no después del primer incidente de rendimiento.
Incluso los proyectos de un solo grafo se construyen con tipos compatibles con la federación (directivas @key, resolvers de entidades), de modo que añadir un segundo subgrafo más adelante sume funcionalidad sin romper nada.
Preguntas frecuentes
GraphQL es la mejor opción cuando varios clientes (web, iOS, Android, partners) consumen la misma API y tienen necesidades de datos distintas; cuando el equipo de frontend cambia con frecuencia los requisitos de datos; cuando se necesitan suscripciones en tiempo real junto a las consultas; o cuando se construye una plataforma de producto en la que desarrolladores externos consultan sus datos. REST es la mejor opción para servicios CRUD sencillos, para APIs públicas en las que el caché HTTP es crítico o para equipos sin experiencia en GraphQL en los que la curva de aprendizaje pesa más que los beneficios.
Apollo Federation 2 compone varios esquemas de subgrafos en un único supergrafo. Cada subgrafo es dueño de los tipos de su dominio y expone entidades marcadas con @key. El Apollo Router (o Apollo Gateway) enruta las consultas entrantes a los subgrafos correctos, obtiene las referencias a entidades mediante las directivas @external y @requires y ensambla la respuesta. La composición del esquema se valida en el CI: el router solo arranca si el supergrafo compuesto es válido.
Con un límite de profundidad de consulta (máximo 7 niveles), un análisis de complejidad de consulta (puntuación máxima 1000, calculada por campo), limitación de tasa en la capa HTTP mediante Redis, consultas persistidas (los clientes de producción solo pueden ejecutar consultas preaprobadas) y la introspección desactivada en producción. En las APIs de gran escala añadimos APQ (Automatic Persisted Queries) para reducir el tamaño de las respuestas y la detección de anomalías de Apollo Studio para patrones de consulta inusuales.
Las suscripciones GraphQL son conexiones WebSocket con estado. Una sola instancia de servidor puede mantener miles de suscripciones, pero el escalado horizontal exige enrutar los eventos de suscripción hacia el servidor correcto. Usamos Redis pub/sub: cuando se produce un evento, el servicio que lo publica escribe en Redis; cada instancia del gateway se suscribe a Redis y reenvía el evento a la conexión WebSocket correspondiente. Esto escala hasta cientos de miles de suscripciones simultáneas.
La especificación de GraphQL no cubre la subida de archivos. Usamos la especificación de solicitudes multipart (graphql-multipart-request-spec), ya sea mediante el soporte de subida integrado en Apollo Server o con el middleware graphql-upload. Los archivos se envían en streaming directamente a S3 desde el resolver, sin pasar por el disco del servidor de aplicaciones. Como alternativa, implementamos un endpoint REST de subida junto a GraphQL para subidas de archivos grandes o frecuentes.
Con control de acceso a nivel de campo mediante directivas personalizadas (@auth, @requiresRole) que comprueban las claims del JWT antes de devolver los campos con PII. Con resolvers de solicitudes de los interesados que anonimizan o devuelven todos los datos de un ID de usuario dado. Con un registro de auditoría de consultas: cada consulta se registra con el ID del usuario autenticado y los campos resueltos. En los despliegues en la UE, el gateway GraphQL enruta las consultas de entidades residentes en la UE a resolvers de la región de la UE que garantizan la residencia de los datos.
Usamos RESTDataSource de Apollo Server para envolver los endpoints REST existentes en resolvers GraphQL. Primero se diseña el esquema GraphQL a partir de las necesidades de datos de los clientes y después los resolvers delegan en REST. A medida que se actualizan los servicios de backend, los resolvers pasan de llamadas REST a consultas directas a la base de datos. Así los equipos de frontend pueden adoptar GraphQL de inmediato mientras la migración del backend avanza de forma incremental a lo largo de semanas o meses.
Respuesta en 1 día hábil. NDA a petición.
Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.