Data di pubblicazione: 8 dicembre 2023
Collaboratori: Chrystal R. China, Michael Goodwin
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).
Utilizzando una sintassi intuitiva che consente agli utenti di effettuare richieste API in una singola riga o in poche righe (invece di accedere a endpoint complessi con molti parametri), le tecnologie GraphQL semplificano la generazione e la risposta alle query API. GraphQL rappresenta un aggiornamento dalle tradizionali architetture RESTful.
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 mobili sempre più complesso hanno reso insostenibile il suo attuale approccio RESTful, che richiedeva più round trip verso diversi endpoint per recuperare tutti i dati di query necessari.
Le API REST (Representational State Transfer ) e RESTful 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 e/o costosi.
In risposta a queste sfide, gli ingegneri di Facebook hanno sviluppato GraphQL (insieme alla piattaforma applicativa a pagina singola React), rilasciandolo come soluzione open source nel 2015. Infine, nel 2018 Facebook ha trasferito il servizio alla GraphQL Foundation, che comprende aziende membri come AWS, Gatsby, Intuit e IBM.
Scopri come suddividere i silos di dati scrivendo meno codice con le API GraphQL altamente reattive.
IBM API Connect ottiene i migliori riconoscimenti
Le funzioni dichiarative di recupero dei dati di un'architettura GraphQL ruotano attorno a 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, nonché 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.
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 praticamente da qualsiasi altra fonte, forniscono istruzioni per trasformare un'operazione GraphQL (ad esempio, una query, una mutazione o un abbonamento) in dati.
Quando viene eseguito un campo di query, 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à altri 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; specifica quali dati il client desidera recuperare. 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.
Analogamente al modo in cui funzionano le query, le mutazioni GraphQL vengono convalidate rispetto allo schema e alle sue definizioni. Una volta convalidata e eseguita la mutazione, il server restituisce una risposta JSON.
Sebbene le API GraphQL siano emerse come un'alternativa più efficiente e flessibile, REST e RESTful sono state per lungo tempo lo standard per le architetture API. API REST è uno stile architettonico strutturato per applicazioni ipermediali di rete, progettato per utilizzare un protocollo di comunicazione client-server stateless memorizzabile nella cache (solitamente HTTP).
Sia GraphQL che REST consentono ai client di comunicare con i server e di richiedere i dati, ma vi sono 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 invia 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 di un recupero inadeguato dei dati dalla richiesta iniziale (under-fetching).
GraphQL, invece, 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, in modo che il client possa ottenere tutti i dati di cui ha bisogno da una singola richiesta al server GraphQL ed evitare problemi di over-fetching e under-fetching.
In un'architettura REST, 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 finale. Ciò significa che gli sviluppatori devono creare un nuovo endpoint ogni volta che modificano la struttura, generando più versioni 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 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 clienti di analizzare il corpo di 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 funzionalità 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, che possono aggiungere complessità all'applicazione.
GraphQL, tuttavia, include il supporto integrato per gli aggiornamenti in tempo reale tramite abbonamenti. Gli abbonamenti mantengono una connessione stabile al server, consentendo al server di inviare aggiornamenti al client ogni volta che si verificano eventi specifici e consentendo ai client di rimanere aggiornati sui dati API rilevanti.
L'ecosistema REST è ben consolidato con una vasta gamma di strumenti, librerie e framework disponibili per gli sviluppatori. Tuttavia, lavorare con le API REST spesso richiede ai team di navigare su diversi endpoint e comprendere le convenzioni/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 di servizi 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 ha un forte 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 una varietà di linguaggi di programmazione, tra cui JavaScript, Python, Ruby e PHP, tra gli altri. E le API GraphQL sono state adottate da una miriade di aziende, come Github, Pinterest, PayPal, Shopify, Airbnb e altre1, consentendo a più clienti di semplificare le specifiche dei dati, ridurre la trasmissione eccessiva o inadeguata dei dati di rete e migliorare le funzionalità complessive di recupero dei dati.
Inoltre, le aziende e gli sviluppatori stanno spingendo per una federazione aperta delle architetture GraphQL. Nella sua attuale iterazione, la federazione GraphQL 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 di dati a richiesta singola. Sfortunatamente, però, l'implementazione della federazione è esclusiva di un singolo fornitore.
Come risposta, IBM sta sostenendo la democratizzazione della federazione, che facilita l'aggregazione di dati sia dalle API GraphQL che dalle API non GraphQL invece dell'aggregazione esclusiva GraphQL.numero arabo
IBM API Connect è una soluzione completa di gestione delle API che utilizza un'esperienza intuitiva per consentirti di creare, gestire, proteggere, diffondere e monetizzare le API in modo coerente, contribuendo a potenziare la trasformazione digitale on-premise e nei cloud.
IBM API Connect rende semplice creare e implementare un'API GraphQL a livello di produzione in pochi minuti. È sufficiente fornire i dettagli di connessione della fonte di dati per generare immediatamente un'API GraphQL sicura e ottimizzata.
Scopri i due diversi approcci adottati da questi framework per la creazione di API e i punti di forza e di debolezza di ciascuno.
Leggi il Gartner Magic Quadrant 2023 per API Management per scoprire perché IBM continua a essere riconosciuta come leader nella API Management.
Esplora il toolkit di IBM API Connect.
Massimizza il valore delle API per promuovere il business digitale con una soluzione completa per la gestione delle API.
IBM è stata nominata Leader nel Gartner Report 2023: Critical Capabilities for API Management.
Questi tutorial forniscono istruzioni pratiche che aiutano gli sviluppatori a imparare a utilizzare le tecnologie nei loro progetti.
Note a piè di pagina
1"IBM acquires GraphQL startup StepZen to step up its game in API management" (link esterno a ibm.com), TechCrunch, 8 febbraio 2023
2"Perché GraphQL ha bisogno di un approccio federativo aperto" (link esterno a ibm.com), The New Stack, 16 novembre 2023