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à.

Routing e comunicazione tra microfrontend

Le opzioni di routing dipendono dall'approccio di composizione. La comunicazione può essere ottimizzata riducendo l'accoppiamento tra i componenti del frontend.

Routing

Le applicazioni che utilizzano la composizione lato client con divisione verticale possono utilizzare il routing lato server (applicazione multipagina) o il routing lato client (applicazione a pagina singola). Se utilizzano una suddivisione mista per la composizione dell'interfaccia utente, il routing lato client è necessario per supportare gerarchie di routing più profonde dei micro-frontend su una pagina.

Le applicazioni che utilizzano la composizione edge-side e la composizione lato server si allineano meglio con il routing lato server o il routing con l'edge computing come Lambda @Edge con Amazon. CloudFront

Comunicazione tra micro-frontend

Con le architetture micro-frontend, consigliamo di ridurre l'accoppiamento tra i componenti del frontend. Un approccio per ridurre l'accoppiamento consiste nel passare dalle chiamate di funzione sincrone alla messaggistica asincrona.

I runtime del browser e le interazioni con gli utenti sono asincroni per natura. Gli eventi possono essere scambiati tra produttori e consumatori tramite messaggi. Gli eventi forniscono un'interfaccia ben definita per la comunicazione tra microfrontend.

Se segui le pratiche DDD per identificare i tuoi contesti limitati per i microfrontend, il passaggio successivo consiste nell'identificare gli eventi che devono essere comunicati oltre i confini.

Il meccanismo di messaggistica per gli eventi può essere costituito da eventi DOM nativi (CustomEvents), emettitori di eventi o JavaScript librerie di flussi reattivi fornite dai team della piattaforma. I micro-frontend pubblicano eventi e si iscrivono a eventi pertinenti per il loro contesto limitato. Con questo metodo, gli editori e gli abbonati non devono conoscersi a vicenda. Il contratto è la definizione dell'evento. Per una rappresentazione visiva di ciò, vedere la sezione Comunica con gli eventi del diagramma Bounded context with Event Architectures.