Mercoledì 23 Giugno dalle 18:00 alle 19:00, durante il prossimo evento di CU SmartShots, parleremo di GraphQl insieme a Stefano Sandrini!
In vista dell‘evento di settimana prossima, scopriamo insieme i suoi vantaggi e le caratteristiche che lo rendono così utile!
Ma cos’è GraphQl?
Nonostante sia un’architettura relativamente nuova, GraphQL sta rapidamente diventando una valida opzione.
GraphQL è un linguaggio di query noto per avere uno schema estremamente tipizzato, e per fornire precisamente agli sviluppatori le informazioni di cui hanno bisogno per la creazione di nuove applicazioni e il trasferimento di dati.
Lo schema GraphQL identifica i parametri di input e le possibili risposte in modo decisamente chiaro, riducendo la confusione e la rielaborazione spesso necessaria con altri modelli API per garantire risultati coerenti.
Lasciamo fare al client!
GraphQL rivoluziona l’approccio REST (o architetture simili) introducendo un concetto piuttosto insolito: difatti, la definizione della struttura dati avviene lato client!
Il server si attiene a questa struttura e restituisce i soli dati effettivamente necessari. Come si vedrà con un esempio più avanti, questo approccio porta notevoli vantaggi in termini di overfetching e underfetching.
Attualmente, l’unica ripercussione negativa si ha in termini di efficacia per quanto riguarda la memorizzazione dei risultati nella cache.
Perché GraphQL?
Come per ogni nuova tecnologia che si propone di rivoluzionare uno standard, ci sono due domande più che lecite:
- perché Facebook ha sentito la necessità di rivoluzionare un sistema consolidato di utilizzo delle API?
- perché, io sviluppatore, dovrei passare a GraphQL?
Dunque, vediamo di rispondere a queste domande.
Overfetching e underfetching
Per rispondere alla prima domanda analizziamo il funzionamento di entrambi gli approcci con un esempio verosimile. Supponete di avere un blog e in una certa pagina avete la necessità di mostrare i titoli di tutti i post di uno specifico utente. Inoltre, volete mostrare il nome degli ultimi 3 follower di quell’utente.
In un ambiente REST i suddetti dati si ottengono accedendo a differenti endpoint; nello specifico, avrete bisogno delle seguenti tre chiamate:
- /user/{id} per ottenere i dati dell’utente
- /user/{id}/posts per recuperare i post di quell’utente
- /user/{id}/followers per recuperare i suoi follower
Ognuna di queste tre chiamate è soggetta a ciò che viene definito overfetching ossia la restituzione di molti più dati di quelli effettivamente necessari.
Infatti, è molto probabile che dell’utente principale vi serva soltanto il nome e quasi sicuramente non avrete bisogno dell’indirizzo o altri dati secondari che la API comunque vi restituisce. Stessa cosa vale per i post, dei quali in tutta probabilità vi servirà solo il titolo e non l’intero corpo o i commenti. E così via.
Con l’utilizzo di GraphQL il tutto si semplifica in un’unica chiamata al server che include solo i dati necessari!
Detto questo potrei anche pensare: visto che la gestione delle API è in mano mia, chi mi impedisce di creare un endpoint specifico che restituisca esattamente i dati di cui ho bisogno? Assolutamente nessuno!
Dunque a questo punto REST e GraphQL si equivalgono? No.
Poniamo il caso che il cliente tra un anno ci chieda una revisione alla UI e voglia mostrare dati diversi da quelli concordati al tempo dell’implementazione del mio endpoint. Incorriamo qui in due rischi:
- overfetching, come abbiamo visto precedentemente, è l’ottenimento di più dati di quelli che effettivamente servono;
- underfetching, è, al contrario, l’ottenimento di meno dati di quelli di cui ho bisogno (caso ben peggiore).
A questo punto, per ogni pagina per cui si è creato un endpoint su misura, sarà necessario andare a controllare, e in tutta probabilità a modificare, il codice dell’API.
In ambiente GraphQL invece (fatta eccezione per quei casi in l’applicazione subisca una ristrutturazione completa, che preveda la nascita di nuove entità e nuove relazioni) non avrò bisogno di intervenire sul server, ma basterà ricostruire lato client la struttura dei dati richiesti e il server sarà pronto a rispondere con la nuova struttura.
Autorizzazione
Inoltre, vorrai poter controllare quali utenti possono vedere e interagire con i vari dati che la tua API GraphQL fornisce:
- L’autorizzazione consiste quindi nello stabilire ciò che un determinato utente ha il permesso di fare o vedere.
Ma quali sono i principali metodi di autorizzazione?
- Autorizzazione a livello di API
– su tipi
– su campi
– su operazioni - Nei resolvers
- Con OpenID Connect e authorization server esterni
Quando sì, quando no
Alla seconda domanda, non c’è una risposta precisa; non c’è nessun obbligo, nessuna raccomandazione e sia REST che GraphQL sono chiaramente due approcci validissimi. Dunque la decisione di adottare l’una o l’altra architettura non dipende dalla qualità, bensì dalle necessità specifiche del progetto che si sta iniziando.
Quando sì: in caso invece di un’applicazione più complessa che preveda frequenti cambiamenti nell’interfaccia o di progetti che prevedono diversi step di upgrade, probabilmente un approccio GraphQL risulterà più semplice e produttivo. Una volta configurato il server e stabilite le interazioni tra gli oggetti, non ci sarà più bisogno di mettere mano al server.
Conclusioni
La versatilità e la semplicità di GraphQL sono indubbie, ma potrà davvero questo nuovo modo di fare API soppiantare il caro vecchio approccio REST?
Oggi abbiamo notato che la scelta dell’uno o dell’altro sistema dipende molto dal caso d’uso del nostro progetto ed è difficile dare a priori una risposta univoca.
Inoltre, adottare una nuova tecnologia rappresenta spesso uno sforzo non banale in termini di tempo e costi e per soppiantare un sistema REST con GraphQL un’azienda si vedrebbe costretta a ristrutturare sistemi già funzionanti nonché, in alcuni casi, chiedere ai propri clienti di adattarsi alla nuova architettura.
Dunque è comprensibile che un tale sistema “rivoluzionario” fatichi ad attecchire globalmente. Vista la giovane età di GraphQL però, è troppo presto per stabilire se con il tempo potrà o meno diventare il nuovo standard. Chissà, forse con qualche ulteriore improvement o con l’aggiunta di qualche feature allettante il team di Facebook riuscirà a convincere il web.
Registrati all’evento se vuoi saperne in modo più approfondito su GraphQL!