Micro-frontends in one portalPARTNER PORTAL · MATERIAL UI SHELL
Team moduleMicro-frontend
IdentityMine · Shadow DOM
Team moduleMicro-frontend
↓ Rendered by the host with Module Federation · data from the host ↓
Illustration of the architecture, not a product screenshot Micro-frontends in the partner portal
The partner portal brings micro-frontends from different teams into one shared place, using Module Federation. Our team owned the identity-provider workflows. I built them as React and Vite micro-frontends that render inside the host app and get their data from it.
They run inside the existing portal without clashing with its Material UI styles.
How I kept them isolated
The portal shell uses Material UI, and global styles can leak between the shell and a new module. I rendered the micro-frontends inside Shadow DOM, so each side keeps its own styles.
Module Federation let each module ship on its own release path while customers still see one portal.
Moving to the shared libraryMaterial UI modulesExisting screens
Compatibility layerThe abstraction I built
shadcn/ui libraryShared components
Simplified overview Moving from Material UI to shadcn/ui
The portal's React modules were built with Material UI, and the platform was moving to a shared UI library based on shadcn/ui. I created the abstraction that converts those modules to the new library.
Modules could adopt the shared library and stay compatible with the existing portal.
What I had to keep working
The parent portal kept using Material UI during the change. I extended the micro-frontend model to support the shared library, so converted modules still fit inside it.
Moving where the code livesAzure DevOpsBefore
→GitHubAfter
Repositories & deliveryDocumented rules
Simplified overview, not a timeline Moving delivery from Azure DevOps to GitHub
The platform's repositories and delivery workflows lived in Azure DevOps. I designed the migration to GitHub on my own and carried it out, keeping the existing micro-frontend model.
Existing users kept working without noticing the change, on a more stable platform.
What I documented along the way
I set up a repository with the project rules, business rules and guidance for moving the platform between environments. People and AI-assisted tools could work from the same written rules.
From modules to servicesReact micro-frontendsPartner portal
↕
npm packagesAPI fetching · shared behavior
↕
Backend servicesC# · NuGet packages
Simplified overview Connecting the modules to the backend
The React micro-frontends depended on backend services written in C#. I wrote reusable npm and NuGet packages for API fetching and shared platform behavior.
Where C# comes in
The npm packages gave the React modules a stable way to fetch from the API. The NuGet packages kept the matching contracts aligned on the C# side.
My main work was on the frontend; the NuGet side kept the C# services in step with it.