This content originally appeared on Bits and Pieces - Medium and was authored by Ashan Fernando
Insights into scaling Micfrontends and how composable architectures can help
Imagine you’re leading a growing team of developers working on a massive web application. Suppose it's a monolithic front that has become increasingly difficult to manage, slowing down development and creating bottlenecks. You decide to transition to a micro frontend (MFE) architecture to solve these challenges. Time passes, and now some micro frontends are also getting difficult to manage.
But how do you scale these micro frontends effectively? Let’s explore the journey of scaling micro frontends through practical strategies, best practices, and efficient DevOps.
1. Continous Evaluation: Assessing the Current Architecture
You don’t want to end up with multiple micro frontends at their breaking point of scaling and go through the same journey of breaking the monolith, which is costly.
Instead, it's advisable to continuously asses the micro frontend architecture of its limits and take necessary actions to break it down whenever necessary.
The first step in this transformation is to set up the metrics that you can evaluate to see whether your MFE reaches its breaking point. And it's worth choosing a standard set of matrices that have proven to work for many applications. One such tool is the DORA Metrics.
2. Setting up the Thresholds: Stepping into DORA Metrics
DevOps Research and Assessment (DORA) metrics provide a standard for measuring DevOps performance. These metrics focus on:
- Deployment Frequency: How often code is deployed.
- Lead Time for Changes: Time taken from code commit to deployment.
- Change Failure Rate: The percentage of deployments causing production failures.
- Time to Restore Service: The time taken to recover from a failure in production.
Since each micro frontend team is fully autonomous and manages the end-to-end delivery, each team can start by continuously tracking these metrics.
If your micro frontend follows a composable architecture, you can refer to the following article to extend it for composable micro frontends.
Extending DORA Metrics for Composable Software
However, you have to determine the thresholds when breaking down the MFE since the values depend on the application's nature, development teams, and other business factors.
3. Formulate the Plan: Break or Merge
Once we find the candidate MFEs, it's important to find out whether there are any meaningful units to break the MFE further into multiple teams and if there are any parts where the responsibility can be given to a different team.
These units should be independent enough to be developed in isolation but cohesive enough to provide specific functionality.
After evaluating the MFE's complexity, dependencies, and interaction with other parts of the application, it's possible to set the plan and key milestones for the migration.
This approach is similar to the one used to transition from the monolith to MFEs but at a much smaller scale.
This involves setting up a timeline, defining milestones, and ensuring the transition does not disrupt ongoing development.
The plan should include:
- Incremental refactoring: Gradually refactor parts of the application into MFEs, ensuring that the transformation is smooth and manageable.
- Ensuring feature parity: Maintain existing functionality during the transition to avoid disrupting the user experience.
- Maintaining user experience consistency: Ensure the transition is seamless and does not affect the end-user experience.
4. Execute the Plan: Follow the Best Practices for Seamless Transition
The next step is to execute the plan. When you start the transition, there are several best practices to make the overall process effective. These include;
- Start small: To minimize risk, begin with less critical parts of the large micro frontend.
- Use a strangler pattern: Gradually replace parts of the microfrontend with the new MFE.
- Emphasize communication: Though your main MFE team can plan the transition, it's worth identifying the future team structure and ownership for a seamless transition.
- Invest in automation: Automate as much as possible, from testing to deployment, to ensure a smooth transition.
As you have seen, scaling micro frontends requires careful planning and may come sooner than you think. Therefore, laying a solid foundation for scaling while transitioning from monolith to micro frontends is important.
Laying the Foundation for MFEs: Using Composable Architecture
When following composable architecture, each MFE owns a collection of independent components. These components are self-contained and can be reorganized depending on the governance structure. Therefore, it's possible to reorganize the ownership of components from one MFE to another with minimal effort.
In addition to that, composable architecture provides the following benefits.
Building with Reusable Components
One of the cornerstones of a scalable microfrontend architecture is building each MFE with reusable components. These components should be designed to be independent and reusable across different application parts.
For instance, you can start with the design system, typically owned by the design team.
The same concept can be extended to the components within the micro frontends. You can also create the MFE as a collection of components.
When creating micro frontends with components, follow composable architecture patterns to make it easy to re-organize your MFEs in the long run.
Maintaining a Dependency Graph
A clear dependency graph of all the components in a micro frontend helps to determine the new boundaries and potential conflicts for breaking it in the future.
Using a tool to visualize these dependencies makes the entire planning highly effective.
Develop Components in Isolation
If the development cycle of the components in your MFE is coupled with the runtime of the MFE, it becomes difficult to divide it in the future.
Instead, use a tool that helps manage each component's development independent from the MFE. The tool should be able to render each component separately to develop, test, and visualize its look and feel.
For example, if you use Bit, you can run the Bit development server to develop each component in isolation.
Keep the Core Framework/Library Dependency Versions Consistent
Another important step to help scale micro frontends in the future is to keep the core frameworks and libraries consistent across MFEs, reducing compatibility issues.
To do that effectively, you can use peer dependencies for these libraries and frameworks so that all the MFEs depend on the version provided by the application's core.
For more information, refer to the following article.
How to Handle Dependencies in Microfrontends
Learn More
- How to Migrate Your Existing Application to Micro Frontend Architecture
- How we Build a Component Design System
- Monorepo, Poly-repo, or No Repo at all?
- Building a Host Application for Your Micro Frontends
Scaling Microfrontends: Every Developer Should Know 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 Ashan Fernando
Ashan Fernando | Sciencx (2024-07-29T11:16:15+00:00) Scaling Microfrontends: Every Developer Should Know. Retrieved from https://www.scien.cx/2024/07/29/scaling-microfrontends-every-developer-should-know/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.