Micro Frontend is one of the most notable trends in the Frontend world in the last year. The idea is still relatively new but it’s getting traction and has the potential to become a real game-changer. This architecture is being adopted by an increasing number of companies, including Netflix and Soundcloud.
In this blog post, I will share my experience with Micro Frontends and provide you with various practical approaches to implement Micro Frontends into your application. This is by no means a complete guide to micro frontends but rather a concise introduction to the most common patterns.
What is Micro Frontend?
In recent years, Single Page Applications became dominant in the modern Web world and with this, more and more logic was moved from the server to the client (like routing). While the Backend world was switching to Microservices, the Frontend world remained largely monolithic. The complexity quickly increased and scalability and maintainability became a real problem. The other issue was the fact that it became increasingly hard to distribute the work across different teams without any interference and bottlenecks. Last but not least, with the monolithic approach, the whole Frontend application must stick to one specific technology which is not always the preferred option. Micro Frontend architecture has an answer to all of these issues.
Micro Frontend is an architectural pattern which allows the Frontend to be composed by smaller decoupled applications which are eventually assembled into a whole.
Think of it as Microservices for UI. Let’s imagine that we have a large e-commerce app, in which, aside from the main functionality, we also have blog posts and dynamic navigation. On the front page, there is navigation, on the top, and lists of promotional products and recent blog posts below.
We can split the Frontend into 3 main teams – Navigation, Store and Blog. Besides showing the promotional products, the Store team is responsible for all the UIs related to the products – list pages, single product pages etc. The Content team is responsible for all the info pages, blog posts etc. The navigation team – well, it’s pretty self-explanatory. In an ideal scenario, each of these teams will use different build piplenes and each piece will be tested and deployed independently. At the end, all the pieces will be assembled into an fully working app.
Common approaches for implementing Micro Frontends
After we have discussed the “Why” and the “What” of the Micro Frontends topic, let’s talk about the “How”. Below, I’ve listed the most common approaches to implementing Micro Frontend at this moment. It’s important to note that all of these solutions would work regardless of the technology – they are all framework agnostic. Unlike the monoliths, you can have one microfrontend using React and another using Vue without any problems for the whole application. Let’s explore the possible implementation patterns:
This is probably the easiest way to put together different applications in a single view. However, IFrames are not very SEO-friendly and there might be issues with styling, like for example the use of “position:fixed”. I think there are much better alternatives below.
Web Components API
By representing each piece into as Custom Element you can ensure encapsulation and reusability of each component. The page can be assembled without the use of any third-party tool. This approach is relatively easy to implement but as with IFrames, there are some limitations – the Web Components is still not widely supported by all the browsers and managing shared dependencies can be cumbersome. You can read more about the Web Components here.
Edge Side Includes(ESI)
Edge Side Includes is a mark-up language which allows different fragments to be assembled into a whole. Below you will find a short example:
As you probably think, this can’t be read by the browser, thus it requires a special server which can parse it and transform it into a real HTML. The most common tools used for this purpose are CDN servers like Varnish, Cloudflare, Squid etc. The assembly takes place on the caching server instead the client, as in most of the other patterns. This approach relatively simple to implement but lacks flexability. You can read more about Edge Side Includes here.
Probably the most popular solution. The composition happens on the client, which make it relatively easy to implement. The main idea behind single-spa is the separation of all the microfrontends into a different ES modules and a root-module which contains all the logic regarding the mounting/unmounting of the different microfrontends depending on the routing/configuration. If you are interested in Micro Frontends, I strongly recommend this approach, as it’s easy to grasp and scales well. Also, single-spa has a nice ecosystem of libraries which are well maintainted. If you are curious, you check out its documentation.
Webpack module federation
This is quite new and neat feature of Webpack. It allows application to dynamically import code from another application at runtime and, by leveraging Webpack’s bundling capabilities, optimizes all dependencies. You can read more about Webpack module federation here.
Bit is a sophisticated paid end-to-end solution for Micro Frontends. It provides the capability to host multiple components on a shared cloud where each component can be maintained, tested and deployed autonomously. Most importantly, Bit provides way to assemble all the components into whole. You can learn more about Bit here.
If you are considering switching to Micro Frontend, I would recommend trying different approaches first until you find what fits your needs. Nowadays, there is enough information online and a lot of companies have shared their experience with microfrontends. In another blog post, I will discuss the pros and cons of Micro Frontends, so make sure you check this one out too.