GraphQL – Cambiando e Migliorando il Modo in cui le Applicazioni Comunicano

Non passerà molto tempo prima che la prossima generazione acquisti criptovalute e controlli il saldo del trust unitario nel lobby di Fortnite tra una partita e l’altra. Ciò sarà reso possibile grazie a numerosi progressi tecnologici.

Quello di cui parleremo oggi è il modo in cui i dati vengono trasferiti (letti, aggiornati, aggiunti/rimossi) tra le applicazioni e le aziende che le possiedono. Le interfacce di programmazione delle applicazioni (API) sono l’architettura che definisce questa comunicazione dei dati e, poiché questi standard si sono evoluti, i requisiti di elaborazione e archiviazione dei dati sono diventati meno gravosi.

Il leader del gruppo in termini di “utilizzo di risorse leggero” è GraphQL, un linguaggio di query e manipolazione dei dati open-source. La fondazione del suo ecosistema è la sua specifica e una raccolta di strumenti creati intorno ad esso.

Non è nuovo – il tempo passa velocemente. Facebook lo ha sviluppato nel 2012 e lo ha utilizzato solo internamente per lo sviluppo di applicazioni mobili. Nel 2015 è stato “open source” e oggi è gestito dalla GraphQL Foundation (https://graphql.org/foundation/) che sovrintende al suo ulteriore sviluppo.

Perché sto scrivendo di questo adesso? Una roadmap tipica per l’adozione di una tecnologia seguirà le seguenti fasi di adozione: 1) hobbisti/progetti personali, 2) implementazione su più linguaggi, 3) implementazioni su start-up e piccole aziende, 4) aziende di medie dimensioni e utilizzo nello sviluppo di prodotti, 5) grandi aziende e giganti della tecnologia.

GraphQL ha raggiunto il livello 5. Attualmente viene utilizzato da GitHub, Pinterest, Shopify, Microsoft, per citarne solo alcuni, e più recentemente, dal marzo 2022, da Salesforce.

Cercando un modo per recuperare i dati in modo più efficiente da Salesforce, ho trovato la loro documentazione GraphQL e ho iniziato a leggere e a cercare modi per implementarlo.

Come si differenzia da un’API REST tradizionale?

• Uno dei principali vantaggi è che con GraphQL puoi eseguire query e ottenere solo i dati specifici richiesti. Se vuoi solo due campi relativi a un incidente del cliente, è quello che ottieni. Un’API REST tradizionale ti restituirebbe tutti i campi associati all’incidente. Potrebbero essere 100 o più campi. Ora devi fare qualcosa con tutti quei dati che non volevi inizialmente. Ciò è noto come data over fetching (anche il under fetching è un problema).
• Il fatto sopra menzionato rende GraphQL più veloce di altre metodologie API quando si restituiscono dati.
• GraphQL è un linguaggio fortemente tipizzato, il che significa, tra le altre cose, che gli errori di codice vengono rilevati prima che il programma venga eseguito e non durante l’esecuzione.
• Un ottimo set di strumenti è stato costruito intorno a GraphQL, il che lo ha reso molto amichevole per gli sviluppatori.
• GraphQL ha un unico endpoint, a differenza dell’API REST che ha più endpoint. Ciò significa che tutti i tuoi dati possono essere recuperati in una singola richiesta.

I due lati della medaglia: richiedente (client) e fornitore (host GraphQL)

Ho esaminato GraphQL finora dalla prospettiva della “richiesta” di dati. Dove un’azienda come Salesforce o Microsoft ha configurato un’API GraphQL che puoi utilizzare per eseguire query e manipolare dati (leggere, aggiornare, aggiungere).

Ad esempio, se volessimo includere dati da Salesforce relativi a incidenti del cliente in un portale del cliente, il modo più efficiente per farlo sarebbe richiedere i dati esatti che stiamo cercando attraverso una query GraphQL dal portale al server GraphQL di Salesforce. Otterrai esattamente i dati che vuoi, senza sotto-né sovrarecuperare dati, e di conseguenza non saranno necessari ulteriori elaborazioni o archiviazioni dei dati.

L’altro lato della medaglia è l’organizzazione che configura l’architettura GraphQL in modo che i clienti possano avere un metodo efficiente per accedere ai dati che desiderano.

Nel costruire l’API GraphQL, un’organizzazione crea un modello che integra tutti i suoi sistemi in un unico modello. Unifica questi sistemi e, una volta completato il lavoro, la query dei dati diventa senza problemi attraverso l’API.

Quando confronto applicazioni o fornitori, guardo cosa offrono per farmi recuperare i miei dati. Non voglio doverli contattare via e-mail o affidarmi a rapporti predefiniti rigidi. Voglio poter “collegarmi” ai miei dati, interrogandoli in modo flessibile e tempestivo. Se si tratta di due applicazioni/fornitori che sono simili in altri punti di confronto e uno offre un’API REST o un’API GraphQL, sceglierò sicuramente quello con l’API.