Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Confronto tra micro-frontend e architetture alternative

Come per tutte le strategie architettoniche, la decisione di adottare i microfrontend deve basarsi su criteri di valutazione guidati dai principi dell'organizzazione. I micro-frontend presentano vantaggi e svantaggi. Se l'organizzazione decide di utilizzare i micro-frontend, è necessario disporre di strategie per affrontare le sfide dei sistemi distribuiti

Quando si sceglie un'architettura applicativa, le alternative più popolari ai microfrontend sono i monoliti, le applicazioni n-tier e i microservizi in combinazione con un frontend applicativo a pagina singola (SPA). Questi sono tutti approcci validi e ognuno di essi presenta vantaggi e svantaggi.

Monoliti

Una piccola applicazione che non richiede modifiche frequenti può essere fornita molto rapidamente come monolite. Anche in situazioni in cui è prevista una crescita significativa, un monolite è un primo passo naturale. Successivamente, il monolite può essere ritirato o rifattorizzato in una struttura più flessibile. Partendo da un monolite, l'organizzazione può andare sul mercato, ottenere il feedback dei clienti e migliorare il prodotto più rapidamente.

Tuttavia, le applicazioni monolitiche tendono a degradarsi se non vengono mantenute con cura o se la codebase cresce di dimensioni nel tempo. Quando più team contribuiscono in modo significativo alla stessa base di codice, raramente tutti contribuiscono alla sua manutenzione e alle sue operazioni. Ciò si traduce in uno squilibrio delle responsabilità, che influisce sulla velocità e causa inefficienze. Allo stesso tempo, l'accoppiamento involontario tra i moduli di un monolite porta a effetti collaterali indesiderati man mano che il codice base si evolve. Questi effetti collaterali possono causare malfunzionamenti e interruzioni.

Applicazioni di livello N

Un'applicazione più complessa con un ritmo di evoluzione relativamente statico può essere costruita come un'architettura a tre livelli (presentazione, applicazione, dati), con un livello REST o GraphQL tra il frontend e il backend. Questa soluzione è molto più flessibile e i team dei diversi livelli possono svilupparsi in modo indipendente in una certa misura. Lo svantaggio di un'applicazione di livello n è che è molto più difficile implementare le funzionalità. Il frontend e il backend sono disaccoppiati tramite un contratto API, quindi le modifiche più importanti devono essere implementate insieme o l'API deve essere versionata.

Considerate il seguente scenario comune: se il rilascio di una nuova funzionalità richiede una modifica dello schema dei dati, i proprietari dei prodotti potrebbero impiegare giorni per concordare una serie di funzionalità con un team di frontend. Quindi il team di frontend chiederà al team di backend di sviluppare e rilasciare la funzionalità da parte sua. Il team di backend collaborerà con i proprietari dei dati per rilasciare un aggiornamento dello schema del database. Successivamente, il team di backend rilascerà una nuova versione dell'API, in modo che il team di frontend possa sviluppare e rilasciare le modifiche. In questo scenario, la propagazione di tutte le modifiche alla produzione potrebbe richiedere settimane o addirittura mesi, poiché ogni team ha il proprio backlog, le proprie priorità e i propri meccanismi per lo sviluppo, il test e il rilascio delle modifiche.

Micro-servizi

In un'architettura di microservizi, il backend è scomposto in piccoli servizi, ognuno dei quali si occupa di una particolare problematica aziendale all'interno di un contesto limitato. Ogni microservizio è inoltre fortemente disaccoppiato dagli altri servizi in quanto presenta un contratto di interfaccia chiaramente definito.

Vale la pena ricordare che i contesti limitati e i contratti di interfaccia dovrebbero esistere anche in monoliti e architetture n-tier ben realizzati. In un'architettura a microservizi, tuttavia, la comunicazione avviene tramite la rete, in genere il protocollo HTTP, e i servizi dispongono di un'infrastruttura di runtime dedicata. Ciò supporta lo sviluppo, la distribuzione e il funzionamento indipendenti di ogni servizio di backend.

Scelta dell'approccio adatto alle proprie esigenze

I monoliti e le architetture n-tier raggruppano più aspetti di dominio in un unico artefatto tecnico. Ciò semplifica la gestione di aspetti quali le dipendenze e il flusso di dati interno, ma rende più difficile l'implementazione di nuove funzionalità. Per mantenere una base di codice coerente, un team spesso investe tempo nel refactoring e nel disaccoppiamento a causa della grande base di codice che deve gestire.

Le applicazioni sviluppate da alcuni team potrebbero non richiedere la complessità aggiuntiva derivante dal passaggio ai microfrontend. Ciò è particolarmente vero se le squadre non pagano le penalità dovute all'elevato numero di accoppiamenti e ai lunghi tempi di attesa per rilasciare le modifiche.

In sintesi, le architetture più complesse e distribuite sono spesso la scelta giusta per applicazioni complesse e in rapida evoluzione. Per le applicazioni di piccole e medie dimensioni, un'architettura distribuita non è necessariamente superiore a un'architettura monolitica, soprattutto se l'applicazione non si evolverà drasticamente in un breve periodo di tempo.