Parliamo dei problemi di GraphQL. Il principale vantaggio di GraphQL non è il cosiddetto sistema di tipi; in realtà, i vincoli di tipo forte possono essere implementati molto bene anche nel sistema RESTful. Sfruttando appieno la soluzione orpc di Zod, che può generare codice multi-piattaforma, anche la combinazione di FastAPI + Pydantic nell'ecosistema Python può ottenere risultati simili. Il vantaggio principale di GraphQL risiede nella flessibilità dei dati, ovvero il client può richiedere i dati in modo flessibile in base alle proprie esigenze. Questo è anche uno dei principali compiti realizzati dal tradizionale livello BFF. Tuttavia, a differenza del tradizionale livello BFF, l'implementazione di GraphQL è spesso fortemente legata al business, senza separare un'infrastruttura dedicata per gestire problemi simili. In questa situazione, la flessibilità porterà a molti problemi, che si presenteranno nel sistema GraphQL (o in soluzioni BFF simili integrate nel business). Il punto più semplice è che la flessibilità porterà a una superficie di attacco più ampia. Il punto più semplice è che un utente malintenzionato può costruire una Query sufficientemente complessa per consumare enormemente le risorse del tuo server attraverso una semplice analisi AST. Certo, molti potrebbero dire: "Ah, basta limitare la complessità della Query, giusto?" Allora ti chiedo, calcolare la complessità della Query non richiede anche di analizzare l'AST? Naturalmente, ci sarà chi dirà: "Basta limitare il Pattern della Query, giusto?" Allora ti chiedo, il tuo Pattern non richiede anche di analizzare l'AST? Inoltre, limitando il massimo vantaggio di GraphQL, che differenza c'è con le tradizionali API RESTful? Inoltre, se l'analisi dell'AST di GraphQL non viene separata dal business, insieme al modello a thread singolo di Node, il tuo Event loop lag verrà direttamente amplificato, e l'esperienza utente subirà un notevole deterioramento. Molte delle cose che GraphQL deve fare richiedono un'infrastruttura separata per essere disaccoppiate dal business, come il Rate Limit a livello di Query, logiche di autenticazione speciali, ecc. A dire il vero, per piattaforme dati o servizi interni, GraphQL potrebbe essere una scelta piuttosto valida. Tuttavia, per le attività toC che hanno raggiunto un certo volume, GraphQL porterà più complessità e incertezze rispetto alle tradizionali API RESTful, richiedendo uno sviluppo infrastrutturale particolarmente intenso.