Laten we de problemen van GraphQL eens uitgebreider bespreken. De kernvoordelen van GraphQL liggen niet in het zogenaamde type-systeem; in feite kunnen sterke typebeperkingen ook goed worden gerealiseerd binnen een RESTful systeem. Het benut de orpc-oplossing van Zod die multi-platform code kan genereren, en de FastAPI + Pydantic-oplossing in de Python-ecosysteem kan vergelijkbare resultaten opleveren. Het belangrijkste voordeel van GraphQL is de flexibiliteit in dataverzoeken, wat betekent dat de client gegevens kan opvragen op basis van zijn eigen behoeften. Dit is ook een van de belangrijkste functies van de traditionele BFF-laag. Echter, in tegenstelling tot de traditionele BFF-laag, is de implementatie van GraphQL vaak sterk verbonden met de business, zonder dat er een aparte infrastructuur is om soortgelijke problemen aan te pakken. In deze situatie kan flexibiliteit veel problemen met zich meebrengen, die zowel in het GraphQL-systeem als in soortgelijke BFF-oplossingen die in de business zijn geïntegreerd, kunnen optreden. Het eenvoudigste punt is dat flexibiliteit een groter aanvalsvlak met zich meebrengt. Het eenvoudigste voorbeeld is dat kwaadwillende gebruikers complexe queries kunnen opstellen die, door simpelweg de AST te parseren, veel van je serverresources kunnen verbruiken. Natuurlijk zullen veel mensen zeggen: "Oh, je kunt de complexiteit van de query beperken, toch?" Maar ik vraag je, vereist het berekenen van de complexiteit van de query niet ook het ontleden van de AST? En anderen zullen misschien zeggen: "Waarom beperk je niet het patroon van de query?" Maar ik vraag je, moet je patroon niet ook de AST ontleden? En door de grootste voordelen van GraphQL te beperken, wat is dan het verschil met traditionele RESTful API's? Bovendien, als de AST-analyse van GraphQL niet van de business wordt losgekoppeld, kan dit in combinatie met het single-threaded model van Node ervoor zorgen dat je event loop lag direct wordt aangetast, wat de gebruikerservaring aanzienlijk verslechtert. Veel dingen die GraphQL zelf moet doen, vereisen aparte infrastructuur om los van de business te functioneren, zoals rate limiting op query-niveau, speciale autorisatie-logica, enzovoort. Eerlijk gezegd, voor dataplatforms of interne diensten kan GraphQL een goede keuze zijn. Maar voor toC-bedrijven met een hoge volume kan GraphQL meer complexiteit en onzekerheid met zich meebrengen dan traditionele RESTful API's, en het zal extra ontwikkelingsinspanningen voor de infrastructuur vereisen.