Pojďme rozvést problémy s GraphQL Výhodou jádra GraphQL není takzvaný typový systém, ve skutečnosti lze silná typová omezení dobře implementovat v RESTful systémech. Plně využívající Zodův orpc schématu, který dokáže generovat multiterminálový kód, může řešení FastAPI + Pydantic v ekosystému Python dosáhnout podobných efektů Hlavní výhodou GraphQL je, že umožňuje klientům flexibilně žádat o data podle svých potřeb. To je také jedna z hlavních funkcí implementovaných tradiční vrstvou BFF. Rozdíl oproti tradiční vrstvě BFF je však v tom, že implementace GraphQL je obvykle silně vázána na podnik a neexistuje samostatná infrastruktura pro řešení podobných problémů. V tomto případě flexibilita přinese pod systém GraphQL mnoho problémů (nebo se podobné BFF schémata objeví po vstoupení do podnikání). V nejjednodušší formě flexibilita vede k větší útočné ploše. V nejjednodušším případě může škodlivý uživatel vytvořit dotaz natolik složitý, že spotřebuje velké množství vašich serverových zdrojů, pomocí jednoduchého AST parsování. Samozřejmě, mnoho lidí si může říct: "Proč neomezíte složitost Query?" Tak se vás zeptám, je nutné řešit ASTy nebo ASTs při výpočtu složitosti Query? Samozřejmě, někteří lidé mohou říct, proč neomezit vzorec dotazu? Tak se tě zeptám, potřebují tvoje vzory také řešit AST? A pokud omezujete největší výhodu GraphQL, jaký je rozdíl mezi vámi a tradičními RESTful API? Navíc, pokud se AST parsování v GraphQL nevyřeší z podniku, s jednovláknovým modelem Node, vaše event loop lag bude přímo nafouknuta a uživatelská zkušenost vzroste o N úrovní Mnoho věcí, které GraphQL sám musí dělat, musí vyřešit samostatná infrastruktura pro řešení podniku, jako jsou limity rychlosti na úrovni dotazů, speciální autentizační logika atd Upřímně řečeno, GraphQL může být dobrou volbou pro datové platformy nebo interní služby. Nicméně u služeb s vysokým objemem toC přinese GraphQL více složitosti a nejistoty než tradiční RESTful API, která vyžadují více vývoje infrastruktury.