Planteamiento y contexto
Usted lidera un SaaS B2B con una API REST consolidada. Clientes importantes solicitan GraphQL para componer consultas a través de múltiples recursos, mientras que ingeniería se preocupa por el costo de las consultas, los límites de autorización, el almacenamiento en caché y la gobernanza a largo plazo. Decida si conviene lanzar GraphQL y explique el alcance, las métricas, los riesgos y el plan de migración.
Esta es una decisión de producto de API, no una invitación a implementar un servidor de GraphQL. La especificación de GraphQL describe un lenguaje de consulta y un motor de ejecución para capacidades y requisitos del modelo de datos; la API pública de GitHub admite tanto consultas como mutaciones. Su trabajo consiste en convertir esas capacidades en una decisión de producto evaluable.
Lo que evalúa el entrevistador
- Partir de los flujos de trabajo de los clientes y del dolor medible en lugar de elegir GraphQL solo porque está de moda.
- Comparar REST, GraphQL y una capa de agregación en cuanto a descubrimiento, viajes de ida y vuelta (round trips), autorización, almacenamiento en caché y observabilidad.
- Convertir el esquema, la complejidad de las consultas, la paginación y los límites de mutación en restricciones de producto.
- Diseñar un piloto por etapas, un plan de compatibilidad, un enfoque de precios y métricas de experiencia del desarrollador.
Preguntas para aclarar primero
- ¿El dolor radica en requerir menos viajes de ida y vuelta, reducir el exceso de datos transferidos (over-fetching) o lograr la composición entre recursos? ¿Podría resolverlo la agregación REST existente?
- ¿Cuántos consumidores, stacks de lenguajes, regiones de cumplimiento y SLOs objetivo están dentro del alcance? ¿Dependen los socios de contratos estables?
- ¿Son suficientes las consultas de solo lectura o se requieren escrituras? ¿Necesitarían las escrituras transacciones, idempotencia y aprobación?
- ¿Qué recursos y campos definen el límite del inquilino (tenant boundary)? ¿Cómo se limitarán la profundidad, el tamaño de la respuesta y el presupuesto por inquilino?
Una respuesta en 30 segundos
Validaría un problema recurrente de composición con los clientes y realizaría un piloto con un conjunto pequeño de recursos de solo lectura. Si la agregación REST ya resuelve los flujos de trabajo de alto valor a bajo costo, no lanzaría GraphQL solo por el protocolo. Si varios clientes necesitan diferentes combinaciones de campos y mantener endpoints personalizados resulta costoso, lanzaría un producto GraphQL acotado. La primera versión expondría un esquema de consulta estable, paginación y presupuestos de complejidad, reutilizaría la identidad y la autorización de inquilinos existentes y pospondría las mutaciones arbitrarias. Escalaría o detendría la iniciativa en función de la activación, la tasa de éxito, la latencia P95, el costo por consulta, la carga de soporte y la migración desde REST.
Análisis detallado paso a paso
Definir primero el valor para el cliente y las alternativas
Divida la solicitud en: menos viajes de ida y vuelta en la red, menor sobrecarga de datos (over-fetching) y composición entre recursos. Para cada una, registre el grafo de llamadas REST actual, la latencia de extremo a extremo, la cantidad de endpoints personalizados y el costo del proxy construido por el cliente. Si un único endpoint de agregación REST resuelve la mayoría de los flujos de trabajo valiosos, incluya el costo de gobernanza de GraphQL en la comparación en lugar de solo contar solicitudes.
Establecer un límite de producto en lugar de exponer la base de datos
El primer esquema debe cubrir recursos con semántica estable, propiedad clara por inquilino y comportamiento observable. Etiquete cada campo con su nivel de sensibilidad, reglas de autorización, promesas de versionado y frescura. Revise las consultas y las mutaciones por separado: valide primero el valor de lectura y luego considere las escrituras una vez que la idempotencia, la auditoría y la semántica de errores hayan madurado.
Convertir el costo de las consultas en un presupuesto exigible
El conjunto de selección flexible de GraphQL traslada el costo del conteo de endpoints a la forma de la consulta. Limite la profundidad máxima, el recuento de nodos, el tamaño de página y el tiempo de espera (timeout), y estime el costo por campo del esquema o resolver. Rechace las solicitudes que excedan el presupuesto con errores claros y accionables, registrando al mismo tiempo el inquilino, el nombre de la operación, el costo estimado y el uso real de recursos.
Preservar la identidad, la autorización y los límites de inquilinos
GraphQL cambia la forma de la solicitud; no debe eludir OAuth existente, cuentas de servicio, aislamiento de inquilinos o permisos a nivel de campo. Aplique la autorización en los resolvers o en una capa compartida de acceso a datos en lugar de hacerlo únicamente en la consulta raíz. Las lecturas por lotes deben evitar uniones entre inquilinos (cross-tenant joins), la reutilización no autorizada de la caché y la fuga de información a través de errores.
Planificar la experiencia del desarrollador y la compatibilidad
Proporcione documentación del esquema, consultas de ejemplo, orientación sobre errores, convenciones de paginación, requisitos para el nombre de operaciones y un registro de cambios (changelog). Los cambios incompatibles en el esquema requieren un período de obsolescencia (deprecation window), escaneo de emisores de llamadas y contactos asignados. REST y GraphQL pueden compartir modelos de dominio, pero no prometa una paridad de campos uno a uno para siempre.
Definir un piloto, métricas y criterios de salida
Seleccione de 2 a 3 clientes representativos y flujos de trabajo de solo lectura con recursos y presupuestos fijos. Monitoree aplicaciones activas, tasa de consultas válidas, latencia P95/P99, costo por consulta, intentos de autorización bloqueados, tickets de soporte y tiempo para completar las tareas del cliente. Una baja adopción, un alto costo o un aumento en incidentes de gobernanza deberían reducir el esquema o detener su expansión en lugar de ocultarse agregando más campos.
{
"pilot": {"tenants": 3, "mode": "read-only", "maxDepth": 6, "costBudget": 100},
"exit": {"p95LatencyMs": 400, "errorRate": 0.01, "supportTicketsPerTenant": 2}
}Ejemplo de una respuesta sólida
No trataría a GraphQL como un reemplazo inevitable para REST. Utilizaría evidencia de los clientes para confirmar si la composición, el over-fetching o el mantenimiento de endpoints personalizados representan un problema lo suficientemente grande, y lo compararía con el costo de entrega de una capa de agregación REST. Si el piloto demuestra su valor, convertiría GraphQL en un producto de API gobernado: un esquema de solo lectura estable, OAuth y autorización de inquilinos existentes, nombres de operación obligatorios, límites de profundidad, nodos, paginación y costos, además de documentación del esquema y un período de obsolescencia. Google Apigee modela un producto de API como un conjunto de recursos, métodos, niveles de acceso y cuotas, lo cual es un recordatorio útil para diseñar el control de acceso, los límites y los planes de GraphQL de forma integrada. Utilizaría clientes activos, tasa de éxito, P95, costo unitario por consulta y carga de soporte para decidir si expandirlo; solo entonces agregaría recursos y mutaciones de alcance acotado.
Errores comunes
- Decir que “el frontend es más flexible” sin demostrar el valor para el cliente ni compararlo con la agregación REST.
- Mapear el esquema de GraphQL directamente a las tablas de la base de datos, ignorando la semántica de dominio, la autorización y los campos sensibles.
- Permitir profundidad, paginación o anidamiento ilimitados sin un modelo de costos y una estrategia de rechazo.
- Lanzar consultas y mutaciones juntas sin límites de idempotencia, auditoría, aprobación o reversión (rollback).
- Medir únicamente la adopción mientras se ignoran la latencia, los costos, la autorización bloqueada y la carga de soporte.
- Prometer una migración única para cada cliente REST ignorando la documentación de doble vía, la obsolescencia y los planes de reversión.
Preguntas de seguimiento y respuestas
Si los clientes solo quieren menos solicitudes, ¿por qué no construir una agregación REST?
Cuantifique ambas opciones con grafos de llamadas y costos de mantenimiento. Los flujos de trabajo fijos, frecuentes y con límites claros favorecen un endpoint de agregación; las combinaciones que cambian continuamente entre muchos clientes hacen que un GraphQL acotado sea más valioso. Pruebe en piloto los mismos flujos de trabajo antes de elegir la superficie del protocolo.
¿Cómo evita que las consultas de GraphQL sobrecarguen el backend?
Aplique límites de profundidad, nodos, paginación y tiempos de espera en el borde; mantenga ponderaciones de costo por campo en el esquema; agrupe por lotes y almacene en caché en los resolvers; y limite la tasa de solicitudes (rate limit) por inquilino y prioridad. Registre el nombre de la operación, el costo estimado y el uso de recursos para las consultas rechazadas en lugar de devolver un error de servidor opaco.
¿Cuándo expondría mutaciones?
Únicamente después de que la autorización de solo lectura, los errores, la auditoría y la observabilidad sean estables. Comience con escrituras de bajo riesgo, idempotentes y compensables. Cada mutación necesita validación de entrada, semántica de conflictos, permisos, eventos de auditoría y comportamiento de reintento; las acciones financieras, de eliminación y entre inquilinos deben seguir siendo flujos de trabajo dedicados.
¿Cómo coexistirían REST y GraphQL?
Mantenga REST como la superficie de compatibilidad estable y use GraphQL para nuevos flujos de trabajo sin exigir paridad campo por campo. Comparta identidad, autorización de dominio, auditoría y SLOs, mientras mide por separado la migración de emisores de llamadas y el costo de cada superficie. Analice la obsolescencia de REST solo cuando el valor para el cliente, el costo operativo y el riesgo de compatibilidad estén respaldados por evidencia.