Let's talk about the issues with GraphQL. The core advantage of GraphQL is not the so-called type system; in fact, strong type constraints can also be well implemented within the RESTful framework. Utilizing Zod's ability to generate multi-endpoint code through the orpc solution, similar effects can be achieved with the FastAPI + Pydantic solution in the Python ecosystem. The most fundamental advantage of GraphQL lies in data flexibility, meaning that clients can request data as needed. This is also one of the main functions of a traditional BFF layer. However, unlike traditional BFF layers, the implementation of GraphQL is often strongly bound to the business, without a separate infrastructure to handle similar issues. In this situation, flexibility can lead to many problems, which are faced in the GraphQL system (or similar BFF solutions that are deeply integrated into the business). The simplest point is that flexibility brings a larger attack surface. The simplest example is that malicious users can construct sufficiently complex queries to consume your server resources significantly through simple AST parsing. Of course, many might say, "Well, just limit the complexity of the queries!" But I ask you, doesn't calculating the complexity of a query also require parsing the AST? Some might also say, "Then just limit the query patterns!" But I ask you, doesn't your pattern also need to parse the AST? Moreover, by limiting GraphQL's greatest advantage, how are you different from traditional RESTful APIs? Additionally, if the AST parsing of GraphQL is not separated from the business, combined with Node's single-threaded model, your event loop lag can directly lead to crashes, significantly degrading user experience. Many things that GraphQL needs to do require separate infrastructure to decouple from the business, such as query-level rate limiting, special authentication logic, etc. To be frank, for data platforms or internal services, GraphQL might be a decent choice. However, for high-volume toC businesses, GraphQL can introduce more complexity and uncertainty compared to traditional RESTful APIs, and it will heavily rely on infrastructure development.