Può essere difficile scegliere le tecnologie da includere nello stack tecnologico del vostro prossimo progetto. In molti casi, e soprattutto quando si tratta di scegliere tra API GraphQL e RESTful, tutto si riassume in quale delle due architettura di progettazione API utilizzare.
Esistono quattro modi principali per costruire le API: SOAP, GRPC, REST e GraphQL. Spesso ci concentriamo su REST e GraphQL quando vogliamo costruire delle API. Questo perché REST ha cambiato i metodi tradizionali di costruzione delle API con SOAP e GRPC.
GraphQL è ampiamente considerato un REST migliore perché rappresenta un modo più efficace di costruire le API. Molte persone che si occupano di sviluppo ritengono che GraphQL sostituirà REST. Molti altri hanno già scoperto che GraphQL aiuta a risolvere alcune sfide comuni che sviluppatrici e sviluppatori devono affrontare durante la creazione di API REST.
Questi due metodi di costruzione delle API sono completamente diversi. In pratica, queste tecnologie funzionano inviando una richiesta HTTP e ricevendo il risultato. Entrambe hanno i loro pro e contro e in questo articolo parleremo diffusamente di queste due grandi tecnologie che hanno cambiato il modo di sviluppare e scalare le API.
Prima di addentrarci nei dettagli, però, esploriamo il significato di GraphQL e API RESTful.
Cos’È GraphQL?
GraphQL è un linguaggio di interrogazione delle API e un runtime per rispondere a tali interrogazioni con i dati esistenti. Inoltre è dotato di potenti strumenti per gestire anche le query più complesse.
La caratteristica principale di GraphQL è la capacità di richiedere e ricevere solo i dati specifici richiesti, niente di più. Questo rende molto più semplice scalare le vostre API insieme alla vostra applicazione.
L’aspetto più interessante di GraphQL è la sua capacità di fornire tutti i dati in un unico endpoint.
Il diagramma qui sopra è una tipica rappresentazione dell’architettura GraphQL. I clienti fanno richieste da diversi dispositivi e GraphQL gestisce le loro richieste e restituisce solo i dati richiesti. In questo modo si risolve il problema dell’over-fetching e dell’under-fetching delle API RESTful.
Nell’esempio qui sopra, mostriamo un ambiente GraphQL e il modo in cui potete interrogare i dati con un singolo endpoint. In alto c’è l’endpoint dell’API, a sinistra la query che richiede i nomi dei continenti e infine, a destra, la risposta alla query richiesta.
GraphQL è stato creato da Facebook con lo scopo principale di risolvere l’esperienza di chi sviluppa applicazioni mobili che lavorano con le API REST. Da quando è stata rilasciata la prima versione open-source nel 2015, GraphQL ha registrato una crescita enorme grazie all’adozione della tecnologia da parte di grandi aziende del settore tecnologico.
Aziende Che Usano GraphQL
Di seguito elenchiamo solo alcune delle aziende e delle applicazioni che usano GraphQL attivamente sui loro server.
Facebook ha creato GraphQL e lo utilizza in produzione per le sue applicazioni mobili dal 2012. L’azienda multimiliardaria di social network ha reso pubbliche le specifiche di GraphQL nel 2015, rendendole accessibili in molti ambienti e a team di ogni dimensione.
GitHub
Anche GitHub ha dichiarato di usare GraphQL fornendo un’API GraphQL per creare integrazioni, recuperare dati e automatizzare i flussi di lavoro tramite l’API GraphQL di GitHub. L’API GraphQL di GitHub offre query più precise e flessibili rispetto all’API REST di GitHub.
Anche Pinterest è uno dei primi utilizzatori di GraphQL. Il gigante della condivisione di foto ha discusso pubblicamente la sua esplorazione iniziale di GraphQL e il modo in cui usa la tecnologia GraphQL che alimenta la sua azienda da un miliardo di dollari.
Molte altre aziende miliardarie come Intuit, Shopify, Coursera e Airbnb alimentano le loro applicazioni con GraphQL. E questa ampia preferenza per REST non fa che crescere.
Cos’È un’API RESTful?
REST è l’acronimo di “Representational State Transfer”, uno stile architettonico per sistemi ipermediali distribuiti. Definisce principi e vincoli per lo scambio di risorse tra il server e i client.
Se questi principi vengono seguiti in un’API, l’applicazione di quell’API viene definita “RESTful”. L’API REST di WordPress ne è un esempio lampante.
Di seguito sono elencati alcuni dei principi e dei vincoli che un’API deve soddisfare per essere definita API Restful:
- Decouple client-server: I client (frontend) e il server (backend) sono completamente separati e possono comunicare solo attraverso gli endpoint.
- Interfaccia uniforme: I dati visualizzati nell’interfaccia sono identici su tutti i dispositivi.
- Statelessness (assenza di stato): Il server non ricorda se la richiesta corrente viene effettuata per la prima volta o meno. Ogni volta che viene effettuata una richiesta, deve includere tutte le informazioni necessarie per elaborarla da zero.
- Cacheability: La cache e l’archiviazione delle sessioni sono consentite, ma devono essere configurate in modo da permettere agli utenti finali di non utilizzare la cache dei dati.
- Architettura di sistema a strati: Le API devono essere progettate in modo che né il client né il server possano sapere se stanno comunicando direttamente o attraverso un intermediario.
Il diagramma sottostante rappresenta l’architettura REST di base. Mostra come vengono gestite le richieste e le risposte.
Vantaggi di GraphQL
Vi elenchiamo alcuni vantaggi dell’uso di GraphQL, che illustrano perché è più che sufficiente per costruire la prossima app da un miliardo di dollari.
Recuperare i Dati Attraverso un Singolo Endpoint API
Il vantaggio principale di GraphQL è la possibilità di accedere a tutti i dati attraverso un unico endpoint API.
Uno dei problemi più comuni delle API RESTful è quello di avere troppi endpoint per accedere alle informazioni. Con GraphQL, invece, avete un solo endpoint, quindi non dovete inviare più richieste per recuperare diverse informazioni su un oggetto.
Il diagramma sottostante mostra un chiaro esempio di recupero di risorse tramite API RESTful e GraphQL. Potete vedere che c’è un solo endpoint per accedere alla risorsa nel server GraphQL, mentre sono necessari più endpoint API per accedere a diverse risorse nell’API RESTful.
Nessun Over-Fetching o Under-Fetching
Il problema dell’over-fetching o dell’under-fetching è un problema noto delle API RESTful. Ciò accade quando i clienti scaricano i dati colpendo endpoint che restituiscono strutture di dati fisse, oppure recuperano più o meno di quanto previsto.
L’over-fetching fa sì che la richiesta riceva – o “recuperi” – più dati di quelli richiesti da una determinata richiesta. Immaginate di recuperare tutti gli utenti di una tabella con l’intenzione di visualizzare i loro nomi nella vostra homepage. In questo caso, l’over-fetching restituirà tutti i dati di ogni utente, compreso (ma non solo) il nome.
L’under-fetching è relativamente raro, ma si verifica quando l’endpoint specifico non riesce a fornire tutte le informazioni richieste. Il cliente dovrà effettuare ulteriori richieste per accedere alle altre informazioni necessarie.
GraphQL risolve in modo efficiente il problema dell’over-fetching o dell’under-fetching, recuperando l’esatta risorsa richiesta dal cliente senza alcun dettaglio aggiuntivo.
Migliore Gestione di Sistemi Complessi e Microservizi
GraphQL può unificare e nascondere la complessità di sistemi multipli integrati.
Per esempio, supponiamo di voler migrare da un’applicazione backend monolitica a un’architettura a microservizi. L’API GraphQL aiuta a gestire la comunicazione tra vari microservizi unendoli in un unico schema GraphQL.
Una volta definiti questi schemi, sia il frontend che il backend possono comunicare separatamente senza ulteriori modifiche, poiché il frontend sa che i dati dello schema saranno sempre sincronizzati in tutto il sistema.
Veloce e Sicuro
Il problema dell’over-fetching può comportare un maggiore consumo di banda per i client che, a lungo andare, può causare rallentamenti nell’applicazione. L’utilizzo di modelli di progettazione delle API RESTful richiede più tempo per selezionare le informazioni necessarie da un carico enorme.
Grazie alla capacità di GraphQL di evitare l’over fetching e l’under fetching, il server restituisce una forma sicura, facile da leggere e prevedibile che rende le richieste e le risposte dell’API più veloci.
Vantaggi di REST
Nonostante la crescente popolarità di GraphQL, REST è ancora uno degli standard API più diffusi. Vediamo perché.
- Curva di apprendimento: Le API RESTful sono le più facili da imparare e da capire. Questo è il suo principale vantaggio rispetto alle altre API.
- Serializzazione: REST offre un approccio flessibile e formati per la serializzazione dei dati in JSON.
- Caching: Le API REST possono gestire un carico elevato con l’aiuto di un server proxy HTTP e della cache.
- Richieste complesse: Le API REST hanno un endpoint separato per le diverse richieste e questo aiuta a rendere le richieste complesse più gestibili rispetto ad altre API
- Semplici e pulite: Le API REST sono eleganti, semplici e pulite. Sono facili da esplorare.
- Procedure HTTP standard: REST usa procedure HTTP standard per recuperare dati e fare richieste.
- Client/Server: Ciò significa che la logica aziendale è disaccoppiata dalla presentazione. Quindi potete cambiare l’una senza influenzare l’altra.
- REST è stateless: Tutti i messaggi scambiati tra client e server hanno il contesto necessario per sapere cosa fare con il messaggio.
Svantaggi di GraphQL
Ora che abbiamo discusso i pro di GraphQL rispetto a REST, analizziamo alcuni degli svantaggi di GraphQL:
- Curva di apprendimento ripida: GraphQL non è facile da imparare come REST. La parte più impegnativa della creazione di un’API GraphQL è la progettazione dello schema. Questo richiede molto tempo e conoscenza del dominio.
- Caricamento dei file: GraphQL non dispone di una funzione nativa per il caricamento dei file. Si può ovviare a questo problema utilizzando la codifica Base64, ma il costo della codifica e della decodifica in questo modo può essere lungo e costoso.
- Web Caching: Il caching aiuta a ridurre il traffico frequente verso il server, velocizzando le richieste e il processo di risposta grazie alla possibilità di mantenere le informazioni di frequente accesso vicino al server. GraphQL non supporta né si affida ai metodi di caching HTTP, ma dipende dai meccanismi di caching dei client Apollo o Relay.
- Non adatto alle piccole applicazioni: GraphQL potrebbe non essere la migliore architettura API per la creazione di una piccola applicazione. Se la vostra applicazione non richiede le query più flessibili offerte da GraphQL, REST è la soluzione migliore.
- Problemi di query complesse: La capacità di GraphQL di dare al cliente esattamente ciò che vuole può anche portare a problemi di propagazione delle query. Se un cliente invia un numero eccessivo di query annidate, può capitare che vengano inviate le query sbagliate, il che può comportare un notevole dispendio di tempo per il server. È meglio usare REST con endpoint personalizzati per soddisfare tali richieste.
Gli Svantaggi di REST
Ora, rivolgiamo la nostra attenzione ad alcuni degli svantaggi di REST:
- Viaggi multipli di andata e ritorno: Il problema principale delle API REST è la natura dei numerosi endpoint. Ciò significa che per ottenere tutte le risorse di un’applicazione completa, il client deve fare innumerevoli viaggi di andata e ritorno per ottenere i dati.
- Over-fetching e Under-fetching: Il problema dell’over-fetching e dell’under-fetching è uno dei principali inconvenienti delle API RESTful. Può causare ritardi nelle risposte a causa dell’acquisizione di grandi carichi di dati indesiderati.
- Gerarchia: Poiché le API REST sono costruite su risorse che fanno riferimento a URI, non sono adatte a risorse che non sono naturalmente organizzate o accessibili in una gerarchia semplice.
Perché Usare GraphQL Invece di REST?
A seguire, parleremo dei motivi per cui potreste prendere in considerazione GraphQL per il vostro futuro sviluppo di API invece di API RESTful.
Schema Fortemente Tipizzato
GraphQL usa un sistema di tipi forti per definire le funzionalità dell’API. In GraphQL, il linguaggio di definizione dello schema (SDL) si usa per definire i parametri relativi alle modalità di accesso del client ai dati del server. Tutte le API esposte al cliente sono scritte in SDL, risolvendo il problema dell’incoerenza dei dati che si riscontra nelle API RESTful.
Nessun Over-Fetching o Under-Fetching
Il problema dell’over-fetching o dell’under-fetching è un problema noto delle API RESTful, in cui i clienti ricevono più o meno informazioni di quelle richieste. GraphQL risolve questo problema fornendo al cliente un mezzo per specificare le informazioni necessarie e restituendo esattamente – e solo – quelle informazioni specifiche.
Endpoint Multipli
Uno dei maggiori problemi delle API RESTful è quello di avere troppi endpoint per accedere alle informazioni.
Supponiamo che vogliate accedere a un particolare utente tramite il suo numero ID. Vi verrebbe presentato un endpoint come /users/1. Ma se volete accedere alle foto di quell’utente, dovrete inviare una richiesta a un altro endpoint, come /users/1/photos.
Con GraphQL, invece, avete un unico endpoint e non dovete inviare più richieste per recuperare diverse informazioni sull’utente.
Prova di Forza tra GraphQL e REST
Infine, analizzeremo le principali differenze tra GraphQL e le API RESTful. In seguito discuteremo alcune delle caratteristiche di un buon design di API e confronteremo il modo in cui ciascuna tecnologia le gestisce.
Prestazioni
Non c’è dubbio che GraphQL sia più veloce delle API RESTful grazie alla sua capacità di fornire un unico endpoint per accedere a tutte le risorse. Le API RESTful utilizzano più endpoint, il che potrebbe comportare una latenza di rete.
Complessità delle Query
Poiché gli endpoint non sono separati in più endpoint, le query GraphQL possono diventare sempre più complesse nel tempo. Gli endpoint delle API RESTful, invece, sono separati e questo limita le API RESTful a query semplici.
Popolarità e Supporto della Comunità
GraphQL è un modello architettonico di API e un linguaggio di query in crescita. Sebbene sia ancora giovane, il suo tasso di adozione e il suo bacino di risorse stanno crescendo rapidamente e le risorse abbondano già per chi vuole impararlo in autonomia.
REST, invece, vanta già un vasto supporto da parte della comunità e continua a essere utilizzato da aziende di ogni tipo, da quelle che costruiscono piccoli microservizi a quelle che creano complesse app social e non solo.
Al momento, la gara di popolarità tra GraphQL e REST è un pareggio. Entrambe le tecnologie continuano a essere ampiamente utilizzate e ben supportate dalla comunità di sviluppatori.
Curva di Apprendimento
La curva di apprendimento di GraphQL è ripida. Richiede una buona conoscenza del dominio dello sviluppo di API e dell’ingegneria del software in generale. Una persona principiante assoluta avrà difficoltà a capire GraphQL abbastanza bene da costruire un’applicazione complessa.
Al contrario, REST è molto semplice da usare e richiede meno conoscenze di dominio. Le API RESTful sono ben integrate nella maggior parte dei linguaggi di programmazione e dei framework più diffusi, il che rende molto semplice il loro apprendimento.
Riepilogo
GraphQL è una nuova tecnologia che segue le orme dei modelli architettonici delle API RESTful, così come REST è stato introdotto per risolvere i problemi dei modelli API SOAP.
GraphQL offre risposte più rapide, un unico endpoint API per tutte le query e uno schema rigoroso per un accesso coerente ai dati. Questi motivi hanno spinto aziende multimiliardarie a passare a GraphQL, anche in fase iniziale. Tuttavia, nonostante i suoi limiti, il progenitore di GraphQL, REST, continua a mantenere una forte presenza sulla scena.
In questa guida abbiamo analizzato tutto ciò che dovete sapere sulle API GraphQL e RESTful, compresi i vantaggi e gli svantaggi di ciascuna tecnologia, per aiutarvi a decidere con sicurezza quale preferite. Abbiamo anche discusso i problemi noti delle API RESTful – come l’over-fetching, l’under-fetching e gli endpoint multipli – e come GraphQL tenta di risolvere questi problemi e di aumentare le prestazioni della vostra app.
Ora avete abbastanza informazioni per scegliere se GraphQL o REST è adatto al vostro prossimo progetto. Fateci sapere nella sezione commenti cosa costruirete con il vostro vincitore!
I am a Software Engineer and Content Creator who is geared toward building high-performing and innovative products following best practices and industry standards. I also love writing about it at Masteringbackend.com. Follow me on Twitter, LinkedIn, and About Me
Lascia un commento