Låt oss utveckla problemen med GraphQL Fördelen med GraphQL-kärnan är inte det så kallade typsystemet, faktiskt kan starka typbegränsningar implementeras väl i RESTful-system. Genom att utnyttja Zods orpc-schema fullt ut, som kan generera flerterminalkod, kan FastAPI + Pydantic-lösningen i Python-ekosystemet uppnå liknande effekter Den grundläggande fördelen med GraphQL är att det låter klienter begära data flexibelt efter sina behov. Detta är också en av huvudfunktionerna som implementeras av det traditionella BFF-lagret. Skillnaden från det traditionella BFF-lagret är dock att implementeringen av GraphQL vanligtvis är starkt bunden till verksamheten, och det finns ingen separat infrastruktur för att hantera liknande problem. I det här fallet kommer flexibilitet att medföra många problem under GraphQL-systemet (eller liknande BFF-system kommer att möta efter att ha sjunkit in i verksamheten). I enklaste form leder flexibilitet till en större attackyta. I sitt enklaste uttryck kan en illvillig användare konstruera en fråga som är tillräckligt komplex för att förbruka mycket av dina serverresurser genom enkel AST-parsing. Självklart kan många säga, "Ah, varför begränsar du inte komplexiteten i Query?" Så låt mig fråga dig, är det nödvändigt att lösa AST eller lösa AST när man beräknar komplexiteten i Query? Självklart kan vissa säga, varför inte begränsa Queryns mönster? Då får jag fråga dig, behöver dina mönster också lösa AST:er? Och du begränsar den största fördelen med GraphQL, vad är skillnaden mellan dig och traditionella RESTful API:er? Dessutom, om GraphQL:s AST-parsing inte löses från affärssidan, kommer din event loop-fördröjning direkt att försämras med Nodes enkeltrådade modell och användarupplevelsen kommer att öka med N nivåer Många av de saker som GraphQL själv behöver göra måste lösas av en separat infrastruktur för att lösa verksamheten, såsom hastighetsgränser på frågenivå, speciell autentiseringslogik, etc Ärligt talat kan GraphQL vara ett bra val för dataplattformar eller interna tjänster. För högvolyms ToC-tjänster kommer dock GraphQL att medföra mer komplexitet och osäkerhet än traditionella RESTful API:er, vilket kommer att kräva mer infrastrukturutveckling.