La oss utdype problemene med GraphQL Fordelen med GraphQL-kjernen er ikke det såkalte typesystemet, faktisk kan sterke typebegrensninger implementeres godt i RESTful-systemer. Ved å utnytte Zods orpc-skjema fullt ut, som kan generere flerterminalkode, kan FastAPI + Pydantic-løsningen i Python-økosystemet oppnå lignende effekter Hovedfordelen med GraphQL er at det lar klienter be om data fleksibelt etter behov. Dette er også en av hovedfunksjonene som er implementert av det tradisjonelle BFF-laget. Forskjellen fra det tradisjonelle BFF-laget er imidlertid at implementeringen av GraphQL vanligvis er sterkt bundet til virksomheten, og det finnes ingen separat infrastruktur for å håndtere lignende problemer. I dette tilfellet vil fleksibilitet føre til mange problemer under GraphQL-systemet (eller lignende BFF-ordninger vil oppstå etter å ha blitt etablert i virksomheten). På sitt enkleste vil fleksibilitet føre til en større angrepsflate. På sitt enkleste kan en ondsinnet bruker konstruere en spørring som er kompleks nok til å bruke mye av serverressursene dine gjennom enkel AST-parsing. Selvfølgelig vil mange si: «Ah, hvorfor begrenser du ikke kompleksiteten i Query?» Så la meg spørre deg, er det nødvendig å løse AST-er eller AST-er når man beregner kompleksiteten til Query? Selvfølgelig kan noen si, hvorfor ikke begrense mønsteret til Query? La meg spørre deg, må mønstrene dine også løse AST? Og du begrenser den største fordelen med GraphQL, hva er forskjellen mellom deg og tradisjonelle RESTful API-er? Dessuten, hvis GraphQLs AST-parsing ikke løses fra virksomheten, vil hendelsessløyfens forsinkelse med enkelttrådede Node bli direkte forhøyet, og brukeropplevelsen vil øke N nivåer Mange av tingene GraphQL selv må gjøre, må løses av en separat infrastruktur for å løse virksomheten, som spørringsnivå-hastighetsgrenser, spesiell autentiseringslogikk osv Ærlig talt kan GraphQL være et godt valg for dataplattformer eller interne tjenester. For toC-tjenester med stort volum vil imidlertid GraphQL bringe mer kompleksitet og usikkerhet enn tradisjonelle RESTful API-er, noe som vil kreve mer infrastrukturutvikling.