La pregunta que recibimos en cada kickoff
En 23 de nuestros últimos 30 kickoffs de migración, un arquitecto de plataforma ha hecho la misma pregunta dentro de la primera hora: “¿El nuevo sistema expondrá GraphQL?” La respuesta es no — y el razonamiento es el mismo cada vez. GraphQL es una buena opción para algunos problemas. La migración de Oracle Forms no es uno de ellos.
Este artículo explica por qué, basándonos en lo que hemos medido en 14 despliegues en producción.
Cómo se ve realmente el sistema de origen
Una aplicación de Oracle Forms es una colección de pantallas, cada una vinculada a un número reducido de bloques de base de datos. Un bloque se mapea a una tabla o vista. Las consultas están parametrizadas, los conjuntos de resultados están acotados, y la navegación entre pantallas pasa un puñado de claves. El patrón de acceso es estrecho, predecible y ya está descrito por los archivos .fmb originales.
La pantalla mediana en nuestra muestra consulta 2,3 tablas y ejecuta 4 consultas distintas. El percentil 95 alcanza 11 tablas y 19 consultas. Este no es un dominio donde los clientes necesiten componer grafos arbitrarios sobre la marcha.
REST se mapea a la forma existente
Cada bloque, trigger y LOV en un formulario migrado tiene un equivalente REST directo:
GET /api/orders?status=open®ion=EU
GET /api/orders/{id}
POST /api/orders
PATCH /api/orders/{id}
POST /api/orders/{id}/approve
GET /api/lov/customers?q=acm
El generador produce un endpoint por consulta de bloque, uno por LOV y uno por acción PL/SQL nombrada. La especificación OpenAPI se deriva del descriptor JSON automáticamente. Cada endpoint está tipado de extremo a extremo porque los tipos provienen del esquema de base de datos original, no de una capa de resolvers escrita a mano.
El coste de GraphQL del que nadie habla
El atractivo de GraphQL es la flexibilidad. Los clientes solicitan exactamente los campos que necesitan, los joins ocurren del lado del servidor y la sobre-consulta desaparece. Para una migración, esos beneficios se manifiestan como costes:
- Resolución N+1. Las pantallas de Forms ejecutan joins predecibles. Los resolvers de GraphQL tienen que reconstruir esos joins en tiempo de ejecución, y el batching de DataLoader añade una capa que no existía en el sistema de origen.
- Superficie de autorización. Las aplicaciones con alcance SOX necesitan control de acceso a nivel de campo. Los endpoints REST codifican los permisos a nivel de ruta; GraphQL los empuja a cada resolver. Medimos un incremento de 3,2x en código relacionado con autorización en un prototipo portado a GraphQL.
- Límites de complejidad de consulta. Los servidores GraphQL en producción necesitan límites de profundidad, análisis de costes y consultas persistentes para prevenir abuso. Nada de esto se necesita para un conjunto conocido de pantallas migradas.
- Caching. Las respuestas REST se cachean limpiamente a nivel de CDN y navegador. Los cuerpos POST de GraphQL no.
El argumento de la auditoría
Las migraciones de Oracle Forms frecuentemente están dentro del alcance de SOX, HIPAA o regímenes similares. Los auditores revisan las superficies de API. Una API REST con 240 endpoints y una especificación OpenAPI toma un día para revisarse. Un schema GraphQL con 80 tipos y composición arbitraria de consultas toma una semana — y el auditor aún tiene preguntas sobre qué consultas de cliente son realmente posibles en producción.
En una migración de servicios públicos, el equipo de auditoría solicitó explícitamente REST porque su matriz de control existente estaba construida alrededor de verbos HTTP y patrones de URL. Reconstruirla para GraphQL habría retrasado la aprobación SOX un trimestre.
Dónde GraphQL tendría sentido
No somos dogmáticos al respecto. GraphQL es una buena opción cuando los clientes son heterogéneos, el schema es amplio y las formas de consulta son impredecibles — aplicaciones móviles consultando un catálogo de productos, por ejemplo. Las migraciones de Oracle Forms no cumplen ninguna de esas condiciones. Los clientes son conocidos (las pantallas migradas), el schema está acotado (la base de datos que la aplicación Forms ya utiliza) y las consultas están enumeradas en los propios archivos .fmb.
Elegir REST aquí no es conservadurismo. Es hacer coincidir la herramienta con la forma del problema.
La conclusión
Cada endpoint en nuestro stack generado es REST, documentado en OpenAPI y derivado directamente de los metadatos originales de Forms. La decisión no se trata de qué estilo de API es mejor en abstracto. Se trata de cuál se mapea limpiamente a 30 años de acceso a base de datos vinculado a pantallas, y cuál los auditores pueden aprobar antes de que la primera pantalla entre en producción.