Mestring af State i Frontend Micro-Frontends: Strategier for Deling af State på Tværs af Applikationer

Indførelsen af micro-frontends har revolutioneret, hvordan store webapplikationer bygges og vedligeholdes. Ved at opdele monolitiske frontends i mindre, uafhængigt deployerbare enheder, kan udviklingsteams opnå større agilitet, skalerbarhed og autonomi. Men dette arkitektoniske skift introducerer en betydelig udfordring: at håndtere og dele state på tværs af disse forskellige mikro-applikationer. Denne omfattende guide dykker ned i kompleksiteten af state management i frontend micro-frontends og udforsker forskellige strategier for effektiv deling af state på tværs af applikationer for et globalt publikum.

Micro-Frontend-Paradigmet og State-Udfordringen

Micro-frontends, inspireret af microservices-arkitekturmønsteret, sigter mod at nedbryde en frontend-applikation i mindre, selvstændige dele. Hver micro-frontend kan udvikles, deployeres og skaleres uafhængigt af dedikerede teams. Denne tilgang giver mange fordele:

• Uafhængig Deployment: Teams kan frigive opdateringer uden at påvirke andre dele af applikationen.
• Teknologisk Diversitet: Forskellige micro-frontends kan bruge forskellige frameworks eller biblioteker, hvilket giver teams mulighed for at vælge de bedste værktøjer til opgaven.
• Team-Autonomi: Mindre, fokuserede teams kan arbejde mere effektivt og med større ejerskab.
• Skalerbarhed: Individuelle komponenter kan skaleres baseret på efterspørgsel.

På trods af disse fordele medfører den distribuerede natur af micro-frontends udfordringen med at håndtere delt state. I en traditionel monolitisk frontend er state management relativt ligetil og håndteres ofte af en centraliseret store (som Redux eller Vuex) eller context-API'er. I en micro-frontend-arkitektur kan forskellige mikro-applikationer dog befinde sig i forskellige kodebaser, blive deployeret uafhængigt og endda køre med forskellige frameworks. Denne segmentering gør det svært for en micro-frontend at tilgå eller ændre data, der administreres af en anden.

Behovet for effektiv deling af state opstår i mange scenarier:

• Brugergodkendelse: Når en bruger logger ind, skal deres godkendelsesstatus og profiloplysninger være tilgængelige på tværs af alle micro-frontends.
• Indkøbskurvsdata: På en e-handelsplatform skal tilføjelsen af en vare til kurven i én micro-frontend afspejles i kurvoversigten, der vises i en anden.
• Brugerpræferencer: Indstillinger som sprog, tema eller notifikationspræferencer skal være konsistente på tværs af hele applikationen.
• Globale Søgeresultater: Hvis en søgning udføres i én del af applikationen, kan resultaterne skulle vises eller anvendes af andre komponenter.
• Navigation og Routing: Det er afgørende at opretholde konsistente navigationstilstande og routinginformation på tværs af uafhængigt administrerede sektioner.

Manglende effektiv håndtering af state-deling kan føre til fragmenterede brugeroplevelser, datainkonsistens og øget udviklingskompleksitet. For globale teams, der arbejder på store applikationer, er robuste strategier for state management altafgørende for at opretholde et sammenhængende og funktionelt produkt.

Forståelse af State i en Micro-Frontend-Kontekst

Før vi dykker ned i løsninger, er det vigtigt at definere, hvad vi mener med "state" i denne sammenhæng. State kan groft kategoriseres:

• Lokal Komponent-State: Dette er state, der er begrænset til en enkelt komponent inden for en micro-frontend. Det deles generelt ikke.
• Micro-Frontend-State: Dette er state, der er relevant for en specifik micro-frontend, men som måske skal tilgås eller ændres af andre komponenter *inden for den samme micro-frontend*.
• Applikationsdækkende State: Dette er den state, der skal være tilgængelig og konsistent på tværs af flere micro-frontends. Dette er vores primære fokus for state-deling på tværs af applikationer.

Udfordringen ligger i, at "applikationsdækkende state" i en micro-frontend-verden ikke er centraliseret fra starten. Vi har brug for eksplicitte mekanismer til at skabe og administrere dette delte lag.

Strategier for Deling af State på Tværs af Applikationer

Flere tilgange kan anvendes til at håndtere state på tværs af micro-frontend-applikationer. Hver har sine egne kompromiser med hensyn til kompleksitet, ydeevne og vedligeholdelse. Det bedste valg afhænger ofte af din applikations specifikke behov og dine udviklingsteams' kompetencer.

1. Browserens Indbyggede Lager (LocalStorage, SessionStorage)

Koncept: At udnytte browserens indbyggede lagringsmekanismer til at persistere data. localStorage persisterer data, selv efter browservinduet er lukket, mens sessionStorage ryddes, når sessionen afsluttes.

Sådan virker det: Én micro-frontend skriver data til localStorage, og andre micro-frontends kan læse fra det. Event listeners kan bruges til at detektere ændringer.

Fordele:

• Ekstremt simpelt at implementere.
• Kræver ingen eksterne afhængigheder.
• Persisterer på tværs af browserfaner for localStorage.

Ulemper:

• Synkron blokering: Læsning og skrivning kan blokere hovedtråden, hvilket påvirker ydeevnen, især med store datamængder.
• Begrænset kapacitet: Typisk omkring 5-10 MB, hvilket er utilstrækkeligt for komplekse applikationstilstande.
• Ingen realtidsopdateringer: Kræver manuel polling eller event-lytning for ændringer.
• Sikkerhedsbekymringer: Data gemmes på klientsiden og kan tilgås af ethvert script på samme origin.
• Streng-baseret: Data skal serialiseres (f.eks. ved hjælp af JSON.stringify) og deserialiseres.

Anvendelsesområde: Bedst egnet til simple, ikke-kritiske data som brugerpræferencer (f.eks. temavalg) eller midlertidige indstillinger, der ikke kræver øjeblikkelig synkronisering på tværs af alle micro-frontends.

Eksempel (konceptuelt):

Micro-frontend A (Brugerindstillinger):

            localStorage.setItem('userTheme', 'dark');
localStorage.setItem('language', 'en');
            

              
                Copy
              
            
          

Micro-frontend B (Header):

            const theme = localStorage.getItem('userTheme');
document.body.classList.add(theme);

window.addEventListener('storage', (event) => {
  if (event.key === 'language') {
    console.log('Language changed to:', event.newValue);
    // Update UI accordingly
  }
});
            

              
                Copy
              
            
          

2. Brugerdefineret Event Bus (Pub/Sub-Mønster)

Koncept: Implementering af en global event emitter eller en brugerdefineret event bus, der giver micro-frontends mulighed for at publicere events og abonnere på dem.

Sådan virker det: En central instans (ofte administreret af container-applikationen eller et delt hjælpeværktøj) lytter efter events. Når en micro-frontend publicerer et event med tilhørende data, underretter event bussen alle abonnerede micro-frontends.

Fordele:

• Afkoblet kommunikation: Micro-frontends behøver ikke direkte referencer til hinanden.
• Kan håndtere mere komplekse data end browserlager.
• Giver en mere event-drevet arkitektur.

Ulemper:

• Forurening af globalt scope: Hvis den ikke håndteres omhyggeligt, kan event bussen blive en flaskehals eller svær at debugge.
• Ingen persistens: Events er flygtige. Hvis en micro-frontend ikke er monteret, når et event affyres, går den glip af det.
• State-rekonstruktion: Abonnenter kan have brug for at rekonstruere deres state baseret på en strøm af events, hvilket kan være komplekst.
• Kræver koordinering: Definition af event-navne og data-payloads kræver omhyggelig aftale mellem teams.

Anvendelsesområde: Nyttigt til realtidsnotifikationer og simpel state-synkronisering, hvor persistens ikke er en primær bekymring, som f.eks. at underrette andre dele af appen om, at en bruger er logget ud.

Eksempel (konceptuelt ved hjælp af en simpel Pub/Sub-implementering):

            // shared/eventBus.js
class EventBus {
  constructor() {
    this.listeners = {};
  }
  on(event, callback) {
    if (!this.listeners[event]) {
      this.listeners[event] = [];
    }
    this.listeners[event].push(callback);
  }
  emit(event, data) {
    if (this.listeners[event]) {
      this.listeners[event].forEach(callback => callback(data));
    }
  }
}

export const eventBus = new EventBus();

// micro-frontend-a/index.js
import { eventBus } from '../shared/eventBus';

function handleLogin(userData) {
  // Update local state
  console.log('User logged in:', userData.name);
  // Publish an event
  eventBus.emit('userLoggedIn', userData);
}

// micro-frontend-b/index.js
import { eventBus } from '../shared/eventBus';

eventBus.on('userLoggedIn', (userData) => {
  console.log('Received userLoggedIn event in Micro-Frontend B:', userData.name);
  // Update UI or local state based on user data
  document.getElementById('userNameDisplay').innerText = userData.name;
});
            

              
                Copy
              
            
          

3. Delt State Management Bibliotek (Ekstern Store)

Koncept: At anvende et dedikeret state management-bibliotek, der er tilgængeligt for alle micro-frontends. Dette kan være en global instans af et populært bibliotek som Redux, Zustand, Pinia eller en specialbygget store.

Sådan virker det: Container-applikationen eller et fælles delt bibliotek initialiserer en enkelt store-instans. Alle micro-frontends kan derefter oprette forbindelse til denne store for at læse og afsende handlinger, hvilket effektivt deler state globalt.

Fordele:

• Centraliseret kontrol: Giver en enkelt kilde til sandhed (single source of truth).
• Rige funktioner: De fleste biblioteker tilbyder kraftfulde værktøjer til state-manipulation, time-travel debugging og middleware.
• Skalerbar: Kan håndtere komplekse state-scenarier.
• Forudsigelig: Følger etablerede mønstre for state-opdateringer.

Ulemper:

• Tæt kobling: Alle micro-frontends afhænger af det delte bibliotek og dets struktur.
• Enkelt fejlpunkt (single point of failure): Hvis store'en eller dens afhængigheder har problemer, kan det påvirke hele applikationen.
• Bundle-størrelse: At inkludere et state management-bibliotek kan øge den samlede JavaScript-bundle-størrelse, især hvis det ikke håndteres omhyggeligt med code splitting.
• Framework-afhængighed: Kan introducere framework-specifikke afhængigheder, hvis det ikke vælges klogt (f.eks. kan en Vuex-store til React micro-frontends være akavet).

Implementeringsovervejelser:

• Container-drevet: Container-applikationen kan være ansvarlig for at initialisere og levere store'en til alle monterede micro-frontends.
• Delt bibliotek: En dedikeret delt pakke kan eksportere store-instansen, hvilket giver alle micro-frontends mulighed for at importere og bruge den.
• Framework-agnosticisme: For maksimal fleksibilitet, overvej en framework-agnostisk state management-løsning eller et bibliotek, der understøtter flere frameworks (selvom dette kan tilføje kompleksitet).

Eksempel (konceptuelt med en hypotetisk delt Redux-store):

            // shared/store.js (exported from a common package)
import { configureStore } from '@reduxjs/toolkit';

const initialState = {
  user: null,
  cartCount: 0
};

const rootReducer = (state = initialState, action) => {
  switch (action.type) {
    case 'SET_USER':
      return { ...state, user: action.payload };
    case 'UPDATE_CART_COUNT':
      return { ...state, cartCount: action.payload };
    default:
      return state;
  }
};

export const store = configureStore({ reducer: rootReducer });

// micro-frontend-auth/index.js (e.g., React)
import React from 'react';
import ReactDOM from 'react-dom';
import { Provider, useDispatch, useSelector } from 'react-redux';
import { store } from '../shared/store';

function AuthComponent() {
  const dispatch = useDispatch();
  const user = useSelector(state => state.user);

  const login = () => {
    const userData = { id: 1, name: 'Alice' };
    dispatch({ type: 'SET_USER', payload: userData });
  };

  return (
    

      {user ? `Welcome, ${user.name}` : Login}
    
  );
}

// Mount logic...
ReactDOM.render(
  
    
  ,
  document.getElementById('auth-root')
);

// micro-frontend-cart/index.js (e.g., Vue)
import { createApp } from 'vue';
import App from './App.vue';
import { store } from '../shared/store'; // Assuming store is compatible or wrapped

// In a real scenario, you'd need to ensure compatibility or use adapters
// For simplicity, let's assume store can be used.

const app = createApp(App);
// If using Redux with Vue, you'd typically use 'vue-redux'
// app.use(VueRedux, store);

// For Pinia, it would be:
// import { createPinia } from 'pinia';
// const pinia = createPinia();
// app.use(pinia);
// Then have a shared pinia store.

// Example if using a shared store that emits events:
// Assuming a mechanism where store.subscribe exists
store.subscribe((mutation, state) => {
  // For Redux-like stores, observe state changes relevant to cart
  // console.log('State updated, checking cart count...', state.cartCount);
});

// To dispatch actions in Vue/Pinia, you'd access a shared store instance
// Example using Vuex concepts (if store was Vuex)
// this.$store.dispatch('someAction');

// If using a global Redux store, you'd inject it:
// app.config.globalProperties.$store = store; // This is a simplification

// To read state:
// const cartCount = store.getState().cartCount; // Using Redux getter

// app.mount('#cart-root');


4. URL/Routing som en State-Mekanisme

Koncept: At udnytte URL-parametre og query-strenge til at overføre state mellem micro-frontends, især for navigationsrelaterede eller dybt linkede tilstande.

Sådan virker det: Når der navigeres fra en micro-frontend til en anden, kodes relevant state-information i URL'en. Den modtagende micro-frontend parser URL'en for at hente state.

Fordele:

  
Kan bogmærkes og deles: URL'er er designet til netop dette.
  
Håndterer navigation: Integrerer naturligt med routing.
  
Ingen eksplicit kommunikation nødvendig: State overføres implicit via URL'en.


Ulemper:

  
Begrænset datakapacitet: URL'er har længdebegrænsninger. Ikke egnet til store eller komplekse datastrukturer.
  
Sikkerhedsbekymringer: Følsomme data i URL'er er synlige for alle.
  
Ydelsesmæssig overhead: Overdreven brug kan føre til re-renders eller kompleks parsing-logik.
  
Streng-baseret: Kræver serialisering og deserialisering.


Anvendelsesområde: Ideel til at overføre specifikke identifikatorer (som produkt-ID'er, bruger-ID'er) eller konfigurationsparametre, der definerer den aktuelle visning eller kontekst af en micro-frontend. Tænk på deep linking til en specifik produktdetaljeside.

Eksempel:

Micro-frontend A (Produktliste):
// User clicks on a product
window.location.href = '/products/123?view=details&source=list';
            

              
                Copy
              
            
          
        

Micro-frontend B (Produktdetaljer):

            // On page load, parse the URL
const productId = window.location.pathname.split('/')[2]; // '123'
const view = new URLSearchParams(window.location.search).get('view'); // 'details'

if (productId) {
  // Fetch and display product details for ID 123
}
if (view === 'details') {
  // Ensure details view is active
}

            

              
                Copy
              
            
          

5. Kommunikation på Tværs af Origins (iframes, postMessage)

Koncept: For micro-frontends, der hostes på forskellige origins (eller endda samme origin men med streng sandboxing), kan `window.postMessage` API'et bruges til sikker kommunikation.

Sådan virker det: Hvis micro-frontends er indlejret i hinanden (f.eks. ved hjælp af iframes), kan de sende beskeder til hinanden ved hjælp af `postMessage`. Dette giver mulighed for kontrolleret dataudveksling mellem forskellige browsing-kontekster.

Fordele:

• Sikker: `postMessage` er designet til kommunikation på tværs af origins og forhindrer direkte adgang til det andet vindues DOM.
• Eksplicit: Dataudveksling er eksplicit via beskeder.
• Framework-agnostisk: Fungerer mellem alle JavaScript-miljøer.

Ulemper:

• Kompleks opsætning: Kræver omhyggelig håndtering af origins og beskedstrukturer.
• Ydeevne: Kan være mindre performant end direkte metodekald, hvis det bruges overdrevent.
• Begrænset til iframe-scenarier: Mindre almindeligt, hvis micro-frontends er co-hostet på samme side uden iframes.

Anvendelsesområde: Nyttigt til integration af tredjeparts-widgets, indlejring af forskellige dele af en applikation som separate sikkerhedsdomæner, eller når micro-frontends reelt opererer i isolerede miljøer.

Eksempel:

            // In the sender iframe/window
const targetWindow = document.getElementById('my-iframe').contentWindow;
targetWindow.postMessage({
  type: 'USER_UPDATE',
  payload: { name: 'Bob', id: 2 }
}, 'https://other-origin.com'); // Specify target origin for security

// In the receiver iframe/window
window.addEventListener('message', (event) => {
  if (event.origin !== 'https://sender-origin.com') return;

  if (event.data.type === 'USER_UPDATE') {
    console.log('Received user update:', event.data.payload);
    // Update local state or UI
  }
});
            

              
                Copy
              
            
          

6. Delte DOM-Elementer og Brugerdefinerede Attributter

Koncept: En mindre almindelig, men levedygtig tilgang, hvor micro-frontends interagerer ved at læse fra og skrive til specifikke DOM-elementer eller bruge brugerdefinerede data-attributter på delte forældre-containere.

Sådan virker det: Én micro-frontend kan gengive en skjult `div` eller en brugerdefineret attribut på et `body`-tag med state-information. Andre micro-frontends kan forespørge DOM'en for at læse denne state.

Fordele:

• Simpelt til specifikke anvendelsesområder.
• Ingen eksterne afhængigheder.

Ulemper:

• Stærkt koblet til DOM-struktur: Gør refactoring vanskelig.
• Skrøbelig: Afhænger af, at specifikke DOM-elementer eksisterer.
• Ydeevne: Hyppige DOM-forespørgsler kan være ineffektive.
• Svært at håndtere kompleks state.

Anvendelsesområde: Generelt frarådes til kompleks state management, men kan være en hurtig løsning til meget simpel, lokaliseret state-deling inden for en tæt kontrolleret forældre-container.

7. Custom Elements og Events (Web Components)

Koncept: Hvis micro-frontends er bygget med Web Components, kan de kommunikere gennem standard DOM-events og -egenskaber, og udnytte custom elements som kanaler for state.

Sådan virker det: Et custom element kan eksponere egenskaber for at læse sin state eller afsende brugerdefinerede events for at signalere state-ændringer. Andre micro-frontends kan instantiere og interagere med disse custom elements.

Fordele:

• Framework-agnostisk: Web Components er en browser-standard.
• Indkapsling: Fremmer bedre komponent-isolering.
• Standardiseret kommunikation: Bruger DOM-events og -egenskaber.

Ulemper:

• Kræver anvendelse af Web Components: Er måske ikke egnet, hvis eksisterende micro-frontends bruger forskellige frameworks.
• Kan stadig føre til kobling: Hvis custom elements eksponerer for meget state eller kræver komplekse interaktioner.

Anvendelsesområde: Fremragende til at bygge genanvendelige, framework-agnostiske UI-komponenter, der indkapsler deres egen state og eksponerer grænseflader til interaktion og datodeling.

Valg af den Rette Strategi for Jeres Globale Team

Beslutningen om, hvilken state-delingsstrategi der skal anvendes, er kritisk og bør tage højde for flere faktorer:

• Kompleksiteten af State: Er det simple primitiver, komplekse objekter eller realtids-datastrømme?
• Hyppigheden af Opdateringer: Hvor ofte ændres state, og hvor hurtigt skal andre micro-frontends reagere?
• Persistenskrav: Skal state overleve side-genindlæsninger eller browser-lukninger?
• Teamets Ekspertise: Hvilke state management-mønstre er jeres teams bekendt med?
• Framework-Diversitet: Er jeres micro-frontends bygget med forskellige frameworks?
• Ydelsesovervejelser: Hvor meget overhead kan jeres applikation tolerere?
• Skalerbarhedsbehov: Vil den valgte strategi skalere, efterhånden som applikationen vokser?
• Sikkerhed: Er der følsomme data, der kræver beskyttelse?

Anbefalinger baseret på scenarier:

• For simple, ikke-kritiske præferencer: localStorage er tilstrækkeligt.
• For realtidsnotifikationer uden persistens: En Event Bus er et godt valg.
• For kompleks, applikationsdækkende state med forudsigelige opdateringer: Et Delt State Management Bibliotek er ofte den mest robuste løsning.
• For deep linking og navigation-state: URL/Routing er effektivt.
• For isolerede miljøer eller tredjeparts-indlejringer: postMessage med iframes.

Bedste Praksis for Global Micro-Frontend State Management

Uanset den valgte strategi er det afgørende at overholde bedste praksis for at opretholde en sund micro-frontend-arkitektur:

• Definér Klare Kontrakter: Etablér klare grænseflader og datastrukturer for delt state. Dokumenter disse kontrakter omhyggeligt. Dette er især vigtigt for globale teams, hvor misforståelser kan opstå på grund af kommunikationskløfter.
• Minimér Delt State: Del kun det, der er absolut nødvendigt. Overdreven deling kan føre til tæt kobling og gøre micro-frontends mindre uafhængige.
• Indkapsl State-Logik: Inden for hver micro-frontend skal state management-logik holdes så lokaliseret som muligt.
• Vælg Framework-Agnostiske Løsninger, Når Det Er Muligt: Hvis I har betydelig framework-diversitet, så vælg state management-løsninger, der er framework-agnostiske eller giver god understøttelse for flere frameworks.
• Implementér Robust Overvågning og Debugging: Med distribueret state kan debugging være en udfordring. Implementer værktøjer og praksisser, der giver jer mulighed for at spore state-ændringer på tværs af micro-frontends.
• Overvej en Container-Applikations Rolle: Den orkestrerende container-applikation spiller ofte en afgørende rolle i at starte delte tjenester, herunder state management.
• Dokumentation er Nøglen: For globale teams er omfattende og opdateret dokumentation om state-delingsmekanismer, event-skemaer og dataformater ikke til forhandling.
• Automatiseret Testning: Sørg for grundig testning af state-interaktioner mellem micro-frontends. Kontrakttestning kan være særligt værdifuld her.
• Faseopdelt Udrulning: Når I introducerer nye state-delingsmekanismer eller migrerer eksisterende, overvej en faseopdelt udrulning for at minimere forstyrrelser.

Håndtering af Udfordringer i en Global Kontekst

At arbejde med micro-frontends og delt state på globalt plan introducerer unikke udfordringer:

• Tidszoneforskelle: Koordinering af deployments, debugging-sessioner og definition af state-kontrakter kræver omhyggelig planlægning og asynkrone kommunikationsstrategier. Dokumenterede beslutninger er afgørende.
• Kulturelle Nuancer: Selvom de tekniske aspekter af state-deling er universelle, kan måden, teams kommunikerer og samarbejder på, variere. At fremme en kultur med klar kommunikation og en fælles forståelse af arkitektoniske principper er afgørende.
• Varierende Netværkslatens: Hvis state hentes fra eksterne tjenester eller kommunikeres over netværk, kan latens påvirke brugeroplevelsen. Overvej strategier som caching, pre-fetching og optimistiske opdateringer.
• Infrastruktur- og Deployment-Forskelle: Globale teams kan operere i forskellige cloud-miljøer eller have forskellige deployment-pipelines. At sikre konsistens i, hvordan delt state håndteres og deployeres, er vigtigt.
• Onboarding af Nye Teammedlemmer: En kompleks micro-frontend-arkitektur med indviklet state-deling kan være overvældende for nyankomne. Klar dokumentation, veldefinerede mønstre og mentorskab er essentielt.

For eksempel vil en applikation inden for finansielle tjenester med micro-frontends til kontoadministration, handel og kundesupport, der er deployeret på tværs af regioner som Nordamerika, Europa og Asien, i høj grad stole på delt godkendelse og brugerprofil-states. At sikre, at brugerdata er konsistente og sikre på tværs af alle disse regioner, samtidig med at man overholder regionale databeskyttelsesforordninger (som GDPR eller CCPA), kræver robust og velarkitektonisk state management.

Konklusion

Micro-frontend-arkitekturer tilbyder et enormt potentiale for at bygge skalerbare og agile webapplikationer. Men effektiv håndtering af state på tværs af disse uafhængige enheder er en hjørnesten i en vellykket implementering. Ved at forstå de forskellige tilgængelige strategier – fra simpel browserlager og event buses til sofistikerede delte state management-biblioteker og URL-baseret kommunikation – kan udviklingsteams vælge den tilgang, der bedst passer til deres projekts behov.

For globale teams flytter fokus sig ikke kun til den tekniske løsning, men også til processerne omkring den: klar kommunikation, omfattende dokumentation, robust testning og en fælles forståelse af arkitektoniske mønstre. At mestre state-deling i frontend micro-frontends er en vedvarende rejse, men med de rette strategier og bedste praksis er det en udfordring, der kan overvindes, hvilket fører til mere sammenhængende, performante og vedligeholdelsesvenlige webapplikationer for brugere over hele verden.