This content originally appeared on Bits and Pieces - Medium and was authored by Mike Chen
Explore build-time vs. runtime Micro Frontends and how Bit enhances code sharing, team autonomy, and consistency for scalable frontend development
Micro Frontends (MFEs) can be integrated using two primary approaches: build-time and runtime. These methods determine how independently developed parts of a frontend application are combined, either during the build process or at runtime. Selecting the right approach is essential to achieving a balance between team autonomy, application performance, and overall development complexity.
This blog delves into both integration strategies, with a special focus on Bit — a tool that simplifies code sharing in poly-repo setups for both runtime and build-time integrations. For organizations favoring build-time MFEs, Bit offers a unique advantage by enabling team independence while maintaining consistent standards across the application, ensuring seamless collaboration without sacrificing uniformity.
Why Microfrontends?
Microfrontends are all about:
- Polyglot Architectures: Teams can use whatever tech fits their needs
- Team Independence: Teams can develop, test, and deploy their part of the app without stepping on each other’s toes.
While the first reason does exist, mainly with enterprises integrating legacy code into modern apps, in most cases it’s about working better together.
It’s also worth noting that MFEs don’t provide the same kind of performance boost that their backend counterparts, microservices, do. MFEs, eventually, run on a single machine while microservices share computation resources across multiple machines.
In many cases, the performance improvements, primarily load time, that MFEs promise can be achieved by code-splitting a traditional monolithic frontend application. This approach avoids the added complexity of MFEs while still optimizing load times and resource use.
Team independence
Team independence is closely tied to the development strategy chosen by an organization.
Developers often mistakenly assume that build-time integration necessitates a monorepo, while runtime integration is implemented by maintaining Micro Frontends (MFEs) in separate repositories (polyrepo), as runtime is perceived to enable looser coupling.
In practice, this assumption is often reversed. Runtime MFEs are commonly developed within a monorepo, facilitating easier code sharing across teams. On the other hand, build-time MFEs are frequently managed as Bit components, enabling them to be developed in a polyrepo setup — or even without a dedicated repository.
JavaScript Monorepos: Exploring Decentralized Alternatives
Run-Time Integration of MFEs
Run-time integration of micro frontends refers to a technique where independently developed micro frontend applications are combined and rendered together during the execution of the application, rather than being compiled or bundled together at build time.
This approach is often implemented using Module Federation, Piral or Single-SPA. However, simpler “native” solutions like iframe embedding and dynamic loading of ES Modules, also qualify as such.
Why runtime integration is great:
- Dynamic Updates: Update one part without touching the rest.
- Polyglot Friendly: Use different tools and languages.
- Loose Coupling: Teams work independently with little coordination.
What’s Tricky:
- Performance Hits: Loading at runtime can slow things down.
- Debugging Woes: Fixing runtime issues can be tough.
- Version Conflicts: Dependencies might not play nice.
Demo app
- Deployed app — A runtime integration of MFEs using Bit + Module Federation.
- Bit scopes — ‘BitBazzar’ organization on the Bit Platform with separate access-controlled scopes for Bit components maintained by different teams: MFE teams, the design team, and the shell-app or infra team.
- Github repositories- ‘BitBazzar’ organization on Github. The shared design components, the “store” MFE, the “blog” MFE, and the shell application are all maintained in separate repositories, deployed independently and integrated at run-time.
Build-Time Integration of MFEs
Build-time integration of micro frontends refers to the approach where independently developed micro frontend applications are assembled into a single cohesive application during the build process. This means that the integration happens before the application is deployed, and the final application is built as a single unit.
While this can be achieved by any integration of separately maintained packages, the most common tool being used is Bit, with the help of Bit’s CI for components “Ripple CI”.
Bit enables build-time integration for micro frontends using a new entity, the Bit component. Bit components can be thought of as super-packages. They can be installed and used in any project but can also be updated and versioned independently of any specific repository or build setup.
Bit components are complemented by a build system that propagates changes from modified components to their dependent components, all the way to the “app component”, a deployable Bit component (i.e, the app).
Why It’s Great:
- Better Performance: Optimized builds mean faster apps.
- Consistency: Shared dependencies keep everything smooth.
- Scalability: Modular design lets you grow easily.
What’s Tricky:
- Coordination Needed: Teams need to stay in sync.
- Build Delays: Updates require rebuilding.
Demo app
- Deployed app — A build-time integration of MFEs using Bit and Ripple CI
- Bit scopes — ‘Cosmos Cruises’ organization on the Bit Platform with separate access-controlled scopes for Bit components maintained by different teams: MFE teams, the design team, and the shell-app or infra team.
Distributed MFEs face unique hurdles. Here’s how Bit helps.
- Streamlined Code Reuse: Fragmented repositories often lead to redundant code and inconsistent designs. Bit’s components act as single-source of truth entities that teams can reuse across projects. By hosting them in centralized scopes, duplication disappears, and UI/UX remains consistent.
- Unified Development Standards: Teams using different tools and configurations can create inefficiencies. Bit’s reusable environments enforce consistent standards across projects. Shared tools and settings (like webpack, eslint, jest) ensure that every component adheres to the same build and test requirements.
- Efficient Dependency Management: Conflicting dependency versions can bloat bundles and cause runtime errors. Bit’s reusable environments and dependency graphs standardize dependencies, preventing duplication. Ripple CI automates checks and updates, ensuring compatibility across projects.
- Centralized State and Communication: Teams often adopt varied approaches to routing, state management, and communication, complicating integration. Build-time integration centralizes global state and shared services. Bit enables wrapping isolated components in shared contexts for features like authentication and theming.
- Seamless Local Development and Testing: Testing MFEs in isolation can overlook integration issues, while monolithic setups hinder team independence. Bit allows teams to develop and test components in isolation while previewing them within the shell application.
Conclusion
Micro Frontends offer an effective way to scale frontend development across multiple teams, but the choice between build-time and runtime integration depends on your organization’s priorities and constraints.
Build-time integration provides consistency, better performance, and streamlined dependency management, making it an ideal choice for teams prioritizing efficiency and shared standards. On the other hand, runtime integration excels in enabling team independence, dynamic updates, and polyglot flexibility, catering to organizations with highly autonomous teams or diverse tech stacks.
Both approaches come with trade-offs in terms of complexity, coordination, and debugging challenges. The key is to assess your team’s workflow, the nature of your application, and long-term goals. Tools like Bit make either approach more manageable by addressing common hurdles, such as dependency conflicts, code reuse, and standardized development environments.
Ultimately, the decision isn’t about which approach is inherently better, but about which one aligns with your team’s structure and project needs. Whether you’re assembling components at build time or weaving them together dynamically at runtime, the right strategy will empower your teams to innovate and deliver seamless user experiences.
Micro Frontends: Build-Time vs. Runtime 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 Mike Chen
Mike Chen | Sciencx (2024-12-23T18:41:29+00:00) Micro Frontends: Build-Time vs. Runtime Integration. Retrieved from https://www.scien.cx/2024/12/23/micro-frontends-build-time-vs-runtime-integration/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.