Un micro frontend è un'interfaccia utente composta da applicazioni frontend autonomamente possedute e deployabili. L'approccio è stato formalmente evidenziato da Thoughtworks in 2016e una 2024 il sondaggio ha riferito che 23.6% di rispondenti ha utilizzato micro frontends nell'anno precedente, rispetto a 75.4% in 2022. Dati State of Frontend
Potresti già affrontare il problema. Tre team di prodotto condividono un repository frontend e attendono lo stesso treno di rilascio, anche quando un team sta modificando il checkout, un altro sta aggiornando i profili e il terzo sta aggiustando le pagine di marketing. Un'architettura di micro frontend separa quelle aree di prodotto in modo che i team possano possedere, testare e rilasciare loro indipendentemente mentre gli utenti continuano a esperire un'applicazione unica.
Quella distinzione conta. I micro frontends non sono folder, componenti o bundle più piccoli. Il loro scopo centrale è indipendenza organizzativa e di rilascio, supported by technical boundaries that make ownership explicit. The architecture can remove a coordination bottleneck, but it also introduces runtime integration, dependency governance, testing, security, and performance responsibilities.
Contenuto della Tabella
- Capire il concetto di Micro Frontend
- Come funziona l'architettura di Micro Frontend
- Confronto dei modelli di Micro Frontend fondamentali
- Vantaggi, compromessi e rischi nascosti
- Pratiche di testing, distribuzione e migrazione
- Utilizza Micro Frontends in Capacitor e Electron
- Quando scegliere Micro Frontends
Capire il concetto di Micro Frontend
Da un frontend a più applicazioni possedute
A un frontend tradizionale spesso ci sono un repository, un build e un confine di distribuzione. Anche se il code è diviso in cartelle di feature pulite, le squadre dietro quelle cartelle possono ancora dipendere dallo stesso pipeline e orario di rilascio. Un piccolo cambiamento in un'area può attivare un build completo dell'applicazione, test di regressione condivisi e coordinamento con ogni squadra.
Un frontend micro divide l'applicazione del browser intorno alle capacità commerciali. La squadra del checkout gestisce il checkout, la squadra del profilo gestisce le impostazioni dell'account e la squadra del marketing gestisce il contenuto promozionale. Ogni sezione può avere il proprio codebase, processo di consegna e calendario di rilascio, e diventare parte di un'esperienza più ampia attraverso un guscio o un layer di composizione.
Martin Fowler definisce il pattern come “un stile architettonico in cui applicazioni frontend autonomamente distribuibili sono composte in un insieme più grande” in suo guida fondamentale all'architettura dei frontend micro. La frase “autonomamente distribuibile” ha più peso di “applicazioni frontend.” Senza un confine di distribuzione autonomo, potresti avere un monolite modulare piuttosto che un sistema di frontend micro.
Un analogia di un negozio composto
Immagina un grande magazzino. Un gruppo gestisce la vetrina, un altro gestisce il bancone del negozio e un altro gestisce i rimborsi. Il cliente vede un solo negozio, ma ogni area ha processi, responsabilità e personale diversi. Un micro frontend funziona in modo simile: il browser visualizza un'esperienza di prodotto unica mentre diversi team gestiscono aree di interfaccia distinte dietro le quinte.
L' shell dell'app di solito possiede il frame condiviso, la navigazione, il contesto di autenticazione e le decisioni di rotta. Un micro frontend possiede la pagina o la capacità all'interno di quel frame. I team concordano sui confini tra loro, ma non devono condividere ogni dettaglio di implementazione.
La parola è diventata associata all'estensione del pensiero dei microservizi al browser after Thoughtworks highlighted it in its November 2016 Technology Radar. Fowler later documented its progression from Assess to Trial and then Adopt, which describes the pattern’s movement from an emerging technique toward a more established architectural option. For a broader practical overview of guida all'architettura dei pluginE' utile confrontare il pattern con approcci adiacenti come l'architettura dei plugin, che viene discussa in questo guida all'architettura dei plugin.
La lezione importante è che i micro front end non sono un'upgrade di default per ogni interfaccia. Sono utili quando i confini di squadra e i confini di rilascio creano un vero dolore. Il costo è giustificato solo quando l'indipendenza è degna di essere gestita con più contratti, asset, modalità di fallimento runtime e strumenti operativi.
Come funziona l'architettura dei micro front end
La shell e i suoi frammenti
Un sistema funzionante inizia con una app shellchiamata anche contenitore o orchestratore. La shell rende il layout comune, stabilisce la routing, fornisce il contesto di autenticazione e fornisce elementi di interfaccia condivisi come la navigazione o le notifiche. Decide anche quale micro frontend caricare e dove montare quel frammento.
Ogni frammento è un'applicazione mantenuta indipendentemente. Potrebbe vivere in un repository separato, utilizzare il proprio pipeline CI, pubblicare la propria versione e esporre un bundle, un frammento, un componente web o un modulo remoto. La shell compone quei pezzi nel browser, sia quando la pagina carica sia quando una rotta richiede loro.
Un confine non è utile a meno che le squadre non possano contare su di esso. La shell e ogni frammento hanno bisogno di un contratto esplicito che copra il comportamento di montaggio, la proprietà delle rotte, gli stati di caricamento, il trattamento degli errori, i token di design, le aspettative di accessibilità e le versioni dei dipendenzi supportate.
Regola pratica: Condividere contratti e primitive visive in modo deliberato. Non condividere dettagli di implementazione runtime solo perché due team utilizzano attualmente lo stesso framework.
Comunicazione senza ricreare il monolite
I frammenti hanno bisogno di comunicare. Un frammento di checkout potrebbe dover sapere che un utente si è registrato, mentre un frammento di profilo potrebbe dover pubblicare un evento di aggiornamento dell'account. Le squadre possono utilizzare eventi del browser personalizzati, un archivio condiviso, parametri URL o servizi iniettati.
Ogni opzione crea un profilo di coulping diverso:
- Eventi personalizzati mantenere la proprietà separata, ma le squadre devono documentare i nomi degli eventi, le forme dei payload e i tempi.
- Archivi condivisi semplificano lo stato coordinato, ma possono ricreare la griglia di dipendenza centrale che l'architettura era destinata a ridurre.
- Parametri URL funzionano bene per la navigazione e lo stato condiviso, anche se non sono adatti a ogni interazione.
- Servizi iniettati forniscono capacità controllate, ma la shell deve mantenere i contratti di servizio.
La shell dovrebbe coordinare solo ciò che appartiene all'applicazione intera. Se diventa responsabile dello stato e delle regole di business di ogni frammento, è diventato un monolite distribuito con un processo di distribuzione più complesso.
La progressione storica documentata da Fowler spiega perché il pattern viene spesso paragonato con i microservizi. Entrambi gli approcci separano la proprietà e la consegna, ma i micro front-end applicano quella indipendenza all'interfaccia del browser. Nella tecnologia attuale Utilizzo di Module Federation è diventato prominente, mentre single-spa rimane un'opzione di orchestrazione per i team che desiderano la registrazione dell'applicazione basata sul ciclo di vita.
Per esempio, il team del checkout potrebbe rilasciare una correzione del flusso di pagamento senza ricostruire il frammento del catalogo. Il team del catalogo può continuare con un ritmo di rilascio più lento perché la shell carica ogni slice approvato in base alla sua configurazione di runtime. Quella frontiera di consegna indipendente, non l'aspetto visivo di componenti separati, è il principale vantaggio dell'architettura.
Una squadra che valuta la piattaforma circostante deve anche considerare l'infrastruttura dell'applicazione per i sistemi frontendperché i repository e i framework da soli non forniranno una composizione affidabile.
Confronto dei Pattern dei Micro Frontend
Nessun meccanismo di integrazione singolo risolve ogni problema dei micro front-end. Scegliere in base alla comparazione dell'isolamento, della comunicazione, della condivisione delle dipendenze, del comportamento del browser e della proprietà di gestione operativa piuttosto che selezionare l'utensile più di moda.
| Pattern | Isolamento | Modello di integrazione | Dipendenze condivise | Performance | Best Fit |
|---|---|---|---|---|---|
| Frame | Procedimento forte e isolamento dei documenti | Documento incorporato con messaggistica tra frame | Nessuno di default | Può aggiungere sovraccarico di caricamento e comunicazione | Esperienze non fidate, legacy o fortemente isolate |
| Componenti web | Elemento encapsulato e, ove utilizzato, stile Shadow DOM | Elementi personalizzati montati dal contenitore | Token di design condivisi e API del browser | Spesso prevedibile, ma dipende dal peso del componente | Equipe orientata a standard che richiede flessibilità di framework |
| Module Federation | Isolamento runtime moderato | Moduli remoti caricati e montati in tempo di esecuzione | Dipendenze esplicitamente negoziate o bundle | Efficiente quando caricamento e deduplicazione sono controllati | Applicazioni integrate strettamente con rilasci independenti |
| single-spa | Limite di orchestrazione piuttosto che un modello di isolamento completo | Applicazioni registrate attraverso hook di ciclo di vita | Dipende dalle applicazioni e dalla configurazione radice | Dipende dalle regole di caricamento e dalla composizione del framework | Orchestrazione multi-framework con attivazione basata su route |
Iframes
Un iframe fornisce il confine più forte in questa comparazione. L'applicazione incorporata ha il suo proprio documento, stili e ambiente JavaScript, quindi non muterà accidentalmente il DOM della pagina host. La messaggistica tra finestre può creare un percorso di comunicazione controllato.
Quella isolamento rende gli iframes utili per i sistemi di legacy, le esperienze dei partner o il contenuto che deve rimanere separato. Il costo appare nella gestione della griglia rispondente, della navigazione, dell'accessibilità, della gestione del focus e dell'autenticazione condivisa. Un iframe di checkout può sembrare una superficie straniera se l'applicazione host e l'applicazione incorporata non coordinano con cura.
Componenti web
I componenti web utilizzano gli standard del browser piuttosto che richiedere a ogni team di adottare lo stesso framework. Gli elementi personalizzati definiscono una superficie di montaggio stabile, e il Shadow DOM può limitare la fuoriuscita di stili. Lo shell deve ancora gestire la routing dell'applicazione, gli stati di caricamento, i confini degli errori e i token di design condivisi.
Questa opzione funziona bene quando i team vogliono la flessibilità del framework senza far caricare al browser l'intero runtime dell'applicazione per ogni slice. Non risolve automaticamente la dimensione dei dipendenze, la comunicazione degli stati o la governance. Un elemento personalizzato può ancora contenere un'applicazione grande con la sua propria complessità operativa.
Federazione di Moduli
Module Federation, introdotto con Webpack 5 e supportato da strumenti come Vite e Rspack, carica moduli compilati da entry remote in esecuzione. Offre un'integrazione stretta, che rende i componenti condivisi e la navigazione coordinata più naturali di quanto spesso non siano con i frame di iframe.
Quella comodità crea responsabilità. Le squadre hanno bisogno di interfaccie esposte compatibili, regole per le dipendenze condivise, gestione delle versioni remote e un piano di recupero quando un remoto non può caricare. La differenza tra architettura monolitica e microservizi provides useful context for separating deployment independence from simple code decomposition.
single-spa
single-spa agisce come un orchestratore indipendente dal framework. Le squadre registrano le applicazioni e le hook di ciclo di vita, quindi la configurazione radice attiva le applicazioni in base alle rotte o ad altre condizioni. Può coordinare applicazioni costruite con diversi framework, ma non elimina la necessità di contratti, politiche di dipendenza, budget di prestazioni o controlli di sicurezza.
Le squadre possono combinare questi meccanismi. Ad esempio, la root di single-spa potrebbe coordinare le rotte, Module Federation potrebbe fornire moduli remoti e i componenti web potrebbero definire la superficie di montaggio pubblica. Quella combinazione può essere potente, ma ogni layer aggiunto aumenta il numero di comportamenti che i developer devono comprendere e testare.
Vantaggi Trattative e Rischi Nascosti
I micro front-end spostano le decisioni oltre i confini. Possono ridurre il raggio d'azione di una release e dare ai team più controllo, ma il sistema deve quindi gestire più artefatti, contratti e condizioni di esecuzione.
| Dimensione | Beneficio | Sconto / Rischi nascosti |
|---|---|---|
| Autonomia del team | Teams own a business slice end to end | Gli squadri devono mantenere pipeline separate, proprietà di chiamata in orario e disciplina di rilascio |
| Distribuzione | Un frammento può essere distribuito senza ricostruire l'intera interfaccia | Le release diventano non atomiche, quindi versioni incompatibili possono incontrarsi in produzione |
| Isolamento del fallimento | Un remoto fallito può essere contenuto con un fallback | Poori limiti di errore possono ancora lasciare la navigazione o i viaggi critici inutilizzabili |
| Performance | Caricamento ritardato e pacchetti iniziali più piccoli possono aiutare le flussi comuni | Piu richieste, framework duplicato code, e inizializzazione remota possono danneggiare la prestazione in esecuzione |
| Scegliere la tecnologia | I team possono utilizzare diversi framework dove i limiti lo consentono | Debugging, accessibilità, coerenza di design e reclutamento diventano più difficili in un mix di tecnologie. |
| Sicurezza | Un limite può limitare la condivisione diretta dell'implementazione | La shell può eseguire il code remoto che non ha adeguatamente verificato |
| Governance | I standard condivisi possono preservare un prodotto coerente | Design system, regole di dipendenza, contratti e supporto per piattaforma richiedono una coordinazione continua |
La fattura di prestazioni
Gli slice independenti producono spesso asset costruiti separatamente. Senza regole di caricamento attente, il browser potrebbe richiedere più file, inizializzare più code, o scaricare dipendenze di framework duplicate. La guida per le prestazioni dei micro front-end enfatizza il caricamento a richiesta, la condivisione delle dipendenze attente, il caching a livello di modulo e l'isolamento delle eccezioni.
Un design pratico inizia con un baseline per l'applicazione esistente. Misura l'avvio della rotta, la composizione del pacchetto, il caricamento remoto, l'inizializzazione e le eccezioni visibili dall'utente. Poi stabilisci budget per la shell e per ogni slice ad alta affluenza. Il caricamento lazy aiuta solo se l'applicazione non blocca il viaggio critico su una lunga catena di moduli remoti.
La sicurezza ai margini
Un modulo remoto non è automaticamente sicuro perché ha un repository separato. La shell potrebbe eseguire code che non ha verificato, e un confine di frontend non sostituisce l'autenticazione ai servizi di token o API. Analisi di sicurezza dei micro front-end focalizzata sottolinea l'importanza di dare attenzione al trust, alla firma, ai controlli di integrità e all'autorizzazione prima che i team distribuiscano il runtime code.
La disomogeneità di versione crea un'altra classe di rischi. Un frammento può funzionare da solo ma fallire quando incontra una versione di shell diversa, una libreria condivisa, un set di token di design o un payload di evento. Linee guida di architettura di Nx identifica sfide persistenti in termini di coordinamento, configurazione dell'ambiente, efficienza dell'applicazione e reutilizzo.
L'architettura non cancella la coordinazione. Cambia la coordinazione dai meeting di rilascio nei contratti, nell'automazione, nell'osservabilità e nella governance.
I team hanno anche bisogno di una chiara proprietà per le dipendenze condivise, le revisioni di accessibilità, la risposta agli incidenti e le decisioni di rollback. Se nessuno possiede il layer della piattaforma, ogni team di prodotto risolverà la composizione in modo diverso e gli utenti esperiranno la consistenza risultante come un'applicazione rotta.
Pratiche di testing, di distribuzione e di migrazione
Il testing deve riflettere la modalità in cui l'applicazione funziona. Un frammento che supera i propri test di unità può ancora fallire quando lo shell fornisce una rotta modificata, uno stato di autenticazione inaspettato o una dipendenza condivisa diversa.
Costruisci un sistema di test a strati
Inizia con i test isolati per ogni frammento. Questi test verificano la rendering, le regole di business, il comportamento del tastiera, gli stati di caricamento e l'errore locale senza richiedere la shell completa.
Il testing dei contratti si trova sopra di loro. Verifica l'interfaccia tra la shell e un frammento, compresi gli input di montaggio, i modelli di rotta, gli eventi emessi, le aspettative dei payload, le assunzioni di autenticazione e il comportamento di fallback. I test dei contratti dovrebbero fallire prima della produzione se un team cambia un'interfaccia che un altro team consuma.
Gli test di integrazione della shell caricano quindi gli artefatti di frammento reali in una composizione rappresentativa. Dovrebbero coprire la navigazione, le transizioni di autenticazione, la navigazione condivisa, gli errori di caricamento e le combinazioni di versione. I test end-to-end appartengono in alto perché validano intere tappe come la navigazione di un prodotto, l'accesso e la completazione dell'acquisto attraverso più pezzi consegnati independentemente.
Controlla la superficie di rilascio
Utilizza manifesti versionati affinché la shell possa identificare l'artefatto di frammento esatto che carica. Un manifesto fornisce anche agli operatori un luogo per fissare una versione nota buona quando un rilascio remoto causa errori.
I controlli utili includono:
- Flag di feature: Attiva un nuovo frammento per un pubblico interno o una rotta selezionata prima di una esposizione ampia.
- Distribuzione canaria: Dirigi un pubblico limitato all'artefatto nuovo mentre monitori gli errori del browser, gli errori di caricamento e le azioni commerciali chiave.
- Bundle osservabili: Aggiungi identificatori di rilascio ai log, alle tracce e agli errori del client affinché il team responsabile possa identificare il frammento che fallisce.
- Percorsi di rollback: Conservare l'artefatto compatibile precedente disponibile e rendere la reversione un'azione operativa, non una ricostruzione manuale.
Le squadre dovrebbero testare la shell e il frammento insieme in un ambiente simile alla produzione. Un esito positivo di un run locale non dimostra che un percorso di consegna dei contenuti, un cache, un token di autenticazione o un manifesto remoto si comporterà correttamente per gli utenti. Pratiche di automazione di distribuzione possono supportare flussi di promozione e rollback ripetibili, ma l'architettura ancora richiede una chiara proprietà.
Migrare un dominio alla volta
Una migrazione strangolatrice dirige una capacità dal monolite a un nuovo frammento mentre il resto rimane invariato. Un flag di feature può supportare esecuzioni parallele, consentendo alla squadra di confrontare il nuovo percorso con l'implementazione esistente prima di rendere il nuovo percorso predefinito.
Considerare un'applicazione commerciale con team separati per catalogo, account e checkout. La shell possiede la navigazione e l'autenticazione, il team del catalogo possiede la navigazione dei prodotti, il team degli account possiede le impostazioni del profilo e il team del checkout possiede le flussi di carrello e pagamento. Ogni team pubblica il proprio artefatto, mentre i test di contratto proteggono gli accordi di percorso e evento.
Iniziare con un dominio a basso rischio, pubblicarlo dietro un flag e osservarlo attraverso viaggi reali. Espandere solo dopo che la squadra può distribuire, diagnosticare e annullare quel pezzo senza chiedere all'intera organizzazione di coordinare una rilascio.
Usare Micro Frontends in Capacitor e Electron
A Capacitor o un'applicazione Electron aggiunge un'altra shell intorno alla shell del browser. Capacitor colloca le code web all'interno di un WebView nativo mobile, mentre Electron esegue le code web in un processo di rendering desktop. In entrambi i casi, l'applicazione può caricare una shell locale che recupera gli artefatti frontend selezionati in esecuzione anziché incorporare ogni cambiamento di interfaccia nel binario nativo.
Quell'arrangiamento crea una suddivisione utile di rilascio. Le capacità native, le autorizzazioni e le ponti code restano legate all'applicazione installata, mentre le superfici di proprietà web, come account, aiuto, catalogo o impostazioni, possono seguire un percorso di consegna separato. La shell deve ancora decidere da dove provengono i frammenti, quale versione è approvata e cosa l'applicazione deve fare se un passaggio di fetch o verifica fallisce.
Aggiornamenti in tempo reale e rollback
Un sistema di aggiornamento in tempo reale deve trattare gli artefatti frontend come software rilasciabile. Deve fornire pacchetti firmativerificarli prima dell'attivazione, supportare i canali di rilascio per i rilasci in fase di staging, applicare gli aggiornamenti alla prossima avviatura anziché interrompere una sessione attiva, e fornire una protezione di rollback automatica con reversione atomica.
Quei controlli si mappano naturalmente sulla consegna di frontend micro. Una shell mobile o desktop può fissare un manifesto, recuperare un frammento compatibile, verificare la sua firma e attivarlo solo quando il bundle completo è disponibile. Se il prossimo avvio rileva un errore, l'aggiornatore può ripristinare lo stato noto buono precedente anziché lasciare gli utenti con un'interfaccia parzialmente aggiornata.
Capgo è una delle opzioni per questo modello di consegna. La sua piattaforma di aggiornamento in tempo reale per CapacitorJS e Electron app pubblica pacchetti web firmati, supporta canali mirati, applica aggiornamenti alla prossima avviatura, fornisce log, storia delle versioni, metriche di adozione e fallimento, protezione del rollback, integrazioni CI/CD e un API. how Capacitor connects web and native code.
Cosa cambia in un guscio nativo.
Il wrapper nativo introduce vincoli che un'applicazione browser-only potrebbe non affrontare:
- Connettività: Un frammento può essere inaccessibile quando il dispositivo è offline, quindi il guscio deve avere artefatti cached o un fallback locale.
- Compatibilità: Un pacchetto web può dipendere dal comportamento del ponte nativo che il binario installato non supporta.
- Sicurezza: Il code remoto deve essere autenticato, verificato per l'integrità e autorizzato per il contesto dell'applicazione.
- Recupero: La shell deve rifiutare un bundle non valido e ripristinare una versione funzionante senza richiedere una distribuzione immediata del magazzino.
- La sicurezza della sessione: Aggiornamento durante un flusso di pagamento o form può creare uno stato non coerente, quindi l'attivazione alla prossima esecuzione è più sicura rispetto all'interruzione di un lavoro in corso.
Questo modello rafforza il rollback quando la piattaforma di consegna offre l'attivazione atomica e i metrici di rilascio dettagliati. Complica l'architettura quando gli squadra suppongono che l'indipendenza web elimini la pianificazione di compatibilità nativa. La shell nativa rimane un confine di contratto, e ogni frammento deve rispettarlo.
Quando scegliere micro frontends
Scegliere micro frontends quando è richiesta una reale esigenza di distribuzione indipendenteo quando più squadre possiedono superfici di prodotto separate e chiare, o quando interfacce legacy e nuove devono coesistere durante una lunga migrazione. La diversità tecnologica può anche giustificare il pattern quando gli squadra hanno bisogno di confini di framework che un singolo build non può accogliere in modo pulito.
Evitalo quando un piccolo team può gestire facilmente un frontend unico, quando i domini condividono uno stato mutabile esteso, o quando la tua organizzazione manca di procedure di CI affidabili, di osservabilità, di test di contratto e di rollback. Un'interfaccia distribuita senza quelle fondamenta non crea autonomia. Crea più posti per nascondere gli errori.
Usa un semplice test di partenza:
- La proprietà: Un team può prendere decisioni per la proposta di taglio?
- Boundary: Possono la shell e la slice comunicare attraverso un contratto stabile?
- È necessario rilasciare: La squadra ha bisogno di distribuire indipendentemente?
- Prontezza operativa: È possibile monitorare, testare, bloccare e tornare indietro il frammento?
- Valore utente: La suddivisione migliorerà la consegna senza danneggiare le prestazioni o la consistenza?
Inizia con un'area a basso rischio come il contenuto di aiuto o le impostazioni. Definisci il contratto di montaggio, la proprietà delle rotte, gli eventi, i token di design, il comportamento di fallback e la politica di versione. Invia dietro una bandiera di feature, misura il costo aggiunto del pacchetto e del carico e documenta ogni nuovo canale, manifesto, regola di dipendenza e percorso di rollback.
I micro front-end sono uno strumento per l'indipendenza organizzativa e di rilascio, non un miglioramento automatico della qualità del front-end. Se il problema di rilascio è piccolo, un monolite modulare può essere la risposta migliore. Se il problema di coordinamento è grande e persistente, un'architettura di micro front-end governata con cura può dare alle squadre l'autonomia di cui hanno bisogno.
Se stai valutando i micro front-end per un prodotto Capacitor o Electron Capgo può aiutarti a distribuire pacchetti web firmati attraverso canali controllati, attivare gli aggiornamenti alla prossima avviatura e ripristinare tramite la protezione del rollback. Visita Capgo per esaminare le sue opzioni di consegna, di osservabilità e API prima di progettare il processo di rilascio del tuo frammento.
