Laajennetaanpa GraphQL:n ongelmia GraphQL-ytimen etuna ei ole niin sanottu tyyppijärjestelmä, vaan vahvat tyyppirajoitteet voidaan toteuttaa hyvin RESTful-järjestelmissä. Hyödyntämällä täysimääräisesti Zodin orpc-järjestelmää, joka pystyy tuottamaan monipäätekoodia, FastAPI + Pydantic -ratkaisu Python-ekosysteemissä voi saavuttaa samankaltaisia vaikutuksia GraphQL:n keskeinen etu on, että se mahdollistaa asiakkaiden joustavan datan pyytämisen tarpeidensa mukaan. Tämä on myös yksi perinteisen BFF-kerroksen pääominaisuuksista. Ero perinteiseen BFF-kerrokseen on kuitenkin se, että GraphQL:n toteutus on yleensä vahvasti sidottu liiketoimintaan, eikä ole erillistä infrastruktuuria vastaavien ongelmien ratkaisemiseksi. Tässä tapauksessa joustavuus tuo mukanaan paljon ongelmia GraphQL-järjestelmässä (tai vastaavia BFF-järjestelmiä kohtaa alalle siirtymisen jälkeen). Yksinkertaisimmillaan joustavuus johtaa parempaan hyökkäyspintaan. Yksinkertaisimmillaan haitallinen käyttäjä voi rakentaa kyselyn niin monimutkaiseksi, että se kuluttaa suuren osan palvelinresursseistasi yksinkertaisella AST-jäsentyksellä. Toki monet saattavat sanoa: "Ah, mikset rajoita kyselyn monimutkaisuutta?" Joten kysyn, onko AST:ien ratkaiseminen vai AST:n ratkaiseminen välttämätöntä, kun lasketaan kyselyn monimutkaisuutta? Tietenkin jotkut saattavat sanoa, miksi ei rajoitettaisi kyselyn kaavaa? Sitten kysyn, pitääkö kaavojesi ratkaista myös AST:t? Ja rajoitat GraphQL:n suurinta etua, mikä on ero sinun ja perinteisten RESTful-rajapintojen välillä? Lisäksi, jos GraphQL:n AST-jäsennystä ei ratkaista liiketoiminnasta yksisäikeisellä Node-mallilla, tapahtumasilmukan viive räjähtää suoraan ja käyttäjäkokemus nousee N tasoa Monet asiat, joita GraphQL itse tarvitsee tehdä, täytyy ratkaista erillisellä infrastruktuurilla liiketoiminnan ratkaisemiseksi, kuten kyselytason nopeusrajoitukset, erityinen todennuslogiikka jne Rehellisesti sanottuna GraphQL voi olla hyvä valinta dataalustoille tai sisäisille palveluille. Kuitenkin suurten toC-palveluiden osalta GraphQL tuo mukanaan enemmän monimutkaisuutta ja epävarmuutta kuin perinteiset RESTful-rajapinnat, jotka vaativat enemmän infrastruktuurin kehitystä.