Architettura Micro Front-end per la Gestione di Servizi Sanitari

Front-end Engineering Solution

contesto

In un’era caratterizzata da una rapida evoluzione digitale che sta rimodellando tutti i settori, incluso quello sanitario, diventa impellente adottare nuove soluzioni flessibili e affidabili. In questo contesto, per un’azienda in ambito healthcare si rende necessario lo sviluppo di una piattaforma digitale innovativa per la gestione di servizi sanitari: una soluzione in grado di integrare funzionalità complesse, tra cui la gestione di pazienti, appuntamenti, disponibilità e pianificazione di risorse mediche (sia personale che spazi), esami e cartelle cliniche.

La realizzazione di tale sistema richiede l’organizzazione del lavoro di diversi team di sviluppo indipendenti, ciascuno responsabile dello sviluppo di moduli specifici. Tale struttura organizzativa, pur necessaria per ottimizzare i tempi di sviluppo, introduce la necessità di gestire le interdipendenze tra i moduli.

Inoltre, i numerosi flussi utente implicano l’interazione tra componenti sviluppati da team differenti. Di conseguenza, il coordinamento della comunicazione a livello tecnico diventa fattore critico per il successo del progetto.

La pianificazione dello sviluppo deve essere parallelizzata tra i diversi moduli, al fine di rispettare le tempistiche complessive del progetto: ciò richiede l’implementazione di strategie per garantire l’autonomia dei team e minimizzare le dipendenze che potrebbero ostacolare lo sviluppo simultaneo.

microfrontend

punti critici

  • Team multipli: La presenza di team specializzati, seppur funzionale, comporta una frammentazione dei processi e delle responsabilità, rendendo difficoltosa la visione d’insieme.
  • Pianificazione e rilasci non sincronizzati: La mancanza di coordinamento tra i team genera ritardi e incongruenze, impattando negativamente sulla tempestività delle implementazioni e sulla coerenza del prodotto finale.
  • Segregazione moduli: La limitata riusabilità del codice e l’ostacolata integrazione delle funzionalità incrementano la complessità dello sviluppo.
  • Funzionalità interdipendenti: La necessità di coordinare le interazioni tra moduli sviluppati da team diversi introduce colli di bottiglia e aumenta il rischio di errori.
  • Tecnologie non uniformi: L’eterogeneità delle tecnologie utilizzate complica la manutenzione e l’aggiornamento della piattaforma, incrementando costi e tempi di sviluppo.

soluzione

Al fine di risolvere le criticità emerse, Bitrock propone un’architettura a Micro front-end (MFE) organizzata nel seguente modo:

  • applicazione “shell”: applicazione principale e orchestratore di altri micro front-end
  • applicazione “remote”: applicazione stand-alone importabile in diversi contesti

 

Il sistema di comunicazione ad eventi è il cuore della sincronizzazione tra gli stati dei componenti MFE (Micro Front-end). Questo “Event Bus” permette la sincronizzazione stato di autenticazione (informazioni utente, token, dati di contesto) e l’invio di messaggi personalizzabili cross componente.

Viene inoltre implementata una gestione messaggi in “replay” tramite una strategia di reactive programming: l’event bus permette di accedere all’ultimo messaggio inviato anche se il componente dovesse essere istanziato successivamente all’invio del messaggio stesso.

L’architettura a MFE permette anche lo sviluppo tecnico verticale e segregato dei moduli: ogni team ha visibilità dei suoi contratti interni (API) e comunica verso l’esterno tramite messaggi con l’event bus.

Tuttavia, la segregazione non vincola il riutilizzo dei componenti da altri team, anzi lo favorisce: per esempio, permettendo ad un solo team di sviluppare un sistema di alerting che possa venire importato e utilizzato in tutta l’applicazione.

Nello specifico, l’applicazione è composta da diversi MFE – anche a più livelli di innesto – contemporaneamente nella stessa vista.

vantaggi

  • Loose-coupling tra i diversi componenti: tecnologie o versioni diverse contemporaneamente
  • Deploy indipendenti con risoluzione dipendenze tra MFE a runtime
  • Comunicazione ad eventi nativa che non crea dipendenze a codice dirette (build time)
  • Segregazione ownership funzionalità: i contratti delle API devono essere noti solamente al team FE di riferimento
  • Composizione di MFE multipli e innestati
tecnologie e competenze adottate

 

  • Webpack module federation
  • Utilizzo diretto di eventi del browser nativi
  • Build tool: vite/webpack/rsbuild
  • React 18 / next
  • Typescript

Vuoi saperne di più in merito ai nostri servizi? Completa il modulo e un nostro consulente ti ricontatterà subito!