Martin Fowler believed that every microservice model was once a monolith that got too big and had to be broken up into smaller components.
Well, it is easy to fall in love with the architectural beauty of the microservice model at the application level, but what if we do something similar at the frontend level?
As demand for feature-rich apps is increasing with time and the monolith model is gasping to match the pace, micro-frontend are starting to appear lucrative.
In 2016, the term micro-frontend was coined, which talked about the implementation of the microservice concept at the frontend level. As an app goes feature-rich, for example, a single-page app, the front end becomes too complex for one team to maintain.
IKEA, the famous European furniture seller, prefers splitting a system vertically to create self-contained systems for both the frontend and backend. They are of the belief that teams of 10–12 people work well, above that teams get less effective.
Micro-Frontends — What Does It Mean For Your Legacy App?
Micro-frontends are small, single-use apps all stringed together and connected with a single root application. This application would instantiate these small apps into divisions on the page as per the route. Moreover, these apps can be developed with any suitable and relevant technology, and thanks to sizes so small, upgrading them is not a hassle at all.
With every feature now being a greenfield, it is easy to transform and scale them. On the other hand, working legacy code could still be preserved within the same app as long as they do the job.
Let’s have a look at each of the benefits of following Micro-Frontend architecture
- Adding A New Feature Is Smooth
Monolith front-ends might be an obvious choice when you start afresh. It is easy to deploy new codes in such a small team, so why even think of a micro frontend model.
One thing that larger applications fear is “legacy”. Having legacy code or not being able to use the latest and greatest tools makes a software project doomed to failure. Micro-frontend architecture allows to build and add more features, while the impact on other features of the upgrade is minimal.
With decoupled code-bases and independence, you can literally appoint one project manager for each feature. Soundcloud used this model, they have product managers that are responsible for each feature.
- More Scope For New Technologies
With all the new features now being greenfield, you can now pick a tech stack you fancy, build a tool and make anything as perfect as you can.
Typescript, flow, or ESNext — use anything to make these brand new projects from scratch, while keeping the legacy code base intact.
- More Empowered Teams
Micro-frontends empowered teams by not only giving them autonomy but also the independence to try new technologies. Each team can try and test new features, approaches without stepping on the other team’s toes.
With autonomous micro-frontends, each team gets complete freedom to build and test the newest technologies in their fields.
Build a new feature one micro-frontend touching the rest of the codebase, without touching the rest of the codebase. Every micro-app has its own build process.
As Mezzalira from DAZN states, “Micro-frontends can really help an organization to move faster, innovate inside a business domain and isolate the failures.
Micro-frontends have empowered small teams at DAZN to work more independently.
- Decoupled Code-Bases Are Easier To Handle And Scale
The decoupled codebases get smaller and simpler to work with. You can minimize the difficulty arising from unnecessary and undesired coupling between components that don’t need communication.
By drawing thicker lines around the bounded contexts of the application, an accidental coupling can be avoided. It makes good decisions easy to take, and bad decisions hard. Micro-frontends compels us to be explicit about about what data and events should be communicated through different parts of the applications.
- Phased Updates
Micro-frontends prevent the inconvenience of the complete rewrite of the older code. Getting a feature delivered for production without touching the existing code is tempting. Sometimes the old code can’t be discarded, and a team might want to build new features to add to it.
With the front end comes more scope to make continuous updates to the existing architecture. Even if there is a major overhaul in the main framework, other frameworks will not require immediate changes.
What Does It Mean For The Users?
Since all the features are now isolated, one does not need to download the entire app to use one part of it. The Root app can load micro-apps quickly, meaning startup times are really faster.
Users can skip on to the feature they need to access without while the other feature is being loaded from the server.
Upwork migrated its website to Micro-frontend model in 2017, to improve its user experience. Sep Nasiri from Upwork accepted that adapting micro-frontend was challenging but benefits far outweigh that inconvenience.
Upwork used Micro-frontends to streamline services to deliver a consistent user experience to their global 17 million audiences.
Key Metrics Improvements
No matter how streamlined the backend is, there comes a time when the frontend will hit the bottleneck. The modular approach i.e. micro-frontend minimizes the impact of one feature upgrade on the rest of the codebase.
Here are some key metric improvements that the Micro-frontend model offers.
- Prefers native browser over custom APIs
The user experience offered by the web apps depends a lot on web browsers and APIs. Micro-frontends work with simpler browser events for communication which are much easier to manage and administer when compared with APIs.
Moreover, the quick rendering offers a great user experience despite the slow internet and sluggish browsers.
- Quicker Build Time
Parallel development is possible thanks to independent development and release cycles. It not only allows to build and deploy changes to micro-apps fastly but also keeps up with the current trends.
Performance Benefits
Delivering the code into smaller parts (per team, per micro-frontend) and not into one monolithic blob has the following benefits:
- Cacheability
Browsers only require to re-download the chunks of the code that are revised. Micro-frontends av re often utilized in conjunction with continuous delivery, where teams deploy to production multiple times in a day.
- Reduced long-running tasks
The main thread of the browser becomes unresponsive as it processes a JavaScript file. Loading multiple smaller files allows it more room to breathe and accept user input along with processing the JavaScript resources.
- On-demand loading
Since the assets are often clubbed by team or micro-frontend, it becomes easier to add only the code a page requires or implement route-based loading. For example, in an eCommerce website, the user doesn’t have to download the code for the cart page when one visits the homepage.
- Go-To Option for Medium-to-Large Projects
When the team size becomes larger than 10, it is wise to part the team into departments. Opting for a vertical micro-frontend style split is a good choice, a concept that lured Amazon once.
Many Amazon employees have reported that the company has leveraged the Micro-frontend architecture in tandem with UI integration technique.
Companies like IKEA, Zealando, and DAZN have employed this end-to-end approach at a larger scale.
Seamless Practices to Implement the Micro-Frontend:
Multiple single-page applications live at distinct URLs. In the case of shared functionality applications, use package managers: Bower or NPM components.
- The Single SPA meta-framework merges a multitude of frameworks on the same page without refreshing the page, such as Angular 1, Angular 2, React, Vue, etc.
- Distinct modules to communicate over a shared events bus. Each module functions on its framework, as long as it manages incoming and outgoing events.
- Separating Micro-apps into Iframes with the help of Windows. It shares APIs exposed by their parent window. Libraries and Post Message APIs to coordinate.
Pitfalls To Avoid With Micro-Frontend
- Micro-frontend is not for everyone. Jumping into it just because it is a hot new trend might backfire on you. If different departments in the team are using different frameworks, it might affect page performance.
- Right from source production, every micro-frontend should have a separate build and test pipeline. Every frontend should have a separate and independent CI/CD path, because that’s only how each part can be deployed independently, with zero interdependence.
- Test every frontend in the build and test pipeline, or you might leave a lot of scope for debugging later. Typescript is your buddy here.
- After decoupling codebases, it becomes easy for the team to work with autonomy, but that doesn’t nullify the need for cross-platform communication. Without knowing what is going on in other teams, overall product development becomes directionless.
The Bottom Line
In a nutshell, a micro-frontend framework aids cross-functional teams successfully. Also, it enables end-to-end development and deployment of individual micro-applications.
The micro-frontend architecture is efficacious in imparting organizational stability. Micro-frontend architecture is not a panacea for frontend scaling. The onus lies on the business leader to map requirements against the benefits of it.
