GraphQL è un linguaggio di query open-source e un runtime lato server che specifica come i client devono interagire con le application programming interface (API).
GraphQL offre un'alternativa efficiente e flessibile alle API REST (Representational State Transfer) e RESTful, risolvendo alcune delle limitazioni delle API REST. Offre, ad esempio, la possibilità di indirizzare con maggiore precisione le risorse con una singola query.
GraphQL utilizza una sintassi intuitiva che consente ai client di inviare una singola query GraphQL a un'API e di ricevere esattamente i dati necessari (invece di accedere a endpoint complessi con molti parametri). Questo recupero dei dati più efficiente può migliorare le prestazioni del sistema e la facilità d'uso per gli sviluppatori.
Ciò rende GraphQL particolarmente utile per la creazione di API in ambienti complessi, con requisiti front-end in rapida evoluzione. Né le API REST, né le API GraphQL sono intrinsecamente superiori; sono strumenti diversi, adatti a compiti diversi.
All'inizio degli anni 2010, Facebook stava vivendo una crescita e una trasformazione enormi. Ma una base di utenti in crescita e un ambiente di app per dispositivi mobili sempre più complesso hanno reso insostenibile il suo approccio RESTful, che richiedeva più round trip verso diversi endpoint di API per recuperare tutti i dati di query necessari.
Le API REST non erano in grado di gestire interfacce utente complesse e basate sui dati e spesso riscontravano problemi di latenza e inefficienze dei dati, soprattutto per gli utenti mobili con piani dati limitati o costosi.
In risposta a queste problematiche, gli ingegneri di Facebook hanno sviluppato GraphQL (insieme alla piattaforma per applicazioni a pagina singola React), rilasciandolo come soluzione open source nel 2015. Infine, nel 2018 Facebook ha trasferito il servizio alla GraphQL Foundation, che include aziende tra cui AWS, Gatsby, Intuit e IBM.
Le funzionalità dichiarative di recupero dei dati di un'architettura GraphQL si basano su diversi componenti e processi chiave, ognuno dei quali svolge un ruolo unico nella gestione e nell'elaborazione dei dati.
Eccone alcune:
GraphQL si basa su un potente sistema di tipi in cui tutti i tipi di dati vengono registrati nel linguaggio di definizione dello schema GraphQL (SDL). Gli schemi digitati determinano i tipi di dati che possono essere interrogati nell'API e le relazioni tra i tipi e le operazioni disponibili per l'utente.
In altre parole, definiscono le funzionalità dell'API e la forma dei client di dati con cui possono interagire. La configurazione di questo schema determina in ultima analisi il modo in cui l'API può essere utilizzata. Quando arrivano le query, lo schema viene utilizzato per la convalida delle richieste e l'API GraphQL esegue solo le query convalidate.
Ciascun campo in uno schema è supportato da un resolver che popola i dati e determina la risposta a un insieme di campi. I resolver, che possono recuperare dati da un database, un cloud service o pressoché da qualsiasi altra fonte, forniscono istruzioni per trasformare un'operazione GraphQL (ad esempio, una query, una mutazione o un abbonamento) in dati.
Quando un campo di query viene avviato, il sistema genera una chiamata al resolver corrispondente per produrre il valore successivo. Se un campo produce un valore scalare (ad esempio, una stringa o un numero), l'esecuzione viene completata. Se un campo produce un valore oggetto, la query conterrà più campi per quell'oggetto. Questo processo continua finché non rimangono solo campi scalari.
I resolver facilitano anche la formattazione dei dati e aiutano il sistema a unire le informazioni provenienti da varie fonti di dati.
Una query di dati è la richiesta fatta dal client al server GraphQL e specifica quali dati il client desidera recuperare. Le query sono definite nel tipo di query, che è un oggetto speciale nel codice che definisce il punto di ingresso di primo livello per ogni richiesta che i clienti possono eseguire nei confronti del server. Ogni tipo di query definisce anche il nome e il tipo di ritorno per ogni punto di ingresso.
Quando arriva una query, GraphQL la convalida rispetto alle definizioni dello schema e, supponendo che la query sia valida, la esegue. La struttura di una query in genere rispecchia la struttura dei dati di risposta, rendendo i requisiti dei dati espliciti e prevedibili.
Le mutazioni sono operazioni GraphQL che creano, aggiornano o eliminano dati sul server. Sono analoghe alle operazioni POST, PUT, PATCH e DELETE nelle API RESTful. Mentre gli utenti possono accedere ad alcune query senza autenticazione, le mutazioni richiedono sempre l'autenticazione (ad esempio, utilizzando un token API).
Analogamente al modo in cui funzionano le query, le mutazioni GraphQL vengono convalidate rispetto allo schema e alle sue definizioni. Una volta convalidata e avviata la mutazione, il server restituisce una risposta JSON.
Resta al passo con le tendenze più importanti e interessanti del settore relative ad AI, automazione, dati e oltre con la newsletter Think. Leggi l' Informativa sulla privacy IBM.
Sebbene le API GraphQL siano emerse come una valida alternativa, più efficiente e flessibile, REST è stato per lungo tempo lo standard per le architetture API. REST è un'architettura strutturata per applicazioni ipermediali di rete, progettata per utilizzare un protocollo di comunicazione client/server senza stato e memorizzabile nella cache (solitamente HTTP).
La scelta tra GraphQL e REST riguarda principalmente la determinazione dello strumento più adatto per il lavoro da svolgere. Sia GraphQL che REST consentono ai client di comunicare con i server e di richiedere i dati, tuttavia vi sono delle differenze chiave che spiegano la proliferazione dei sistemi GraphQL.
Le API REST sono progettate in base alle risorse (ad esempio, qualsiasi tipo di oggetto, dato o servizio accessibile al client) e funzionano con endpoint (URL) diversi per ciascuna risorsa. Utilizzano una struttura dati fissa per determinare la forma e la dimensione delle risorse che forniscono ai client.
Quando il client richiede una risorsa, il server risponde con un set di dati completo contenente tutti i dati associati a tale risorsa. Se un client necessita solo di un sottoinsieme di dati, riceve comunque tutti i dati (over-fetching); se il client necessita di dati che si estendono su più risorse, spesso dovrà effettuare più chiamate API a causa del recupero inadeguato dei dati dalla richiesta iniziale (under-fetching).
GraphQL, tuttavia, utilizza un singolo endpoint che fornisce una descrizione completa e comprensibile dei dati. Le query GraphQL possono accedere alle proprietà delle risorse e seguire i riferimenti tra le risorse. Ciò consente al client di ottenere tutti i dati di cui necessita da un singolo payload di richiesta API ed evitare problemi di overfetching e underfetching.
In un'architettura RESTful, la modifica della struttura dei dati spesso richiede ai team di eseguire la versione dell'API per evitare errori di sistema e interruzioni del servizio per l'utente.
Ciò significa che gli sviluppatori devono creare un nuovo endpoint ogni volta che modificano la struttura, generando più versioni dell'API e complicando il processo di manutenzione.
GraphQL elimina la necessità del controllo delle versioni perché i client possono specificare i propri requisiti nella query. Se vengono aggiunti nuovi campi al server, i client che non necessitano di tali campi non saranno interessati. Al contrario, se i campi sono obsoleti, i client possono continuare a richiederli fino a quando non aggiornano le loro query.
Le API REST utilizzano codici di stato HTTP per indicare lo stato/successo di una richiesta. Ogni codice di stato ha un significato specifico. Una richiesta riuscita restituisce un codice di stato 200, mentre un errore del client potrebbe restituire un codice di stato 400 e un errore del server potrebbe restituire un codice di stato 500.
GraphQL gestisce gli errori in modo diverso. Ogni richiesta, indipendentemente dal fatto che abbia generato un errore, restituisce un codice di stato 200 OK. Gli errori non vengono comunicati utilizzando i codici di stato HTTP, bensì il sistema comunica gli errori nel corpo della risposta insieme ai dati.
Questo approccio richiede ai client di analizzare il corpo della risposta per determinare se la richiesta è andata a buon fine, il che può rendere il debug delle API GraphQL un po' impegnativo.
REST non dispone del supporto integrato per gli aggiornamenti in tempo reale. Se un'applicazione web o mobile necessita di funzioni in tempo reale con un'API REST, gli sviluppatori devono solitamente implementare tecniche come il long-polling (in cui il client esegue ripetutamente il polling del server per ottenere nuovi dati), gli eventi inviati dal server e i WebSocket, il che può aumentare la complessità dell'applicazione.
GraphQL include tuttavia il supporto integrato per gli aggiornamenti in tempo reale tramite abbonamento. Gli abbonamenti mantengono una connessione stabile al server, consentendo al server di inviare aggiornamenti al client ogni volta che si verificano eventi specifici e permettendo ai client di rimanere aggiornati sui dati API rilevanti.
L'ecosistema REST è ben consolidato con una vasta gamma di strumenti, librerie, framework e tutorial disponibili per gli sviluppatori. Tuttavia, lavorare con le API REST spesso richiede ai team di navigare tra diversi endpoint e di comprendere le convenzioni e i modelli unici di ciascuna API.
GraphQL è relativamente nuovo, ma l'ecosistema GraphQL è cresciuto enormemente dalla sua introduzione, con una varietà di strumenti e librerie disponibili sia per lo sviluppo front-end che back-end.
Strumenti come GraphiQL, Apollo Studio e GraphQL Playground offrono potenti ambienti di sviluppo integrati nel browser (IDE) per esplorare e testare le API GraphQL. Inoltre, GraphQL dispone di un solido supporto per la generazione di codice, che può semplificare lo sviluppo lato client.
Le API REST si basano su meccanismi di memorizzazione nella cache HTTP come ETag e intestazioni dell'ultima modifica. Sebbene efficace, la strategia di memorizzazione nella cache può essere complessa da implementare e potrebbe non ottimizzare in modo coerente le prestazioni per tutti i casi d'uso.
Le API GraphQL possono essere più difficili da memorizzare nella cache a causa della natura dinamica delle query. Tuttavia, l'uso di query persistenti, memorizzazione nella cache delle risposte e memorizzazione nella cache lato server può mitigare queste sfide e fornire strategie di memorizzazione nella cache efficienti per le architetture GraphQL.
Dalla transizione di GraphQL alla GraphQL Foundation, gli sviluppatori hanno creato implementazioni per vari linguaggi di programmazione, tra cui JavaScript, Python, Ruby e PHP. Le API GraphQL sono state adottate da innumerevoli aziende, come Github, Pinterest, PayPal, Shopify, Airbnb e molte altre, consentendo loro di semplificare la specifica dei dati, ridurre la trasmissione eccessiva o inadeguata dei dati di rete e di migliorare le funzionalità di recupero dei dati.1
Inoltre, le aziende e gli sviluppatori stanno spingendo per una federazione aperta delle architetture GraphQL. Nella sua attuale iterazione, la GraphQL federation prende servizi GraphQL separati e li aggrega in un'unica API GraphQL, che funge da punto di immissione per tutti i dati di back-end sottostanti e facilita il recupero dei dati a richiesta singola. Tuttavia, l'implementazione della federazione è l'esclusiva di un singolo fornitore.
In risposta a ciò, i sostenitori di GraphQL chiedono la democratizzazione della federazione, al fine di facilitare l'aggregazione dei dati sia dalle API GraphQL che dalle API non GraphQL, al posto dell'aggregazione esclusiva GraphQL.2
Crea API sicure e flessibili più velocemente con meno codice, unificando i dati per accelerare lo sviluppo e l'innovazione.
Connetti, automatizza e rompi i silos dei dati per sbloccare l'innovazione e la velocità con un'integrazione sicura e unificata.
Aumenta al massimo il valore dell'hybrid cloud nell'era dell'agentic AI. Accelera la trasformazione, modernizza le applicazioni e automatizza l'IT per promuovere l'efficienza, la sostenibilità e un'innovazione più rapida.
1 IBM acquires GraphQL startup StepZen to step up its game in API Management, TechCrunch, 8 febbraio 2023
2 Why GraphQL Needs an Open Federation Approach, The New Stack, 16 novembre 2023