Ci sono degli svantaggi in GraphQL? [chiuso]

Tutti gli articoli su GraphQL ti diranno quanto è meraviglioso, ma ci sono degli svantaggi o dei difetti? Grazie.

Svantaggi:

• Devi imparare come configurare GraphQL. L'ecosistema è ancora in rapida evoluzione, quindi devi stare al passo.
• Devi inviare le query dal client, puoi semplicemente inviare stringhe ma se vuoi più comfort e memorizzazione nella cache utilizzerai una libreria client -> codice extra nel tuo client
• È necessario definire lo schema in anticipo => lavoro extra prima di ottenere risultati
• Devi avere un endpoint graphql sul tuo server => nuove librerie che non conosci ancora
• Le query Graphql sono più byte rispetto al semplice passaggio a un endpoint REST
• Il server deve eseguire ulteriori elaborazioni per analizzare la query e verificare i parametri

Ma quelli sono più che contrastati da questi:

• GraphQL non è così difficile da imparare
• Il codice aggiuntivo è solo di pochi KB
• Definendo uno schema, impedirai molto più lavoro dopo la correzione di bug e gli aggiornamenti duraturi
• Ci sono molte persone che passano a GraphQL, quindi c'è un ricco ecosistema in via di sviluppo, con strumenti eccellenti
• Quando si utilizzano query persistenti in produzione (sostituendo le query GraphQL semplicemente con un ID e parametri), si inviano effettivamente meno byte rispetto a REST
• L'elaborazione aggiuntiva per le query in arrivo è trascurabile
• Fornire un disaccoppiamento pulito di API e backend consente un'iterazione molto più rapida sui miglioramenti del backend

Ho riscontrato alcune preoccupazioni importanti per chiunque stia pensando di utilizzare GraphQL e fino ad ora i punti principali sono:

Query in profondità indefinita : GraphQL non può eseguire query in profondità indefinita, quindi se hai un albero e vuoi restituire un ramo senza conoscere la profondità, dovrai fare un po 'di impaginazione.

Struttura di risposta specifica : in GraphQL la risposta corrisponde alla forma della query, quindi se devi rispondere in una struttura molto specifica, dovrai aggiungere un livello di trasformazione per rimodellare la risposta.

Cache a livello di rete : a causa del modo in cui GraphQL viene comunemente utilizzato su HTTP (un POST in un singolo endpoint), la cache a livello di rete diventa difficile. Un modo per risolverlo è utilizzare Persisted Queries.

Gestione del caricamento dei file : non c'è nulla sul caricamento dei file nella specifica GraphQL e le mutazioni non accettano i file negli argomenti. Per risolverlo puoi caricare file utilizzando altri tipi di API (come REST) ​​e passare l'URL del file caricato alla mutazione GraphQL, oppure iniettare il file nel contesto di esecuzione, così avrai il file all'interno delle funzioni del resolver.

Esecuzione imprevedibile : la natura di GraphQL è che è possibile eseguire query combinando qualsiasi campo si desideri, ma questa flessibilità non è gratuita. Ci sono alcune preoccupazioni che è bene sapere come Prestazioni e N + 1 Query.

API super semplici : nel caso in cui tu abbia un servizio che espone un'API molto semplice, GraphQL aggiungerà solo una complessità extra, quindi una semplice API REST può essere migliore.

Questo problema più grande che vedo con graphQL, cioè se stai usando con database relazionali, è con i join .

1. Il fatto che tu possa consentire / non consentire alcuni campi rende i join non banali (non semplici). Il che porta a domande extra.

2. Anche le query annidate in graphql portano a query circolari e possono mandare in crash il server . È necessario prestare particolare attenzione.

3. La limitazione della velocità delle chiamate diventa difficile perché ora l'utente può inviare più query in una chiamata.

SUGGERIMENTO : usa il dataloader di Facebook per ridurre il numero di query in caso di javascript / node

Sta migliorando ogni anno e, per ora, la comunità di GraphQL sta crescendo e, di conseguenza, ci sono molte più soluzioni a molti problemi che sono stati evidenziati in altre risposte prima. Ma per ammettere ciò che ancora impedisce alle aziende di gettare tutte le risorse su GraphQL, vorrei elencare alcuni problemi e soluzioni seguiti da quelli irrisolti.

• Cache a livello di rete : come ha detto Bruno, si tratta di query persistenti e ovviamente puoi memorizzare nella cache su un client e nessuno ti impedisce di utilizzare la cache a livello di database o anche Redis. Ma ovviamente, poiché GraphQL ha un solo endpoint e ogni query è diversa, è molto più complicato eseguire questo tipo di memorizzazione nella cache rispetto a REST.
• Le query annidate in GraphQL portano a query circolari e possono mandare in crash il server - non più un problema con una vasta gamma di soluzioni. Alcuni di loro sono elencati qui
• Gestione File Upload - abbiamo già un sacco di soluzioni per esso

Ma ci sono un paio di altri casi che possono essere considerati svantaggi:

• boilerplate eccessività (con questo intendo, per creare ad esempio una nuova query è necessario definire schema, resolver e all'interno del resolver per dire esplicitamente GraphQL come risolvere i propri dati e campi all'interno, sul lato client creare query con esattamente i campi relativi a questi dati)
• gestione degli errori : devo dire che è più correlato al confronto con REST. È possibile qui con apollo ma allo stesso tempo è molto più complicato che in REST
• autenticazione e autorizzazione - ma come ho detto la comunità sta aumentando con una velocità eccezionale e ci sono già un paio di soluzioni per questo obiettivo.

Per riassumere, GraphQL è solo uno strumento per obiettivi specifici e di sicuro non è un proiettile d'argento a tutti i problemi e ovviamente non è un sostituto per REST.

È davvero fantastico avere un unico endpoint ed esporre tutti i dati. Trovo di seguito i punti da considerare per GraphQL:

1. L'implementazione di Download / Upload di file diventa complicata (la conversione in stringa potrebbe non essere l'opzione migliore per file di grandi dimensioni)
2. Molto codice boilerplate e schema sia sul frontend che sul backend.
3. Seguire e supportare l'impaginazione fornita nella specifica GraphQL.
4. Consenti ordine personalizzato e logica di assegnazione delle priorità per l'ordinamento dei campi. Esempio se recuperiamo i dati degli utenti e i gruppi e i ruoli associati. Un utente può ordinare più i dati in base al nome utente, al nome del gruppo o al nome del ruolo.
5. L'autenticazione e l'autorizzazione dipendono dal framework di backend.
6. Assicurati che l'ottimizzazione del back-end e il supporto del database per attivare una singola query per ogni comando graphql potrebbero essere complicati.

Inoltre, si dovrebbero considerare i pro dopo la sua implementazione:

1. Molto flessibile per supportare nuovi elementi e aggiornare il comportamento esistente.

2. Facile da aggiungere condizioni utilizzando argomenti e ordinamento personalizzato una volta implementato

3. Usa molti filtri personalizzati e sbarazzati di tutte le azioni che devono essere create, ad esempio un utente può avere ID, nome, ecc. Come argomenti ed eseguire il filtro. Inoltre, i filtri possono essere applicati anche ai gruppi negli utenti.

4. Facilità di test dell'API creando file contenenti tutte le query e le mutazioni GraphQL.
5. Le mutazioni sono dirette e facili da implementare una volta compreso il concetto.
6. Un modo potente per recuperare più profondità di dati.
7. Il supporto di Voyager e GraphiQL UI o Playground lo rende facile da visualizzare e utilizzare.
8. Facilità di documentazione durante la definizione dello schema con metodi di descrizione validi.

Penso che graphql per il momento debba far parte dell'architettura backend, per il caricamento dei file si continua a colpire un'API normale