This content originally appeared on Bits and Pieces - Medium and was authored by Eden Ella
Enhance micro frontend development with build-time integration, ensuring stability, performance, and efficient team collaboration using Bit.
Often, a runtime integration of micro frontends (MFEs) is preferred over build-time integration, not necessarily because it delivers a better experience for end users but because it enables faster builds and smoother collaboration between teams. With runtime integration, team autonomy reaches new heights — MFEs are developed, built, and deployed independently. In many cases, they are even version-controlled in separate repositories.
However, runtime integration has notable drawbacks. It is more prone to inconsistencies in UX, integration issues, and often results in suboptimal performance. Build-time integration, on the other hand, enables thorough end-to-end testing, reducing the likelihood of bugs in production. It simplifies dependency management, reducing overall bundle size, avoiding version conflicts, and ensuring a consistent UX across the application.
While there are valid reasons to choose runtime integration — such as polyglot codebases and legacy code — many of these challenges can be addressed using a well-architected build-time integration approach. However, those considerations are beyond the scope of this blog.
In this article, we’ll focus on implementing a build-time MFE using Bit to achieve the best of both worlds: enabling smooth collaboration between independent teams while delivering a performant, robust, and consistent application.
Implementing a Build-Time MFE Integration with Bit
Bit can be adopted in various ways. Some teams use Bit as a single solution for their entire development workflow, bypassing Git repositories altogether and maintaining their applications as deployable Bit components.
However, since most Bit users integrate Bit into their existing workflows and tools, we will follow that approach in this example.
Our demo solution is a single-page application for space travel, built with Vite and React, maintained in a Git repository. It integrates two Micro Frontends, ‘Marketing’ and ‘Booking,’ each managed in its own Git repository and Bit scope.
1. Creating the Bit Scopes and Git Repositories to Host Our Solution
We start by creating Bit scopes and setting up Git repositories for the micro frontends, their shared UI library, and the code that integrates them into a cohesive application.
- Foundation: Components that orchestrate and integrate MFEs
- Design: UI components that are shared across the MFEs for UI/UX consistency
- Booking: Components used for the composition of the booking MFE (including the booking MFE component)
- Marketing: Components used for the composition of the marketing MFE (including the marketing MFE component)
As previously mentioned, the app shell in this demo is not maintained as a Bit component but as a standalone application, meaning it is not hosted in a Bit scope.
Bit scopes, hosted on the Bit Platform, come with access control features. In this setup, each scope corresponds to a single repository, along with its associated roles and permissions. However, this isn’t always the case — a single repository can house Bit components from multiple scopes.
2. Creating the App Shell and Components That Integrate Our Solution
The app shell is responsible for orchestrating the MFEs and providing shared dependencies. In this demo, the app shell is implemented as two separate pieces:
A “subscriber” (Bit) component defines how MFEs in that system should be implemented and provides the API for them to register into the system. The subscriber or container implements the shared context for the MFEs (app theme, app layout, global state, shared actions, etc).
/**
* Subscriber
*/
// ...
export class App {
// ...
registerRoutes(routes: RouteType[]) {
this.routes.push(...routes);
}
registerHeaderLinks(headerLinks: HeaderLink[]) {
this.headerLinks.push(...headerLinks);
}
listRoutes() {
return this.routes;
}
listHeaderLinks() {
return this.headerLinks;
}
renderApp() {
return (
<Theme>
<Header links={this.listHeaderLinks()} />
<Routes>
{this.listRoutes().map((route) => (
<Route
key={route.path}
path={route.path}
element={route.element}
/>
))}
</Routes>
</Theme>
);
}
}
A (non-Bit) application defines which MFEs should be part of the application, as well as how the app should be built and deployed.
The app is agnostic to the way MFEs are integrated. It only consumes the MFEs and executes the registration and rendering as the subscriber component defines it.
/**
* Application
*/
import { createRoot } from 'react-dom/client';
import { App, Frontend } from '@cosmo-flux/foundation.subscriber';
import { marketingMfe } from '@cosmo-flux/marketing.marketing-mfe';
import { bookingMfe } from '@cosmo-flux/booking.booking-mfe';
const app = new App();
const frontends: Frontend[] = [marketingMfe, bookingMfe];
frontends.forEach((frontend) => frontend(app));
createRoot(document.getElementById('root')!).render(
<>{app.renderApp()}</>
);
3. Implementing the MFEs
Use the proper Bit template to generate the boilerplate for your MFE components, or use Bit’s Hope AI to generate the necessary components.
The important thing is to implement the Frontend type as it is defined by the component responsible for the integration of MFES (the subscriber). As you can see, in order to keep the MFE teams as independent as possible, we implement an inversion of control using dependency injection.
An MFE determines how it integrates into the system and which shared functionalities and states it uses (notifications, user info, etc).
For example, the Booking MFE registers the Red Planet Reservations page into the app.
/**
* Booking Micro Frontend
*/
import type { Frontend } from '@cosmo-flux/foundation.subscriber';
import { RedPlanetReservations } from '@cosmo-flux/booking.pages.red-planet-reservations';
export const bookingMfe: Frontend = (app) => {
app.registerRoutes([
{
path: '/reservations',
element: <RedPlanetReservations />,
},
]);
app.registerHeaderLinks([
{
label: 'Reservations',
path: '/reservations',
},
]);
return app;
};
Since both the MFE and the page are Bit components, they are consumed using their package name (as you can see in the previous example, the application shell project uses the booking MFE as a regular package).
4. Create a Webhook to Trigger the App Shell CI/CD When an MFE Version is Released
To replicate the seamless developer experience and smooth collaboration seen in runtime MFE setups, we can leverage Bit Platform to configure a webhook that automatically triggers the shell application's build and (possibly) deployment whenever a new stable MFE version is released.
Using Bit Webhooks in Composable Software: 5 Use Cases
This approach empowers MFE teams to deploy their applications independently without relying on other teams.
While automating the build and deployment process may seem risky at first, when implemented correctly, it is arguably safer than the conventional runtime integrations we commonly accept.
Build-time integration enables comprehensive end-to-end testing and automated verifications, ensuring that failures occur during the build process rather than at runtime.
Micro Frontends: Achieving Full Team Autonomy with Build-Time Integration was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Eden Ella
Eden Ella | Sciencx (2025-02-12T23:39:57+00:00) Micro Frontends: Achieving Full Team Autonomy with Build-Time Integration. Retrieved from https://www.scien.cx/2025/02/12/micro-frontends-achieving-full-team-autonomy-with-build-time-integration/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.