Introduzione

Microservizi è uno stile architettonico in rapida diffusione nello sviluppo di software e ne abbiamo già parlato qui. Ora è il momento di fare un ulteriore passo avanti con questo approccio e vedere come il microservizio può essere adattato al frontend nella creazione del cosiddetto micro-frontend. Lo schema qui è lo stesso e consiste nella scomposizione di frontend monolitici in parti più piccole e più semplici che possono essere sviluppate, testate e distribuite in modo indipendente, pur continuando ad apparire agli utenti come un unico frontend coeso.

Ecco alcuni dei motivi per cui abbiamo deciso di passare ai micro-frontend.

1) Il frontend monolite è troppo complesso

Col passare del tempo il frontend su cui stavamo lavorando era cresciuto immensamente. Avevamo a che fare con un frontend monolitico difficile da scalare dal punto di vista dello sviluppo. Ci siamo resi conto che le applicazioni di grandi dimensioni create utilizzando architetture monolitiche hanno molte dipendenze e il coordinamento è diventato sempre più difficile e richiedendo sempre più tempo.

2) Bisogno di divisione

Il codice di ogni micro-frontend è per definizione molto più piccolo del codice sorgente di un singolo frontend monolitico. Queste basi di codice più piccole sono più semplici e facili da gestire per gli sviluppatori.

3) Organizzazione del team

Poiché abbiamo più frontend che lavorano nello stesso team, abbiamo bisogno che ognuno sia esperto in una singola parte del progetto per evitare la dispersione. Il micro-frontend offre la possibilità di compartimentalizzare il lavoro, quindi una maggiore efficienza.

4) Onboarding più rapido

Una codebase monolitica è complicata e l'onboarding di un nuovo sviluppatore richiede più tempo del previsto perché ci sono troppe cose da imparare tutte insieme. Il micro-frontend consente di dividere la big picture in frame più piccoli e di facile comprensione, quindi è sufficiente imparare un pezzo per volta diventando immediatamente produttivi.

5) Sviluppo indipendente

Questo è di gran lunga il vantaggio più grande che abbiamo tratto, infatti poiché ogni applicazione di micro-frontend è indipendente, la modifica di una parte non influirà sulle altre parti (purché siano separate). Il mio team può avere persone che lavorano in parallelo senza la necessità di essere coordinate.

6) Deployment indipendenti

Durante l'aggiornamento di un'applicazione Web monolitica, è necessario aggiornare tutto. Non è possibile aggiornare solo un pezzo mantenendo il resto, perché causerebbe problemi, quindi il coordinamento è obbligatorio. Invece, con i micro-frontend, i team possono eseguire il deployment ognuno con le proprie velocità senza attendere che le dipendenze esterne vengano risolte prima dell'implementazione in produzione. Questo concetto vale anche per i test.

7) A prova di obsolescenza

Un altro motivo per cui scegliamo questo approccio è la natura mutevole dello sviluppo frontend. Ammettiamo che un nuovo framework prenda il sopravvento e iniziamo a usarlo. L'architettura dei micro-frontend consente il test e l'integrazione di nuovi framework in modo che i team siano liberi di scegliere la loro tecnologia preferita.

8) Scegliere il linguaggio preferito

Con i micro-frontend, ogni pacchetto può essere scritto in un linguaggio diverso (Angular, React, Vue, Svelte, ecc.). Ciò consente ai team di essere agnostici durante lo sviluppo poiché possono scegliere quello che preferiscono.

Conclusioni

I micro-frontend consentono ai team di sviluppare in modo indipendente, deployare rapidamente e testare individualmente. Potrai usare continuous integration, continuous deployment, e continuous delivery. Ti consigliamo vivamente di approfondire il microfrontend poiché può essere la soluzione migliore per il tuo progetto. Nel prossimo articolo tratterò perché e come utilizziamo Module Federation per ottenere micro-frontend.