Building Scalable Web Apps with Micro Frontend Architecture
Micro frontends apply the principles of microservices to the frontend. The approach promotes agility, scalability and allows the project team to deploy autonomously, thus enabling continuous delivery for web frontends.
What are micro frontends?
The trend is to build a powerful and feature-rich web application which resides on top of a microservice architecture. Over a period of time the frontend part of the application becomes huge and large, which is developed by a separate team and gets more difficult to maintain, this type of application is called Frontend Monolith.
Micro frontend is a microservice approach to frontend web development. The idea behind micro frontend is to decompose the web application into smaller units based on the screens representing domain-specific functionality instead of writing large monolithic frontend application.
Micro frontend application is a composition of features owned by different independent teams, where a team is cross-functional and has ability to develop end-to-end features, from the user interface to database. It gives the same level of flexibility, testability and velocity as of microservices.
Problems with Frontend Monolith
The flexibility promised by microservices cannot be scaled across the teams i.e. the backend team cannot deliver business value without the frontend being updated
There would be a classical overhead of a separate backend and frontend team, which would cause the entire frontend to be updated and re-tested for a change in the API of one of the services.
In a Single Page Application, all the files would be bundled into one and rendered on the browser, this file size would be huge.
As applications grow, so does the features that teams need to support. With multiple teams contributing to a monolithic application, development and release coordination is a tedious.
Newer frameworks and libraries offer considerable performance improvements and innovations on the front end space. However, the onerous task of upgrading a monolithic application and/or making it interoperate with these new frameworks and libraries often can’t be done without compromising the ability to ship new features at existing release rates.
Why Micro Frontend matters
As web browsers get increasingly powerful and frontend applications have started to handle more business logic than ever. In this kind of situation, many companies faced with scalability problems with their frontend applications as their frontend teams and business requirements grew. Since maintaining the monolith application is a costly business, developers started to search for different approaches to solve the bottleneck. The solution to the problem is micro frontend.
Benefits of Micro Frontends
The key advantages of a micro frontends architecture over a monolith are:
- Gives teams their release autonomy and time back
By breaking features from the monolith into separate micro frontends, teams enjoy increased autonomy and flexibility when releasing products/features. No longer are teams who aren’t releasing required to stay up late on release calls trying to regression test other teams’ changes in production. In other words, testing becomes simple as well as for every small change, you don’t have to go and touch entire application. - Self-Independent
The individual development team can choose their own technology, not having to rely on the entire codebase reduces dependencies and scope, enabling teams to onboard and deliver quickly. This creates room for time spent innovating without fear of breaking other teams’ features. - Highly scalable & better performing web-app
A loosely coupled architecture with established global standards makes it easier to add new features or spin up teams when needed. Since each app is fragmented into its own micro frontend, if a single feature (one micro frontend) on an enterprise app isn’t loading fast, it won’t affect the performance of the entire application. It also makes it possible for certain parts of a webpage to load faster, allowing users to interact with the page before all features are loaded or needed.
What are the techniques available?
Comparing server-side integration, build-time integration, run-time integration via iframes, and run-time integration via script.
1. Server-Side Integration
Moving on to the server-side integration this integration is our weapon of choice for anything dynamic that should also be served server-side rendered. This method will excel in perceived performance.
There are various ways of realizing server-side composed micro frontends. Using a layout engine such as podium we can quickly find a scaling approach without too much trouble. On the other hand, the dynamics of micro frontends may be difficult to tame with a central layout engine. Here, approaches such as using a reverse proxy could be more fruitful.
The challenge of using a reverse proxy is that the local development setup becomes rather complicated. Quite often, the only possibility of actually seeing the integration live is to deploy the micro frontend in question or to provide some hot loading capability for sustaining a local development environment.
The server-side integration works great for content-heavy sites. One example where this pattern shines is webshops.
PROS
- Best performance
- Dynamic loading
- SEO
CONS
- Framework integration
- Micro frontend isolation
- Development environment
Example of libraries & solutions:
2. Build-Time Integration
The presumably simplest, but most reliable integration is the build-time integration. Reliable in the sense that at build-time we know already how everything works and we can join the different pieces to get a single deliverable.
This kind of mechanism is as old as writing software is. In the end, quite often different pieces have been developed independently at different locations, just to arrive at a single point for final assembly. To say the least, automation is key here. The process is best when it just triggers autonomously when any piece changes.
For instance, when a single micro frontend changes, the whole application should just be rebuild. Since the number of micro frontends may grow indefinitely this can be a lot of stress on the build server. Even if not, constant refreshes of the whole application may prevent caching which forms the basis for great SPA performance.
The build-time integration works great in combination with server-side integration or for smaller applications where only some well-defined parts are outsourced. One possible solution here is to use Webpack with the module federation plugin.
PROS
- Type checking
- Runtime optimizations
- Easy for migration
CONS
- Dynamic loading
- Build times
- Orchestration
Example of libraries & solutions:
3. Run-Time Integration
3.1. Via iFrame
Joining micro frontends at runtime has many advantages, but comes at some non-negligible costs, too. Most runtime integrations require JavaScript and thus provide challenges on the SEO and accessibility site. While modern crawlers from Google use a powerful JavaScript engine (in fact they use a very recent version of Chrome to “see” the web), standard SEO rules still mandate quick response and rendering times. Runtime integrations quite often struggle here.
One exception is the inclusion of iframes. This can already be prepared on the server-side quite well, however, requires single elements including their purpose and area of use to be known centrally.
The best part about iframes is their isolation. This also beats alternatives such as shadow DOM or CSS modules as indeed nothing is shared with the hosting application. Since iframes come from a dynamic source their content can be server-side rendered, too. This is also necessary to some degree, as resources cannot be shared and need to be loaded multiple times.
The run-time integration via iframes works great for pages using third-party content, where strong isolation is required. This technique is already applied for ages. The first on-site PayPal integrations used it. Many chatbots and consent solutions use it. The reason is that the provided boundaries are just great to shield one application from another.
PROS
- Strong isolation
- Full flexibility
- Web-native
CONS
- No sharing possible
- Difficult to sustain great UX
- Worst performance
Example of libraries & solutions:
3.2. Via Script
For the run-time integration of micro frontends, a plugin mechanism can be utilised, too. This method has the advantage that everything could be built very easily choosing all the right parameters centrally. The central location is usually called the application shell, or abbreviated “app shell”. It loads the scripts and evaluates their content.
While some frameworks offer great control over the distributed API, others are only script loaders or basic routing engines. Nevertheless, pretty much all solutions in this space focus on developer experience.
This approach should not be underestimated. It can give great flexibility but comes at some costs. Interesting applications such as VS Code have been built using a plugin system, which proves that a combination of a powerful app shell that comes with the majority of the UI is as viable as a weak app shell that only orchestrates the different micro frontends.
Alternatively, the integration via script can also bring micro frontends in form of web components. While this approach does have some loyal followers, it also comes with additional challenges — mostly in the backward compatibility sector.
PROS
- Very dynamic
- Super flexible
- Best developer experience
CONS
- Weak isolation
- Requires JavaScript
- Efficient orchestration
Example of libraries & solutions:
Conclusion
As frontend codebases continue to get huge and more complex over the years, there is a growing need for more scalable architectures. We should be able to draw clear boundaries that establish the right levels of coupling and cohesion between technical and domain entities with the ability to scale software delivery across independent, autonomous teams.
While far from the only approach, there are many real-world cases where micro frontends deliver these benefits, and the technique is being gradually applied over time to legacy codebases as well as new ones. Whether micro frontends are the right approach for you and your organisation or not, we can only hope that this will be part of a continuing trend where frontend engineering and architecture is treated with the seriousness that we know it deserves.
