Graphql – Modifica e miglioramento del modo in cui le applicazioni comunicano
Non passerà molto tempo prima che la prossima generazione acquisterà criptovalute e controllerà il saldo della fiducia dell’unità nella lobby di Fortnite tra i giochi. Ciò sarà reso possibile da molti progressi tecnologici.
Quello di cui discutiamo oggi è il modo in cui i dati vengono trasferiti (letti, aggiornati, aggiunti/rimossi) tra le applicazioni e le società che le possiedono. Le API (Application Programming Interface) sono l’architettura che definisce questa comunicazione di dati e, con lo sviluppo di questi standard, i requisiti di elaborazione e di archiviazione dei dati sono diventati meno ardui.
Il leader del pacchetto in termini di utilizzo delle risorse “leggero” è GraphQL, un linguaggio di manipolazione e query di dati open source. Il fondamento del suo ecosistema sono le sue specifiche e una raccolta di strumenti che sono stati creati attorno ad esso.
Non è una novità: il tempo scorre veloce. Facebook lo ha sviluppato nel 2012 e lo ha utilizzato solo internamente per lo sviluppo di applicazioni mobili. Nel 2015 era ‘open source’ e oggi è curato dalla GraphQL Foundation ( https://graphql.org/foundation/ ) che ne cura l’ulteriore sviluppo.
Allora perché ne scrivo ora? Una tipica tabella di marcia verso l’adozione tecnologica seguirà le seguenti acquisizioni 1) hobbisti/progetti personali, 2) implementazione in più lingue, 3) implementazioni tra start-up e piccole aziende, 4) aziende di medie dimensioni e utilizzate nello sviluppo di prodotti, 5 ) grandi aziende e giganti della tecnologia.
GraphQL ha raggiunto il livello 5. Attualmente è utilizzato da GitHub, Pinterest, Shopify, Microsoft per citarne solo alcuni e più recentemente, a partire da marzo 2022, Salesforce.
Alla ricerca di un modo per recuperare i dati in modo più efficiente da Salesforce, mi sono imbattuto nella loro documentazione GraphQL e ho iniziato a leggere e cercare modi per implementarla.
In che cosa differisce da un’API REST tradizionale?
Uno dei principali vantaggi è che con GraphQL è possibile eseguire query e restituire solo quei dati specifici. Se vuoi solo due campi relativi a un incidente con un cliente specifico, allora è quello che ottieni. Un’API REST tradizionale ti restituirebbe TUTTI i campi associati all’incidente. Potrebbero essere più di 100 campi. Ora devi fare qualcosa con tutti quei dati con cui non volevi iniziare. Questo è indicato come il recupero dei dati ( anche il recupero è un problema).
Quanto sopra rende GraphQL più veloce di altre metodologie API durante la restituzione dei dati.
GraphQL è un linguaggio fortemente tipizzato che, tra le altre cose, significa che gli errori di codice vengono rilevati prima dell’esecuzione del programma e non durante esso.
Un ottimo set di strumenti è stato costruito attorno a GraphQL che lo ha reso molto intuitivo per gli sviluppatori.
GraphQL ha un unico endpoint rispetto all’API REST che ha più endpoint. Ciò significa che tutti i tuoi dati possono essere recuperati in un’unica richiesta.
Due facce della medaglia: richiedente (client) e provider (host GraphQL)
Ho esaminato GraphQL finora dal punto di vista della “richiesta” di dati. Laddove un’azienda come Salesforce o Microsoft ha impostato un’API GraphQL che è possibile utilizzare per eseguire query e manipolare i dati (leggere, aggiornare, aggiungere).
Ad esempio, se volessimo includere i dati degli incidenti client relativi a Salesforce in un portale client, il modo più efficiente per farlo sarebbe richiedere i dati esatti che stiamo cercando tramite una query GraphQL dal portale al server GraphQL di Salesforce. Otterrai esattamente i dati che desideri, nessun recupero inferiore o eccessivo e, di conseguenza, non sarà richiesta alcuna elaborazione aggiuntiva o archiviazione dei dati.
L’altro lato della medaglia è l’organizzazione che imposta l’architettura GraphQL in modo che anche i tuoi clienti possano avere un metodo efficiente per accedere ai dati che desiderano.
Nella creazione dell’API GraphQL un’organizzazione sta creando un modello che integra tutti i propri sistemi in un unico modello. Unifica questi sistemi e, una volta terminato, rimuove la complessità del sistema sottostante. Una volta completato il lavoro, l’interrogazione dei dati diventa semplice tramite l’API.
Quando si confrontano applicazioni o provider, guardo quali funzioni mi offrono per recuperare i miei dati da loro. Non voglio doverli inviare via e-mail o fare affidamento su rigidi report predefiniti. Voglio essere in grado di “collegare” i miei dati interrogandoli in modo flessibile e tempestivo. Se si tratta di due applicazioni/fornitori e sono abbinati in modo simile su altri punti di confronto e uno offre un’API REST o un’API GraphQL, sceglierò sicuramente quella con l’API.
Marcus Loveland da Unite.ai
