Oggi studiamo... l'API LED architecture

Ciao a tutti!
Questo è il primo articolo che pubblico su questo mio personalissimo sito/blog e non vi nascondo che provo un poco di emozione, non avendo mai fatto frontend per me è stata una bella sfida riuscire a mettere in piedi qualcosa che ritenessi soddisfacente e ritengo il risultato un grande traguardo! 😁

Se doveste sgamare qualche bachetto qui e lì vi prego di informarmi, così da poterci litigare nella speranza di avere la meglio.
Se invece volete solo lasciare un feedback (anche per dirmi che vi fa schifo!) ne sarò più che contento :)

Ma torniamo ora a noi, ho pensato per un bel po' all’argomento del mio primo post ed alla fine ho scartato tante opzioni più tecniche (che restano nel backlog e arriveranno in futuro) decidendo di partire dalla base.

Oggi voglio parlarvi di un tema che è sempre attuale nel nostro mondo: l’architettura della nostra infrastruttura IT!

Ogni professionista che si rispetti che inizia la sua avventura nel mondo MuleSoft deve conoscere i principi dell’architettura API Led (Led verbo eh, non pensate alle lucette!), però in questo post facciamo un breve recap per chi potrebbe essere nuovo e meno in confidenza con questo strumento.

L’architettura API Led è il modello architetturale promosso da MuleSoft che si basa sull’ottimizzazione della nostra rete di microservizi tramite il riutilizzo delle componenti, in parole povere l’obiettivo di questo modello è contenere quello che in gergo viene definito “debito tecnico” (ossia il tempo che ogni team IT deve perdere per manutenere le proprie applicazioni) riutilizzando più possibile ogni singola applicazione che verrà quindi sviluppata cercando di mantenerla quanto più possibile agnostica rispetto allo specifico business flow che stiamo implementando.

“Ma Marco, com’è possibile una cosa del genere? Ci sono delle esigenze che ti costringeranno a creare accoppiamento tra il codice ed i client che usufruiranno delle tue API!”

Corretto!
Ovviamente l'API Led tiene conto di questa necessità e quindi risponde a questa nostra esigenza, aiutiamoci con uno schemino grafico (ringraziamo Unity Group), così da agevolare l’introduzione di un altro concetto cardine dell'API Led: i layer.

• Experience: è il layer che risponde alle necessità di customizzazione di ogni fruitore delle nostre API, si occupano di ricevere e restituire i dati in un formato compatibile con i client che ci richiamano ed allo stesso tempo impachettano i dati in modo che siano utilizzabili dai nostri layer interni. Sono ovviamente le applicazioni meno riutilizzabili e vengono solitamente suddivise in base ai canali che devono fruire dei nostri servizi (mobile, web, crm ecc.).
• Process: è il layer che corrisponde al cuore delle nostre operazioni di business. Queste applicazioni solitamente ricoprono il ruolo di orchestratori dei processi e realizzano il loro scopo parlando con altre process e con le system. Insieme alle system sono applicazioni che vengono riutilizzate quanto più possibile e solitamente le dividiamo in base allo scope dei flussi che orchestrano: prodotti, clienti, blockchain e così via.
• System: è il layer più in basso nella nostra architettura, solitamente anche quello più “stupido”. Sono applicazioni che si interfacciano direttamente con sistemi terzi o sorgenti di dati ed in quanto tali devono rimanere assolutamente agnostiche in modo da essere riutilizzabili al 100%. Sono composte da processi lineari e piatti che non eseguono alcuna forma di logica non strettamente necessaria.

Ora che abbiamo introdotto l'API Led ed i suoi principi facciamo un esempio pratico di come questi potrebbero venirci incontro.
Immaginiamo di lavorare ad un primo progetto con un cliente dove gestiamo la registrazione dei clienti, con i dati che vengono salvati su un CRM ed un DB:

Potremmo approcciare il progetto con un’impronta architetturale simile all’immagine proposta sopra.
Ma cosa accadrebbe se il cliente ci chiedesse in un secondo momento di integrare il tutto con un secondo canale di accesso per il mobile oltre a quello delle web-app? Quale sarebbe l’impatto sulle nostre applicazioni?
Osserviamolo in una seconda immagine:

Le modifiche sarebbero minime, in quanto ci basterà fornire un nuovo punto di ingresso al nostro ecosistema realizzando delle nuove API specifiche per i client mobile.

Se ora provate ad immaginare questa dinamica estesa su di un ecosistema già maturo, e con diversi processi già sviluppati, capirete da soli che il risparmio in termini di manutenzione e tempi di sviluppo è enorme e con questi arriva anche un risparmio economico importante per il cliente che state assistendo.

Una cosa importante che voglio sottolineare è che il principio dei layer è qui per facilitarci il lavoro e non ne dobbiamo diventare mai schiavi!
Se un flusso non ha bisogno di orchestrare alcuna logica possiamo bypassare il layer della Process e far interagire direttamente Experience e System, a meno che non riteniamo che in futuro aver mantenuto una Process nel flusso possa agevolarci in future evoluzioni della nostra infrastruttura.
Allo stesso modo non dobbiamo irrigidirci con la gerarchia Experience > Process > System, una Process può chiamare a sua volta un’altra Process ad esempio.

Prossimamente discuteremo in un articolo incentrato sull'Anypoint Platform dei tool a nostra disposizione per sfruttare ancora meglio l’API Led, con la speranza che vi aiuti a capire maggiormente il valore aggiunto degli Experience APIs che sono solitamente il layer con il quale i novizi hanno più difficolta ad approcciarsi, ritenendolo spesso ed erroneamente superfluo.

Per oggi invece è tutto, grazie mille per aver letto e se avete dubbi, perplessità o non siete d’accordo con quanto scritto sentitevi liberi di mandarmi un messaggio su LinkedIn per discuterne, ritengo il confronto la base della crescita e sono sempre aperto al dibattito!

Alla prossima! 😄