Web Delivery — Microfrontend Architecture

The web experience for tenant workers is delivered through a microfrontend (MFE) architecture. This takes the isolation idea from the mobile strategy and pushes it further: instead of bundling all domains together at build time, each domain is deployed as a separate frontend application that the browser loads at runtime.

What is a Microfrontend?

A microfrontend is a technique where a web application is split into smaller, independently deployable pieces. Each piece is owned by a team and can be deployed on its own schedule — without requiring a coordinated release of the whole app.

Think of it like microservices on the backend, but applied to the frontend.

Key difference from the mobile strategy

On mobile, all modules are bundled into one app and released together. On the web, each domain MFE is deployed separately and loaded by the browser on demand. A team can push a fix to the Safety & Compliance MFE without any other team needing to redeploy.

Structure

The web experience is composed of a Shell App and several Domain MFEs.

graph TB
    subgraph Browser["User's Browser"]
        direction TB

        subgraph Shell["Shell App (Main Web Application)"]
            Auth["Authentication\n(SSO, token management)"]
            Routing["Routing\n(decides which MFE to show)"]
            Company["Company Selection\n& License Validation"]
            Layout["Shared Layout\n(nav, header, notifications)"]
        end

        subgraph MFEs["Domain Microfrontends — loaded remotely"]
            WF["Workforce\nMFE"]
            Prod["Productivity\nMFE"]
            Safety["Safety & Compliance MFE\n(Checkingmate + Saffer)"]
            Monitor["Worker Monitoring\nMFE"]
            Asset["Asset Management\nMFE"]
        end

        Shell -->|"loads at runtime\nfrom remote URL"| MFEs
    end

    User(["Worker / Supervisor / Manager"]) --> Shell

The Shell App

The Shell App is a lightweight application responsible for:

• Authentication — SSO login, token refresh, and propagating auth context to all MFEs.
• Routing — deciding which domain MFE to activate based on the current URL.
• Company selection & licensing — same as in the mobile strategy, shared context available to all MFEs.
• Shared layout — the navigation sidebar, top bar, and global notification area. These live in the shell so they are consistent across all domains.

The Shell App itself renders no domain-specific business functionality. Its job is to bootstrap the environment and hand control over to the right MFE.

Domain MFEs

Each MFE is a self-contained React application that owns its domain end-to-end. It is hosted and deployed independently from the shell and from other MFEs.

When a user navigates to a domain (for example, /safety), the Shell loads the Safety & Compliance MFE from its remote URL, mounts it into the page, and passes the shared context (user, company, token).

Domains Are Not 1:1 with Applications

An important design decision: MFEs are grouped by domain, not by application.

For example, the Safety & Compliance domain includes both the Checkingmate and Saffer applications. These are not deployed as two separate MFEs — they are combined into one Safety & Compliance MFE. This keeps the number of MFEs manageable and reflects the DDD bounded context boundaries.

graph LR
    subgraph Domain["Safety & Compliance MFE (one deployment)"]
        CM["Checkingmate\n(safety forms & templates)"]
        SF["Saffer\n(anomaly detection & compliance)"]
    end

Independent Deployment

The real power of this architecture is that each team can deploy their MFE without coordinating with other teams.

sequenceDiagram
    participant Dev as Developer (Safety Team)
    participant CI as CI/CD Pipeline
    participant CDN as CDN / Static Hosting
    participant Shell as Shell App
    participant Browser as Worker's Browser

    Dev->>CI: Push fix to Safety & Compliance MFE
    CI->>CI: Build only the Safety MFE
    CI->>CDN: Deploy new Safety MFE bundle
    Note over CDN: Workforce, Productivity, etc.\nare NOT redeployed
    Browser->>Shell: User navigates to /safety
    Shell->>CDN: Fetch latest Safety MFE
    CDN->>Browser: Returns new bundle
    Browser->>Browser: Renders updated Safety MFE

Domain-to-MFE Mapping

Domain	MFE	Applications included
Workforce Management	Workforce MFE	Angelis Worker Web (workforce features)
Productivity	Productivity MFE	Productivity module
Safety & Compliance	Safety & Compliance MFE	Checkingmate, Saffer
Worker Monitoring	Worker Monitoring MFE	Monitoring module
Asset Management	Asset Management MFE	Asset tracking module

Rule of thumb for junior engineers

When you’re working on a feature, identify which domain it belongs to. That tells you which MFE repository to work in. You should rarely need to touch the Shell App unless you are changing navigation, authentication, or shared layout.