Un altro linguaggio, perché? Per un problema di Facebook!
Non si può dire che ci sono pochi linguaggi di programmazione, eppure capita che si sente il bisogno di qualcosa di differente. È quello che è capitato dentro Facebook attorno al 2012.
Dobbiamo ricordarci che il primo iPhone è stato annunciato nel 2007. Quindi si era nel piano boom espansionistico del mondo del mobile. Facebook aveva le sue API basate principalmente su REST ed iniziavano ad esserci problemi dovuti alle specifiche esigenze degli smatrphone e dalla complessità crescente dell’API.
In particolare, il problema principale era legato alla molteplicità di richieste, necessarie per ottenere i dati desiderati. La gestione di queste richieste aumenta il traffico di rete e la complessità della gestione delle risorse.
Per capire meglio il problema fissiamo un’altra data. È nel 2004 che nasce Facebook. Molti si ricorderanno quanti passavano il tempo al PC persi dentro Facebook e degli impiegati sporpresi a mettere i like che nascondevano frettolosamente il browser. Ma se Facebook voleva essere dentro ai nuovi dispositivi e seguire ovunque i suoi utenti doveva fare i conti con la larghezza di banda e le prestazioni della rete, che in quegli anni erano di 56Kbps (GSM) e 114Kbps (GPRS). Si avete letto bene Kbps, i Mega erano un lusso delle reti fisse ed i Giga forse li vedevamo nei film di fantascenza.
Capiamo bene il problema
l’API REST di Facebook forniva una grande quantità di dati e risorse, il che significava che molte richieste includevano dati non necessari all’applicazione mobile di Facebook.
Per capire esattamente il problema faccimo un esempio. Pensiamo di avere un blog dove ci sono utenti, post e iscritti ai post. Per ciascuno abbiamo un’API che ci permettere di leggere e scrivere i dati. Quindi avremo tre API endpoint per interagire con questi elementi.
Il problema è che dobbiamo far interagire gli endpoints. Se vogliamo la lista degli iscritti per un utente, dobbiamo prima chiamare l’endpoint degli utenti per avere l’ID dell’utente. Poi chiamare l’endpoint dei post per avere tutti i post di quell’utente, Ed infine, per ogni post, usare l’endpoint degli iscritti per averer il loro elenco.
Sono tanti passaggi tra il client ed il server. Poi tutto questo porta facilmente ad un overload perché, ad esempio, l’interrogazione dell’endpoint dei post restituisce più dati del solo ID del post che dobbiamo usare nell’endpoint degli iscritti (la data di pubblicazione, l’autore, il titolo, ecc.)
Tutto questo porta a tempi di risposta lunghi e complessità per la gestione dei dati restituiti dalle singole chiamate REST.
Questi problemi hanno portato Facebook a cercare una soluzione migliore per gestire le richieste dell’applicazione mobile, e alla creazione di GraphQL come alternativa all’API REST tradizionale.
La soluzione: GraphQL
In risposta a questo problema, Facebook ha creato una nuova API basata su un linguaggio di interrogazione personalizzato chiamato GraphQL. Il design di GraphQL si concentra sulla descrizione dei dati, piuttosto che sulla descrizione delle risorse, e permette agli sviluppatori di specificare esattamente ciò di cui hanno bisogno, riducendo il traffico di rete e migliorando le prestazioni dell’applicazione.
Con GraphQL, si imposta una query definendo esattamente cosa si vuole. Il runtime si occupa del resto e c’è un solo endpoint, lato server, a cui il client invia le richieste.
Nel 2015, Facebook ha rilasciato pubblicamente GraphQL, rendendolo open source e disponibile a tutti gli sviluppatori. Grazie alla sua flessibilità e alla sua capacità di ridurre il traffico di rete, GraphQL ha rapidamente guadagnato popolarità, diventando una scelta comune per la creazione di API.
Oggi, GraphQL è utilizzato da molte grandi aziende, tra cui GitHub, Airbnb, Shopify e Netflix. GraphQL continua ad evolversi, con il rilascio di nuove funzionalità e l’integrazione con altri strumenti di sviluppo. La sua crescente popolarità dimostra che GraphQL rappresenta un’importante innovazione nel mondo delle API e dell’interrogazione dei dati.
