Vamos a ampliar los problemas de GraphQL La ventaja del núcleo GraphQL no es el llamado sistema de tipos; de hecho, las restricciones de tipos fuertes pueden implementarse bien en sistemas RESTful. Aprovechando al máximo el esquema orpc de Zod, que puede generar código multiterminal, la solución FastAPI + Pydantic en el ecosistema Python puede lograr efectos similares La principal ventaja de GraphQL es que permite a los clientes solicitar datos de forma flexible según sus necesidades. Esta es también una de las principales características implementadas por la capa tradicional BFF. Sin embargo, la diferencia respecto a la capa tradicional BFF es que la implementación de GraphQL suele estar fuertemente ligada al negocio, y no existe una infraestructura separada para abordar problemas similares. En este caso, la flexibilidad traerá muchos problemas bajo el sistema GraphQL (o se enfrentarán esquemas similares de BFF tras sumergirse en el negocio). En su forma más simple, la flexibilidad conducirá a una superficie de ataque mayor. En su forma más simple, un usuario malicioso puede construir una consulta lo suficientemente compleja como para consumir muchos de los recursos de tu servidor mediante un simple análisis AST. Por supuesto, mucha gente puede decir: "Ah, ¿por qué no limitáis la complejidad de Query?" Así que déjame preguntarte, ¿es necesario resolver ASTs o resolver ASTs al calcular la complejidad de una consulta? Por supuesto, algunas personas pueden decir, ¿por qué no limitar el patrón de la Consulta? Entonces déjame preguntarte, ¿tus patrones también necesitan resolver ASTs? Y limitas la mayor ventaja de GraphQL, ¿cuál es la diferencia entre tú y las APIs RESTful tradicionales? Además, si el análisis AST de GraphQL no se resuelve desde el negocio con el modelo de un solo hilo de Node, el lag del bucle de eventos se verá directamente afectado y la experiencia de usuario subirá a niveles N Muchas de las cosas que GraphQL necesita hacer deben ser resueltas por una infraestructura separada para resolver el negocio, como límites de velocidad a nivel de consulta, lógica especial de autenticación, etc Francamente, GraphQL puede ser una buena opción para plataformas de datos o servicios internos. Sin embargo, para servicios toC de alto volumen, GraphQL aportará más complejidad e incertidumbre que las APIs RESTful tradicionales, que requerirán más desarrollo de infraestructura.