Un Micro Frontend è un'interfaccia utente composta da applicazioni frontend autonomamente possedute e deployabili. L'approccio è stato formalmente evidenziato da Thoughtworks in 2016, e un 2024 Una ricerca ha riferito che 23.6% dei rispondenti avevano utilizzato micro front-end nel corso dell'anno precedente, rispetto a 75.4% in 2022. lo stato del frontend
Potresti già affrontare questo problema. Tre team di prodotto condividono un repository frontend e attendono lo stesso train 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. Una architettura a micro front-end 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 front-end non sono semplicemente cartelle, componenti o bundle più piccoli. Il loro scopo centrale è l'indipendenza organizzativa e di rilasciosupportata da confini tecnici che rendono l'ownership esplicito. L'architettura può eliminare un punto di bottiglia di coordinamento, ma introduce anche responsabilità di integrazione in esecuzione, governance delle dipendenze, testing, sicurezza e prestazioni.
Tavola dei contenuti
- Capire il concetto di Micro Frontend
- Come funziona l'architettura del Micro Frontend
- Confronto dei modelli di Micro Frontend fondamentali
- Vantaggi, compromessi e rischi nascosti
- Pratiche di testing, distribuzione e migrazione
- Utilizzare Micro Frontend in Capacitor e Electron
- Quando scegliere Micro Frontend
Capire il concetto di Micro Frontend
Da un frontend a più applicazioni gestite
Un frontend tradizionale spesso ha un unico repository, un unico build e un unico confine di distribuzione. Anche se il code è diviso in cartelle di feature pulite, i team dietro quelle cartelle possono ancora dipendere dalla stessa pipeline e dallo stesso orario di rilascio. Un piccolo cambiamento in un'area può attivare un build completo dell'applicazione, test di regressione condivisi e coordinamento con ogni team.
Un micro frontend divide l'applicazione del browser intorno alle capacità commercialiLa squadra di checkout gestisce il checkout, la squadra del profilo gestisce le impostazioni dell'account e la squadra di marketing gestisce il contenuto promozionale. Ogni sezione può avere il proprio codice sorgente, processo di consegna e calendario di rilascio, e poi diventare parte di un'esperienza più ampia attraverso uno strato o un layer di composizione.
Martin Fowler definisce il pattern come “un stile architettonico in cui applicazioni frontend autonomamente eseguibili sono composte in un tutto più grande” in suo guida fondamentale micro frontends architecture. La frase “autonomamente eseguibile” ha più peso della “applicazioni frontend”. Senza un confine di distribuzione autonomo, potresti avere un monolite modulare piuttosto che un sistema di micro frontend.
Un analogia di un negozio di abbigliamento
Pensa a un grande negozio di abbigliamento. Una squadra gestisce il negozio principale, un'altra gestisce il bancone del checkout e un'altra gestisce i ritorni. Lo shopper 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 diverse squadre operano aree di interfaccia distinte dietro le quinte.
L'app shell di solito gestisce il frame condiviso, la navigazione, il contesto di autenticazione e le decisioni di route. Un micro frontend gestisce la pagina o la capacità all'interno di quel frame. Le squadre concordano sui confini tra loro, ma non devono condividere ogni dettaglio di implementazione.
La locuzione è diventata associata all'estensione pensiero ai microservizi al browser dopo che Thoughtworks l'ha evidenziata nel suo Rapporto tecnologico di novembre 2016. Fowler ha documentato successivamente la sua evoluzione da Assess a Trial e poi Adottare, che descrive il movimento del modello da una tecnica emergente a un'opzione architettonica più stabilita. Per una panoramica più ampia e pratica della sviluppo web scalabile da Nerdify, aiuta a confrontare il modello 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. Hanno senso quando i confini di squadra e i confini di rilascio creano un vero dolore. Il costo è giustificato solo quando quella 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 conchiglia e i suoi frammenti
Un sistema funzionante inizia con una conchiglia dell'appanche chiamata contenitore o orchestratore. La conchiglia 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 front-end caricare e dove quel frammento dovrebbe montare.
Ogni frammento è un'applicazione mantenuta indipendentemente. Potrebbe vivere in un repository separato, utilizzare la propria 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, ad esempio quando la pagina carica o 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 squadre utilizzano attualmente lo stesso framework.
Comunicazione senza ricreare il monolite
I frammenti a volte hanno bisogno di comunicare. Un frammento di checkout potrebbe avere bisogno di sapere che un utente si è registrato, mentre un frammento di profilo potrebbe avere bisogno di pubblicare un evento account-updated. Le squadre possono utilizzare eventi del browser personalizzati, una store condivisa, parametri URL o servizi iniettati.
Ogni opzione crea un profilo di coulping diverso:
- Eventi personalizzati mantengono la proprietà separata, ma le squadre devono documentare i nomi degli eventi, le forme dei payload e il timing.
- Store condivisi semplificano lo stato coordinato, ma possono ricreare la griglia di dipendenze centrali che l'architettura era destinata a ridurre.
- Parametri della 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 quei 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, è diventata un monolite distribuito con un processo di distribuzione più complesso.
La documentazione storica di 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. Nelle attuali tecnologie Utilizzo di Module Federation E' diventato prominente, mentre single-spa rimane un'opzione di orchestrazione per le squadre 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.
E' necessario considerare anche L'infrastruttura dell'applicazione per i sistemi frontendperché i repository e i framework da soli non forniscono una composizione affidabile.
Confrontare i modelli di base di Micro Frontend
Non esiste un meccanismo di integrazione unico che risolva ogni problema di micro frontend. 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.
| Modello | Isolamento | context: Pagina/Area: Capgo Builder / prodotto di pagina nativa di costruzione cloud. Ruolo: Etichetta UI breve o elemento di navigazione. Visualizzato in: pagina native-build.astro. Chiave di messaggio `native_build_v2_trust_iso_lbl` (Native Build V2 Trust Iso Lbl). | Modello di integrazione | Dipendenze condivise | Performance |
|---|---|---|---|---|---|
| context: Pagina/Area: Sezione di problema/soluzione homepage. Ruolo: Intestazione di sezione o pagina. Visualizzato in: pagina premium-support.astro. Chiave di messaggio `ps_help_performance_title` (Ps Help Performance Title). | Scelta migliore | Iframe | Procedura forte e isolamento dei documenti con documentazione | Può aggiungere sovrapposizione di caricamento e comunicazione | Esperienze non fidate, legacy o fortemente isolate |
| Componenti web | Elemento encapsulato e, ove utilizzato, stili Shadow DOM | Elementi personalizzati montati dal contenitore | Token di design condivisi e API del browser | Spesso predittivi, ma dipendono dal peso del componente | Team orientati alle norme che richiedono flessibilità del framework |
| Module Federation | Isolamento di runtime moderato | Moduli remoti caricati e montati in esecuzione | Dipendenze esplicitamente negoziate o bundle | Efficace quando il caricamento e la deduplicazione sono controllati | Applicazioni integrate strettamente con rilasci independenti |
| single-spa | Modello di confine 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 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, esperienze di partner o contenuti che devono rimanere separati. 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
Le componenti web utilizzano gli standard del browser anziché richiedere a ogni squadra di adottare lo stesso framework. Gli elementi personalizzati definiscono una superficie di montaggio stabile, e il Shadow DOM può limitare la fuoriuscita di stili. La shell deve ancora gestire la routing dell'applicazione, gli stati di caricamento, i limiti degli errori e i token di design condivisi.
Questa opzione funziona bene quando le squadre desiderano la flessibilità del framework senza far caricare al browser l'intero runtime dell'applicazione per ogni sezione. Ciò non risolve automaticamente la dimensione delle dipendenze, la comunicazione degli stati o la governance. Un elemento personalizzato può ancora contenere un grande applicazione con la sua propria complessità operativa.
Module Federation
Module Federation, introdotto con Webpack 5 e supportato da strumenti come Vite e Rspack, carica i moduli compilati da entry remoti in esecuzione. Offre un'integrazione stretta, che rende i componenti condivisi e la navigazione coordinata più naturali di quanto spesso non siano con gli 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 fornisce un contesto utile per separare l'indipendenza di distribuzione dalla semplice decomposizione code.
single-spa
single-spa funge da orchestratore indipendente dalle tecnologie. Le squadre registrano le applicazioni e le funzioni di ciclo di vita, quindi la configurazione radice attiva le applicazioni in base alle rotte o ad altre condizioni. Può coordinare applicazioni costruite con diverse tecnologie, 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, una root single-spa potrebbe coordinare le rotte, la 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 Contrappesi e Rischi Nascosti
Micro frontends spostano le decisioni oltre i confini. Possono ridurre il raggio d'azione di una release e dare alle squadre più controllo, ma il sistema deve quindi gestire più artefatti, contratti e condizioni di esecuzione.
| Dimensione | Beneficio | Contrappeso / Rischio Nascosto |
|---|---|---|
| Autonomia della squadra | Le squadre possiedono una porzione di business da capo a fondo | Le squadre devono mantenere pipeline separate, proprietà di chiamata in caso di emergenza e disciplina di rilascio |
| Deploy | Un frammento può essere distribuito senza ricostruire l'intera interfaccia | Le rilasci diventano non atomici, quindi le versioni incompatibili possono incontrarsi in produzione |
| Isolamento del fallimento | Un remoto fallito può essere contenuto con un fallback | Ilimitatezza dei confini di errore può lasciare inutilizzabili la navigazione o i viaggi critici |
| Performance | context: Pagina/Area: Sezione problema/soluzione. Ruolo: Intestazione di sezione o pagina. Visualizzato in: pagina premium-support.astro. Chiave di messaggio `ps_help_performance_title` (Ps Aiuto Performance Titolo). | More requests, duplicated framework code, and remote initialization can hurt runtime performance |
| Piu richieste, framework duplicato __CAPGO_KEEP_0__, e inizializzazione remota possono danneggiare la prestazione in esecuzione | Scegliere la tecnologia | I team possono utilizzare diversi framework dove i confini lo permettono |
| Debugging, accessibilità, coerenza di design e reclutamento diventano più difficili in una pila mista | Sicurezza | La shell potrebbe eseguire remoto code che non ha verificato adeguatamente |
| Governance | I standard condivisi possono preservare un prodotto coerente | I sistemi di design, le regole di dipendenza, i contratti e il supporto della piattaforma richiedono una coordinazione continua |
Il conto della prestazione
Le sezioni independenti producono solitamente 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 sulla prestazione per i micro front-end enfatizza il caricamento a richiesta, la condivisione delle dipendenze attente, il caching a livello di modulo e l'isolamento degli errori.
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 gli errori visibili dall'utente. Poi stabilisci budget per la shell e per ogni sezione di alta affluenza. Il caricamento a richiesta aiuta solo se l'applicazione non blocca il viaggio critico in 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'autorizzazione alle API o ai servizi di token. Analisi di sicurezza focalizzata sui micro front-end sottolinea perché la fiducia, la firma, i controlli di integrità e l'autorizzazione richiedono attenzione al design prima che i team distribuiscano code di esecuzione in tempo di esecuzione.
La disallineamento delle versioni crea un'altra classe di rischi. Una frazione potrebbe funzionare da sola ma fallire quando incontra una versione di shell diversa, una libreria condivisa, un set di token di design o un payload di evento. Nx’s architetture di guida identifica la coordinazione, la configurazione dell'ambiente, l'efficienza dell'applicazione e la riutilizzabilità come sfide che continuano.
La architettura non cancella la coordinazione. Cambia la coordinazione dai meeting di rilascio nei contratti, nell'automazione, nell'osservabilità e nella governance.
Gli squadre hanno anche bisogno di una chiara proprietà per le dipendenze condivise, le recensioni di accessibilità, la risposta agli incidenti e le decisioni di rollback. Se nessuno possiede il layer di piattaforma, ogni squadra di prodotto risolverà la composizione in modo diverso, e gli utenti esperiranno la consistenza risultante come un'applicazione rotta.
Pratiche di Test, Distribuzione e 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 test dei contratti si trova sopra di loro. Verificano 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 ipotesi di autenticazione e il comportamento di fallback. I test dei contratti dovrebbero fallire prima della produzione se una squadra cambia un'interfaccia che un'altra squadra consuma.
Gli test di integrazione del shell caricano quindi gli artefatti di frammento reali in una composizione rappresentativa. Dovrebbero coprire la routing, 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 interi viaggi come la navigazione di un prodotto, l'accesso e la completazione del checkout attraverso diversi pezzi consegnati indipendentemente.
Controlla la superficie di rilascio
Utilizza manifesti versionati in modo che il shell possa identificare l'artefatto di frammento esatto che carica. Un manifesto fornisce anche agli operatori un posto 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 in modo che 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 la nuova via con l'implementazione esistente prima di rendere la nuova rotta la default.
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 dell'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 rotta 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.
Utilizzare Micro Frontends in Capacitor e Electron
A Capacitor o un'applicazione Electron aggiunge un'altra shell intorno alla shell del browser. Capacitor colloca i web code all'interno di un WebView nativo mobile, mentre Electron esegue i web code in un processo di rendering desktop.
Quell'arrangiamento crea una suddivisione utile di rilascio. Le capacità native, i permessi e le ponti code restano legati all'applicazione installata, mentre le superfici di proprietà web, come ad esempio 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 dovrebbe 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. Dovrebbe consegnare pacchetti firmativerificarli prima dell'attivazione, supportare i canali di rilascio per i roll-out 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 alla consegna di frontend micro. Una shell mobile o desktop può fissare un manifesto, recuperare un frammento compatibile, verificarne la firma e attivarlo solo quando il bundle completo è disponibile. Se la prossima avviatura rileva un errore, l'aggiornatore può revertere allo 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 le applicazioni CapacitorJS e Electron pubblica pacchetti web firmati, supporta canali mirati, applica gli 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.
Un diagramma che illustra come utilizzare i micro frontends con __CAPGO_KEEP_0__ o gusci di applicazione native di Electron.
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 di cache o un fallback locale. Compatibilità:
- Un pacchetto web può dipendere dal comportamento del ponte nativo che il binario installato non supporta. Remote code must be authenticated, integrity-checked, and authorized for the application context.
- Il __CAPGO_KEEP_0__ remoto deve essere autenticato, verificato per l'integrità e autorizzato per il contesto dell'applicazione. La shell deve essere in grado di rifiutare un bundle non valido e ripristinare una versione funzionante senza richiedere una distribuzione immediata del magazzino.
- La sicurezza della sessione: Aggiornare durante un flusso di pagamento o di formazione può creare uno stato non coerente, quindi l'attivazione a partire dalla prossima esecuzione è più sicura di interrompere il lavoro attivo.
Questo modello rafforza il rollback quando la piattaforma di consegna offre l'attivazione atomica e i metri di rilascio dettagliati. Complica l'architettura quando gli squadra suppongono che l'indipendenza web elimini la pianificazione della 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 indipendentese più squadre possiedono superfici di prodotto separate e chiare, o se gli interfacce di legacy e nuove devono coesistere durante una lunga migrazione. La diversità tecnologica può anche giustificare il modello quando le squadre 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, 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 test di partenza semplice:
- Proprietà: Un team può prendere decisioni per la proposta di taglio?
- Boundary: Può la shell e la slice comunicare attraverso un contratto stabile?
- Release need: La squadra ha bisogno di distribuire indipendentemente?
- Operational readiness: È possibile monitorare, testare, bloccare e tornare indietro il frammento?
- User value: 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 caricamento 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 esecuzione e recuperare 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.
