Con la digitalizzazione dei processi, il ruolo giocato dal software gestionale nell’economia delle informazioni aziendali è profondamente cambiato. Prima il gestionale era un ambiente a sé stante, slegato o poco interfacciato con gli altri flussi, come una sorta di silos di dati chiuso in sé stesso.
Ora, invece, il software ERP comunica attivamente con gli altri ambiti, alimentando un continuo scambio di dati. A loro volta, le interfacce per mezzo di cui avviene questo scambio hanno subito una continua evoluzione, passando da tecnologie legacy poco scalabili all’utilizzo dei web service, che hanno permesso di gestire basi di dati sempre più complesse salvaguardando le prestazioni del sistema.
L’evoluzione da web service a GraphQL
Negli ultimi anni, proprio grazie a questo continuo ampliamento degli ambiti in cui il software gestionale è coinvolto, le tabelle della sua base dati si sono sempre più ramificate, aumentando sia come numero di entità, sia come dettaglio delle informazioni contenute in ciascuna di esse.
Questa crescente complessità ha avuto ripercussioni sull’architettura del back end che effettua le operazioni CRUD (lettura e scrittura) sulla base dati: gli endpoint di una soluzione web service si sono anch’essi moltiplicati e ramificati, introducendo firme dalla parametrizzazione sempre più complessa e rendendo la manutenzione e l’apprendimento più sfidanti.
La difficoltà di costruire in maniera coerente le chiamate in certi ambiti (si pensi ad esempio la produzione) e i budget sempre maggiori necessari per lo sviluppo di front end basati su web service, hanno spinto alcune software house a cercare un metodo più performante per la creazione di interfacce tra la base dati del gestionale e i software esterni.
La tecnologia GraphQL si rivela perfetta per rispondere a questa esigenza, ossia esporre le informazioni del gestionale per mezzo di un insieme di endpoint facilmente navigabile e organizzato in maniera intuitiva per il fruitore.
Come funzionano le GraphQL
Le GraphQL semplificano la fruizione dei web service esponendo le informazioni con una sintassi più vicina al linguaggio di uso comune.
Prendiamo, per esempio, un web service che effettui l’interrogazione su una distinta base di un sottoprodotto di un ordine di produzione. La sintassi tipica del suo endpoint in un linguaggio C-like potrebbe essere resa come:
/api/getOrdineproduzione/getBOM?id=188897&item=22010&sottoprodotto=1&alternativa=1&returndetail=1
Lato sviluppatore, l’invocazione di questo URL richiede la gestione di parametri che vanno tipicamente popolati per mezzo di valori ricavati dalle logiche del controller o da altre tabelle del gestionale, spesso con la complicazione di dover effettuare anche una manipolazione JSON prima che i valori possano essere resi fruibili dall’endpoint.
Oltre alla complessità del codice, allo sviluppatore è richiesto di possedere anche una conoscenza mnemonica non indifferente della mappa degli endpoint, della loro parametrizzazione, della struttura dati sottostante e delle sue specifiche caratteristiche.
Lo stesso endpoint, invocato per mezzo di una chiamata GraphQL apparirebbe, invece, in questo modo:
OrdineProduzione.Item.SottoProdotto.BOM
Dal confronto tra le due sintassi emerge subito la chiarezza della seconda: la sintassi GraphQL è maggiormente intuitiva, rispecchiando sia l’esperienza umana sia la struttura dati su cui è mappata, di cui è un riflesso immediato. Per questo motivo, l’effort richiesto allo sviluppatore è minore e il codice risultante più pulito e di immediata comprensione anche a collaboratori appena entrati nel team di sviluppo.
Oltre a questa maggiore intuitività nella sintassi, le API GraphQL apportano valore aggiunto anche da un punto di vista tecnico. Il primo beneficio dell’impiego delle GraphQL è un accesso ai dati sempre aggiornato in tempo reale, senza necessità di eseguire long pooling (chiamate ripetute e continuative al server). Il secondo beneficio importante è relativo al controllo versioni. Se alcuni campi delle tabelle sottostanti vengono modificati, un web service REST deve essere aggiornato per rimanere coerente con la struttura dati, pena il rischio di fastidiosi errori nelle chiamate dal front end. GraphQL, invece, scarica il team di sviluppo da questa responsabilità, perché i client possono specificare i propri requisiti di dati nella query, definendo a piacimento il nodo con cui hanno bisogno di comunicare.
Costi e benefici
L’attivazione dei servizi GraphQL sulla propria piattaforma ERP solitamente prevede l’acquisto di una licenza o di un canone aggiuntivo.
L’installazione del servizio è tipicamente semplice: la configurazione si limita alla generazione e all’impostazione di alcuni token per verificare di avere le credenziali autorizzate alla fruizione del nuovo endpoint.
I benefici di questo investimento contenuto sono però notevoli: il passaggio a un ambiente back end di tipo GraphQL abbatte i budget di realizzazione degli sviluppi front end e permette di contenere i costi di manutenzione.
Tipicamente, il nuovo ambiente GraphQL viene anche distribuito con una Sandbox, ossia un ambiente protetto in cui sperimentare con le nuove funzioni senza rischiare di danneggiare nulla sull’ambiente di produzione. La Sandbox permette alle risorse in training di vedere in tempo reale gli effetti del codice che stanno scrivendo, abbattendo drasticamente i tempi di formazione dei nuovi sviluppatori.
