Hablemos sobre los problemas de GraphQL. La ventaja principal de GraphQL no es el sistema de tipos, de hecho, las restricciones de tipo fuerte también se pueden implementar muy bien en un sistema RESTful. Se aprovecha al máximo la solución orpc de Zod que puede generar código para múltiples plataformas, y la combinación de FastAPI + Pydantic en el ecosistema de Python puede lograr un efecto similar. La ventaja más importante de GraphQL radica en la flexibilidad de los datos, es decir, el cliente puede solicitar datos de manera flexible según sus necesidades. Esta es también una de las funciones principales que implementa la capa BFF tradicional. Sin embargo, a diferencia de la capa BFF tradicional, la implementación de GraphQL suele estar fuertemente vinculada al negocio, sin separar una infraestructura independiente para manejar problemas similares. En esta situación, la flexibilidad puede traer muchos problemas, que son los que enfrentan los sistemas GraphQL (o problemas similares que surgen cuando la solución BFF se sumerge en el negocio). El punto más simple es que la flexibilidad traerá una mayor superficie de ataque. Lo más sencillo es que un usuario malintencionado puede construir una consulta lo suficientemente compleja para consumir en gran medida los recursos de tu servidor a través de un simple análisis de AST. Por supuesto, muchas personas pueden decir: "Ah, simplemente limita la complejidad de la consulta, ¿no?" Entonces te pregunto, ¿no necesitas también analizar el AST para calcular la complejidad de la consulta? Por supuesto, también hay quienes pueden decir: "Entonces, ¿por qué no limitas el patrón de la consulta?" Entonces te pregunto, ¿no necesitas también analizar el AST para tu patrón? Además, al limitar la mayor ventaja de GraphQL, ¿en qué te diferencias de una API RESTful tradicional? Además, si no se separa el análisis del AST de GraphQL del negocio, junto con el modelo de un solo hilo de Node, tu bucle de eventos se verá afectado y la experiencia del usuario se verá gravemente afectada. Muchas de las cosas que GraphQL debe hacer requieren una infraestructura separada para desvincularse del negocio, como el límite de tasa a nivel de consulta, lógica de autenticación especial, etc. Para ser honesto, para plataformas de datos o servicios internos, GraphQL puede ser una buena opción. Pero para negocios de consumo masivo, GraphQL puede traer más complejidad e incertidumbre que una API RESTful tradicional, y requerirá un desarrollo de infraestructura considerable.