Mestre kommunikasjon mellom applikasjoner: Hendelsesbussen for Micro-Frontends i Frontend

I moderne webutvikling har micro-frontends vokst frem som et kraftig arkitektonisk mønster. De lar team bygge og distribuere uavhengige deler av et brukergrensesnitt, noe som fremmer smidighet, skalerbarhet og teamautonomi. En kritisk utfordring oppstår imidlertid når disse uavhengige applikasjonene trenger å kommunisere med hverandre. Uten en robust mekanisme kan micro-frontends bli isolerte øyer, noe som hindrer den sammenhengende brukeropplevelsen som brukerne forventer. Det er her Hendelsesbussen for Micro-Frontends i Frontend kommer inn i bildet, og fungerer som det sentrale nervesystemet for kommunikasjon på tvers av applikasjoner.

Forstå landskapet for Micro-Frontends

Før vi dykker ned i hendelsesbussen, la oss kort gjenopprette konteksten for micro-frontends. Se for deg en stor e-handelsplattform. I stedet for en enkelt, monolittisk frontend-applikasjon, kan vi ha:

• En Produktkatalog Micro-Frontend: Ansvarlig for å vise produktlister, søk og filtrering.
• En Handlevogn Micro-Frontend: Håndterer varer lagt i handlekurven, antall og igangsetting av kassen.
• En Brukerprofil Micro-Frontend: Håndterer brukerautentisering, ordrehistorikk og personlige detaljer.
• En Anbefalingsmotor Micro-Frontend: Foreslår relaterte produkter basert på brukeratferd.

Hver av disse kan utvikles, distribueres og vedlikeholdes uavhengig av forskjellige team. Dette gir betydelige fordeler:

• Teknologisk mangfold: Team kan velge den beste teknologistakken for sin spesifikke micro-frontend.
• Teamautonomi: Utviklingsteam kan jobbe uavhengig uten omfattende koordinering.
• Raskere distribusjonssykluser: Mindre, uavhengige distribusjoner reduserer risiko og øker hastigheten.
• Skalerbarhet: Individuelle micro-frontends kan skaleres basert på etterspørsel.

Utfordringen: Kommunikasjon mellom applikasjoner

Skjønnheten ved uavhengig utvikling kommer med en betydelig utfordring: hvordan snakker disse separate applikasjonene med hverandre? Vurder disse vanlige scenarioene:

• Når en bruker legger en vare i Handlevognen, kan Produktkatalogen trenge å visuelt indikere at varen nå er i handlekurven (f.eks. med et hakemerke).
• Når en bruker logger inn via Brukerprofil micro-frontend, kan andre micro-frontends (som Anbefalingsmotoren) trenge å vite brukerens autentiseringsstatus for å tilpasse innholdet.
• Når en bruker foretar et kjøp, kan Handlevognen trenge å varsle Produktkatalogen for å oppdatere lagertall eller Brukerprofilen for å reflektere den nye ordrehistorikken.

Direkte kommunikasjon mellom micro-frontends frarådes ofte fordi det skaper tett kobling, noe som motvirker mange av fordelene med micro-frontend-arkitekturen. Vi trenger en løst koblet, fleksibel og skalerbar måte for dem å samhandle på.

Introduksjon til hendelsesbussen for Micro-Frontends i Frontend

En hendelsesbuss, også kjent som en meldingsbuss eller pub/sub (publiser-abonner)-system, er et designmønster som muliggjør avkoblet kommunikasjon mellom forskjellige deler av en applikasjon. I konteksten av micro-frontends fungerer den som et sentralt knutepunkt der applikasjoner kan publisere hendelser og andre applikasjoner kan abonnere på disse hendelsene.

Kjerneideen er enkel:

• Utgiver (Publisher): En applikasjon som genererer en hendelse og kringkaster den til bussen.
• Abonnent (Subscriber): En applikasjon som lytter etter spesifikke hendelser på bussen og reagerer når de inntreffer.
• Hendelsesbuss (Event Bus): Mellomleddet som fasiliterer levering av publiserte hendelser til alle interesserte abonnenter.

Dette mønsteret er også nært beslektet med Observatørmønsteret (Observer pattern), der ett objekt (subjektet) vedlikeholder en liste over sine avhengige (observatører) og varsler dem automatisk om eventuelle tilstandsendringer, vanligvis ved å kalle en av deres metoder.

Nøkkelprinsipper for en hendelsesbuss for Micro-Frontends

1. Avkobling: Utgivere og abonnenter trenger ikke å vite om hverandres eksistens. De samhandler kun gjennom hendelsesbussen.
2. Asynkron kommunikasjon: Hendelser behandles vanligvis asynkront, noe som betyr at utgiveren ikke trenger å vente på at abonnentene skal fullføre behandlingen av hendelsen.
3. Skalerbarhet: Etter hvert som flere micro-frontends legges til, kan de enkelt abonnere på eller publisere hendelser uten å påvirke eksisterende.
4. Sentralisert logikk (for hendelser): Mens applikasjonslogikken forblir distribuert, er hendelseshåndteringsmekanismen sentralisert gjennom bussen.

Designe din Micro-Frontend hendelsesbuss

Det finnes flere tilnærminger til å implementere en micro-frontend hendelsesbuss, hver med sine fordeler og ulemper. Valget avhenger ofte av de spesifikke behovene til applikasjonen din, de underliggende teknologiene som brukes, og distribusjonsstrategien.

1. Global hendelsesutløser (JavaScript)**

Dette er en vanlig og relativt enkel tilnærming for micro-frontends som distribueres innenfor samme nettleserkontekst (f.eks. ved hjelp av module federation eller iframe-kommunikasjon). Et enkelt, delt JavaScript-objekt fungerer som hendelsesbussen.

Implementasjonseksempel (konseptuell JavaScript)

Vi kan lage en enkel klasse for hendelsesutløsning:

            class EventBus {
  constructor() {
    this.listeners = {};
  }

  subscribe(event, callback) {
    if (!this.listeners[event]) {
      this.listeners[event] = [];
    }
    this.listeners[event].push(callback);
    return () => {
      this.unsubscribe(event, callback);
    };
  }

  unsubscribe(event, callback) {
    if (!this.listeners[event]) {
      return;
    }
    this.listeners[event] = this.listeners[event].filter(listener => listener !== callback);
  }

  publish(event, data) {
    if (!this.listeners[event]) {
      return;
    }
    this.listeners[event].forEach(callback => {
      try {
        callback(data);
      } catch (error) {
        console.error(`Error in event handler for ${event}:`, error);
      }
    });
  }
}

// In your main application shell or a shared utility file:
export const sharedEventBus = new EventBus();

            

              
                Copy
              
            
          

Hvordan Micro-Frontends bruker den

Produktkatalog Micro-Frontend (utgiver):

            import { sharedEventBus } from './sharedEventBus'; // Assuming sharedEventBus is imported correctly

function handleAddToCartButtonClick(productId) {
  // ... logic to add item to cart ...
  sharedEventBus.publish('itemAddedToCart', { productId: productId, quantity: 1 });
}

            

              
                Copy
              
            
          

Handlevogn Micro-Frontend (abonnent):

            import { sharedEventBus } from './sharedEventBus'; // Assuming sharedEventBus is imported correctly

// When the cart component mounts or initializes
const subscription = sharedEventBus.subscribe('itemAddedToCart', (eventData) => {
  console.log('Item added to cart:', eventData);
  // Update cart UI, add item to internal state, etc.
  updateCartUI(eventData.productId, eventData.quantity);
});

// Remember to unsubscribe when the component unmounts to prevent memory leaks
// componentWillUnmount() { subscription(); }

            

              
                Copy
              
            
          

Vurderinger for globale hendelsesutløsere

• Omfang (Scope): Denne tilnærmingen fungerer bra når micro-frontends lastes innenfor samme nettleservindu og deler et globalt omfang eller et felles modulsystem (som Webpacks Module Federation).
• Minnelekkasjer: Det er avgjørende å implementere skikkelige mekanismer for avabonnering når micro-frontend-komponenter avmonteres for å unngå minnelekkasjer.
• Navnekonvensjoner for hendelser: Etabler klare navnekonvensjoner for hendelser for å forhindre kollisjoner og sikre vedlikeholdbarhet. Bruk for eksempel et prefiks som [micro-frontend-name]:eventName.
• Datastruktur: Definer konsistente datastrukturer for hendelser.

2. Egendefinerte hendelser og DOM-utsending

En annen nettleser-nativ tilnærming utnytter DOM som en kommunikasjonskanal. Micro-frontends kan sende egendefinerte hendelser på et delt DOM-element (f.eks. `window`-objektet eller et dedikert konteinerelement), og andre micro-frontends kan lytte etter disse hendelsene.

Implementasjonseksempel (konseptuell JavaScript)

Produktkatalog Micro-Frontend (utgiver):

            
function handleAddToCartButtonClick(productId) {
  const event = new CustomEvent('microfrontend:itemAddedToCart', {
    detail: { productId: productId, quantity: 1 }
  });
  window.dispatchEvent(event);
}

            

              
                Copy
              
            
          

Handlevogn Micro-Frontend (abonnent):

            
const handleItemAdded = (event) => {
  console.log('Item added to cart:', event.detail);
  updateCartUI(event.detail.productId, event.detail.quantity);
};

window.addEventListener('microfrontend:itemAddedToCart', handleItemAdded);

// Remember to remove the listener when the component unmounts
// window.removeEventListener('microfrontend:itemAddedToCart', handleItemAdded);

            

              
                Copy
              
            
          

Vurderinger for egendefinerte hendelser

• Nettleserkompatibilitet: `CustomEvent` er bredt støttet, men det er alltid lurt å verifisere.
• Begrensninger for dataoverføring: `detail`-egenskapen til `CustomEvent` kan overføre vilkårlige serialiserbare data.
• Forurensning av globalt navnerom: Utsending av hendelser på `window` kan føre til navnekollisjoner hvis det ikke håndteres forsiktig.
• Ytelse: For et svært høyt volum av hendelser er dette kanskje ikke den mest ytelsessterke løsningen sammenlignet med en dedikert hendelsesutløser.

3. Meldingskøer eller eksterne meglere (for mer komplekse scenarioer)

For micro-frontends som kan kjøre i forskjellige nettleserkontekster (f.eks. iframes fra forskjellige opphav), eller hvis du trenger mer robuste funksjoner som garantert levering, meldingspersistens eller kringkasting til server-side-komponenter, kan du vurdere å bruke eksterne meldingskøsystemer.

Eksempler inkluderer:

• WebSockets: For sanntids, toveiskommunikasjon.
• Server-Sent Events (SSE): For enveis server-til-klient-kommunikasjon.
• Dedikerte meldingsmeglere: Som RabbitMQ, Apache Kafka, eller skybaserte løsninger (AWS SQS/SNS, Google Cloud Pub/Sub).

Implementasjonseksempel (konseptuelt - WebSockets)

En WebSocket-server i backend fungerer som den sentrale megleren.

Produktkatalog Micro-Frontend (utgiver):

            
// Assuming a WebSocket connection is established and managed globally
function handleAddToCartButtonClick(productId) {
  if (websocketConnection.readyState === WebSocket.OPEN) {
    websocketConnection.send(JSON.stringify({
      event: 'itemAddedToCart',
      data: { productId: productId, quantity: 1 }
    }));
  }
}

            

              
                Copy
              
            
          

Handlevogn Micro-Frontend (abonnent):

            
// Assuming a WebSocket connection is established and managed globally
websocketConnection.onmessage = (event) => {
  const message = JSON.parse(event.data);
  if (message.event === 'itemAddedToCart') {
    console.log('Item added to cart (from WS):', message.data);
    updateCartUI(message.data.productId, message.data.quantity);
  }
};

            

              
                Copy
              
            
          

Vurderinger for eksterne meglere

• Infrastruktur-overhead: Krever oppsett og administrasjon av en separat tjeneste.
• Latens: Kommunikasjon går vanligvis gjennom en server, noe som kan introdusere latens.
• Kompleksitet: Mer komplekst å sette opp og administrere enn løsninger i nettleseren.
• Skalerbarhet og pålitelighet: Tilbyr ofte høyere skalerbarhet og pålitelighetsgarantier.
• Kommunikasjon på tvers av opphav (Cross-Origin): Essensielt for iframes fra forskjellige opphav.

Beste praksis for implementering av en Micro-Frontend hendelsesbuss

Uavhengig av valgt implementasjon, vil overholdelse av beste praksis sikre et robust og vedlikeholdbart system.

1. Definer en tydelig kontrakt for hendelser

Hver hendelse bør ha en veldefinert struktur. Dette inkluderer:

• Hendelsesnavn: En unik og beskrivende identifikator.
• Payload-struktur: Formen og typene data som hendelsen bærer.

Eksempel:

Hendelsesnavn: userProfile:authenticated

Payload:

            {
  "userId": "abc-123",
  "timestamp": "2023-10-27T10:30:00Z"
}

            

              
                Copy
              
            
          

2. Etabler navnekonvensjoner

For å unngå navnekonflikter, spesielt i større micro-frontend-arkitekturer, implementer en konsistent navnestrategi. Prefikser anbefales på det sterkeste.

• Omfangsbaserte prefikser: [microfrontend-name]:[eventName] (f.eks. catalog:productViewed, cart:itemRemoved)
• Domenebaserte prefikser: [domain]:[eventName] (f.eks. auth:userLoggedIn, orders:orderPlaced)

3. Sørg for korrekt avabonnering

Minnelekkasjer er en vanlig fallgruve. Sørg alltid for at lyttere fjernes når komponenten eller micro-frontenden som registrerte dem ikke lenger er aktiv. Dette er spesielt kritisk i single-page-applikasjoner der komponenter opprettes og ødelegges dynamisk.

            // Example using a framework like React
import React, { useEffect } from 'react';
import { sharedEventBus } from './sharedEventBus';

function OrderSummary({ orderId }) {
  useEffect(() => {
    const subscription = sharedEventBus.subscribe('order:statusUpdated', (data) => {
      if (data.orderId === orderId) {
        console.log('Order status updated:', data.status);
        // Update component state based on new status
      }
    });

    // Cleanup function: unsubscribe when the component unmounts
    return () => {
      subscription(); // This calls the unsubscribe function returned by subscribe
    };
  }, [orderId]); // Re-subscribe if orderId changes

  return (
    

      
Order #{orderId}
      {/* ... order details ... */}
    
  );
}

            

              
                Copy
              
            
          

4. Håndter feil elegant

Hva skjer hvis en abonnent kaster en feil? Implementeringen av hendelsesbussen bør ideelt sett ikke stoppe behandlingen av andre abonnenter. Implementer `try...catch`-blokker rundt kall til tilbakekallingsfunksjoner for å sikre robusthet.

5. Vurder hendelsesgranularitet

Unngå å lage altfor brede hendelser som sender ut for mye data eller for ofte. Omvendt, ikke lag hendelser som er for spesifikke og fører til en eksplosjon av hendelsestyper.

• For bredt: En hendelse som dataChanged er lite hjelpsom.
• For spesifikt: productNameChanged, productPriceChanged, productDescriptionChanged kan være bedre å dele inn i en enkelt product:updated-hendelse med spesifikke felt som indikerer hva som endret seg, eller håndteres av applikasjonen som eier dataene.

Streb etter en balanse som representerer meningsfulle tilstandsendringer eller handlinger i systemet ditt.

6. Versjonering av hendelser

Etter hvert som micro-frontend-arkitekturen din utvikler seg, kan hendelsesstrukturer måtte endres. Vurder en versjoneringsstrategi for hendelsene dine, spesielt hvis du bruker eksterne meldingsmeglere eller hvis nedetid ikke er et alternativ under oppdateringer.

7. Global hendelsesbuss som en delt avhengighet

Hvis du bruker en delt JavaScript-hendelsesutløser, sørg for at den virkelig er delt på tvers av alle dine micro-frontends. Teknologier som Webpack Module Federation gjør dette enkelt ved å la deg eksponere og konsumere moduler globalt.

            // webpack.config.js (in host application)
module.exports = {
  //...
  plugins: [
    new ModuleFederationPlugin({
      name: 'hostApp',
      remotes: {
        catalogApp: 'catalogApp@http://localhost:3001/remoteEntry.js',
        cartApp: 'cartApp@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        './src/sharedEventBus': { 
          singleton: true, 
          eager: true // Load immediately
        }
      }
    })
  ]
};

// webpack.config.js (in micro-frontend 'catalogApp')
module.exports = {
  //...
  plugins: [
    new ModuleFederationPlugin({
      name: 'catalogApp',
      filename: 'remoteEntry.js',
      exposes: {
        './CatalogApp': './src/bootstrap',
        './SharedEventBus': './src/sharedEventBus'
      },
      shared: {
        './src/sharedEventBus': {
          singleton: true,
          eager: true
        }
      }
    })
  ]
};

            

              
                Copy
              
            
          

Når man ikke bør bruke en hendelsesbuss

Selv om den er kraftig, er en hendelsesbuss ikke en universalløsning for alle kommunikasjonsbehov. Den er best egnet for å kringkaste hendelser og håndtere sideeffekter. Den er generelt ikke det ideelle mønsteret for:

• Direkte forespørsel/svar: Hvis micro-frontend A trenger en spesifikk databit fra micro-frontend B og må vente på disse dataene umiddelbart, kan et direkte API-kall eller en delt tilstandshåndteringsløsning være mer hensiktsmessig enn å utløse en hendelse og håpe på et svar.
• Kompleks tilstandshåndtering: For å håndtere intrikat delt applikasjonstilstand på tvers av flere micro-frontends, kan et dedikert tilstandshåndteringsbibliotek (potensielt med sin egen hendelses- eller abonnementsmodell) være mer egnet.
• Kritiske synkrone operasjoner: Hvis umiddelbar, synkron koordinering er nødvendig, kan den asynkrone naturen til en hendelsesbuss være en ulempe.

Alternative kommunikasjonsmønstre i Micro-Frontends

Det er verdt å merke seg at hendelsesbussen bare er ett verktøy i verktøykassen for micro-frontend-kommunikasjon. Andre mønstre inkluderer:

• Delt tilstandshåndtering: Biblioteker som Redux, Vuex eller Zustand kan deles mellom micro-frontends for å håndtere felles tilstand.
• Props og Callbacks: Når en micro-frontend er direkte innebygd eller komponert i en annen (f.eks. ved hjelp av Webpack Module Federation), kan direkte overføring av props og tilbakekallingsfunksjoner brukes, selv om dette introduserer kobling.
• Web Components/Custom Elements: Kan kapsle inn funksjonalitet og eksponere egendefinerte hendelser og egenskaper for kommunikasjon.
• Ruting og URL-parametere: Å dele tilstand via URL-en kan være en enkel, tilstandsløs måte å kommunisere på.

Ofte brukes en kombinasjon av disse mønstrene for å bygge en omfattende micro-frontend-arkitektur.

Globale eksempler og betraktninger

Når du bygger en micro-frontend hendelsesbuss for et globalt publikum, bør du vurdere disse punktene:

• Tidssoner: Sørg for at all tidsstempeldata i hendelser er i et universelt forstått format (som ISO 8601 med UTC) og at konsumentene er klar over hvordan de skal tolke det.
• Lokalisering/Internasjonalisering (i18n): Hendelser i seg selv bærer vanligvis ikke UI-tekst, men hvis de utløser UI-oppdateringer, må disse oppdateringene lokaliseres. Hendelsesdata bør ideelt sett være språkuavhengige.
• Valuta og enheter: Hvis hendelser involverer pengeverdier eller mål, vær eksplisitt om valutaen eller enheten, eller design payloaden for å imøtekomme dem.
• Regionale reguleringer (f.eks. GDPR, CCPA): Hvis hendelser bærer personopplysninger, sørg for at implementeringen av hendelsesbussen og de involverte micro-frontends overholder relevante personvernforskrifter. Sørg for at data kun publiseres til abonnenter som har et legitimt behov for dem og har passende samtykkemekanismer på plass.
• Ytelse og båndbredde: For brukere i regioner med tregere internettforbindelser, unngå altfor pratsomme hendelsesmønstre eller store hendelses-payloads. Optimaliser dataoverføringen.

Konklusjon

Hendelsesbussen for Micro-Frontends i Frontend er et uunnværlig mønster for å muliggjøre sømløs, avkoblet kommunikasjon mellom uavhengige micro-frontend-applikasjoner. Ved å omfavne publiser-abonner-modellen kan utviklingsteam bygge komplekse, skalerbare webapplikasjoner samtidig som de opprettholder smidighet og teamautonomi.

Enten du velger en enkel global hendelsesutløser, utnytter egendefinerte DOM-hendelser, eller integrerer med robuste eksterne meldingsmeglere, ligger nøkkelen i å definere klare kontrakter, etablere konsistente konvensjoner, og omhyggelig håndtere livssyklusen til hendelseslytterne dine. En velimplementert hendelsesbuss forvandler dine micro-frontends fra isolerte komponenter til en sammenhengende, dynamisk og responsiv brukeropplevelse.

Når du arkitekterer ditt neste micro-frontend-initiativ, husk å prioritere kommunikasjonsstrategier som fremmer løs kobling og skalerbarhet. Hendelsesbussen, når den brukes omtenksomt, vil være en hjørnestein for din suksess.