Micro Frontend Orchestration

In the VENI-AI platform, Micro Frontends (MFE) are not just a UI pattern—they are a core architectural pillar managed by the Backend. The Shell API acts as the central orchestrator that enables independent satellites to be discovered, loaded, and secured within a unified workspace.

---

1. The Backend as a Registry

Unlike traditional MFE setups that use hardcoded URLs, VENI-AI uses a Dynamic Registry pattern.

The apps Table

The Shell API maintains a database of all registered satellites. Each entry defines the "contract" for that MFE:

• Slug: The unique identifier used in the URL (e.g., /drive, /hrm).
• UI URL: The base URL where the satellite's frontend is hosted.
• API URL: The endpoint for the satellite's backend services.
• Entry Point: The path to the remoteEntry.js (standardized as root).

Discovery API

The Shell UI does not know which apps exist until it queries the backend:

• Endpoint: GET /api/config/apps
• Response: A list of active apps with their Federation metadata.
• Caching: This registry is cached in Redis to ensure zero-latency for the Shell's startup.

---

2. Dynamic Federation Handshake

The backend facilitates the "handshake" that allows the Shell UI to inject a remote app at runtime.

Loading Flow

1. Request: User navigates to /hrm.
2. Lookup: Shell UI asks Shell API: "Where is the HRM entry point?"
3. Resolve: Shell API returns http://localhost:4175/remoteEntry.js.
4. Inject: Shell UI uses the Vite Module Federation runtime to fetch and mount the remote component.

---

3. Securing the Bridge (SSO)

Micro frontends must share the same security context without forcing the user to log in multiple times. The backend enables this through Token Broadcasting.

Identity Propagation

• Broadcasting: When the Shell API issues a JWT, the Shell UI writes it to localStorage and broadcasts it via BroadcastChannel.
• Backend Exchange: The remote MFE picks up this Shell JWT and calls its own satellite API (POST /auth/exchange).
• Verification: The satellite API calls the Shell API's JWKS endpoint to verify the token without needing a shared secret.

---

4. Why Backend-Driven MFE?

By moving the MFE configuration to the Backend Core, we gain several advantages:

Benefit	Description
Zero-Downtime Updates	You can point to a new version of a satellite by updating a single row in the Shell DB.
Feature Flagging	Apps can be enabled/disabled for specific organizations via the backend registry.
Environment Parity	The same Shell UI build works in Dev, UAT, and Prod because it resolves URLs dynamically from the API.
Independent Deploys	Satellites can be deployed to different clusters or regions; the Shell API simply routes to the correct URL.

Integration Guide

To learn how to connect your satellite to this orchestration layer, see Integrate with Shell.