Enterprise case study · BridgeNext · logistics domain client
Logistics micro-frontend platform
React micro-frontends for a logistics product, composed at runtime with Module Federation so each domain ships without redeploying the whole application.
- Role
- Software Development Engineer · frontend
- When
- 2024 — present
- Links
- Confidential client work
- Host shell
- Module Federation
- Domain remotes
- Shared UI
The problem
Logistics workflows span several business domains that are built and integrated across teams. The frontend had to let those domains move independently while still feeling like a single product to the people using it.
What I did
- Delivered domain micro-frontends in React, TypeScript and Redux
- Built on a shared component library so independently deployed remotes look and behave consistently
- Introduced React Suspense and lazy loading at remote boundaries
- Worked on cross-team integration between the host and domain remotes
Architecture
- A host shell loads domain remotes at runtime through Module Federation
- Each remote owns its own Redux state; the shell owns layout and navigation
- Remotes are lazy-loaded behind Suspense boundaries, so a slow module shows a placeholder instead of blocking the shell
- Shared component library keeps UI consistent across teams
Key decisions
Runtime composition over a shared build
Module Federation lets a domain team release its remote without a coordinated release of the whole frontend — the main reason to split the UI at all.
Suspense at every federation boundary
A remote is a network dependency. Treating each one as lazy, with its own fallback, keeps the shell interactive when one domain is slow.
Stack
- React
- TypeScript
- Redux
- React Suspense
- Module Federation
- Vite
Client work under NDA — no code, screenshots or client names. The architecture and my role are described as they were.