abhinav-paliwal_author.jpg

Abhinav Paliwal

<p>Microservices have revolutionized the way we develop modern apps. And that’s primarily because of the huge advantage they bring along: Innovate faster by breaking down large products or projects into smaller, manageable pieces that you can move, update, or replace quickly. We have built our award-winning products based on this approach, and it has helped us scale incredibly fast. </p>
<p>That’s the story of our backend. </p>
<p>Our frontend, however, until some time ago, was still monolithic. We wanted to take a similar approach for our frontend to get the benefits of “microservices” there. This approach is called a “micro-frontend.” </p>
<p>In the last few months, we tried and tested a few methods, and finally, we successfully implemented a micro-frontend for our application. We learned quite a few crucial lessons in the process. This blog is about these lessons. It’s not a theoretical introduction to micro-frontend nor a definitive guide to implementing it. It’s more about our journey of building micro-fronted for our applications, some lessons we learned, and sample code to help you build yours.  </p><h2>Why We Chose Micro-Frontend</h2>
<p>A single, unified frontend works well until your app is catering to only a handful of customers. As you grow and start adding more capabilities, the inflexibility of a single, large frontend starts to throttle the pace of your delivery. </p>
<p>We have broken down our product into several sub-domains, with each one being developed and owned by separate teams. When the different codebases from all these teams came together into a single application, there were natural consequences:</p><ul><li>All the teams had to sync often on deployment and testing</li><li>Releases needed to be coordinated across the different teams and their schedules</li><li>Merge conflicts occurred frequently</li></ul>
<p>It was not an efficient approach and certainly not scalable. Dividing the frontend into smaller apps was the need of the hour. </p><h2>The Approach</h2>
<p>There are several ways to build micro-frontends. We did some initial research and found the following two ways to be more suitable for our requirements: </p><ul><li>Iframes</li><li>Approach as defined in <a href="https://micro-frontends.org/" target="_blank">https://micro-frontends.org/</a></li></ul>
<p>We tried the “iframes” approach initially. It was, however, not a very effective approach, as it has issues related to security, usability, and SEO. However, it helped us bootstrap a repository and get the micro-frontend on the screen to start development.</p>
<p>The second approach, as suggested by <a href="https://micro-frontends.org/" target="_blank">micro-frontends.org</a>, was interesting because it leverages <a href="https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements" target="_blank">custom DOM elements</a>. While the approach is well thought out, we realized that it could be overkill for us since we don’t use multiple frameworks — we use ReactJS across projects — and we don’t have many use cases for out-of-the-frame rendered components.</p>
<p>Later, we came across the blog: <a href="https://medium.com/better-programming/5-steps-to-turn-a-random-react-application-into-a-micro-frontend-946718c147e7" target="_blank">5 Steps to Turn a Random React Application Into a Micro Front-End</a>. It suggests a few methods to help implement a micro-frontend the way we wanted, and they eventually became the base for our implementation. Let’s look at the methods in detail. </p><h2>The Implementation</h2>
<p>As defined in the blog, the basic implementation includes using a dynamic <strong>script</strong> tag to load the micro-frontend JavaScript on the page. Once loaded, the container calls a method on the <strong>window </strong>object. The micro-frontend provides this method to start the rendering process. The micro-frontend renders to a <strong>div</strong> as exposed by the container. Eventually, you get a setup that looks like the illustration below.</p><p style="margin: auto; text-align: center;"><img data-image="0jbubok77ntz" src="https://images.contentstack.io/v3/assets/bltc5a09bf374882538/blt9458632cc9389fda/60d0ff42b930a53616fa435f/container-app-render-sections.png" data-sys-asset-uid="blt9458632cc9389fda" alt="container-app-render-sections.png"></p>
<p>The container app renders sections in <strong>green</strong>, and the section in <strong>blue</strong> is the micro-frontend.</p><h2>Challenges with rendering outside the micro-frontend — and the solution</h2>
<p>While the initial success using the above approach was quite encouraging, it was short-lived. We faced a significant challenge, and we quickly realized that our implementation needed to be slightly different:</p><p style="margin: auto; text-align: center;"><img data-image="h23bm5k99vpv" src="https://images.contentstack.io/v3/assets/bltc5a09bf374882538/blt0de30e93d4bb85d5/60d0ff56ae0d50495b4f8804/render-components-sourced-from-micro-frontend.png" data-sys-asset-uid="blt0de30e93d4bb85d5" alt="render-components-sourced-from-micro-frontend.png"></p>
<p>As you can see in the illustration above, the micro-frontend also needed to render a few components outside its DOM hierarchy. The left navigation bar and the top header need to render certain buttons, icons, and other components sourced from the micro-frontend.</p>
<p>After some basic troubleshooting, we realized that we could use the <a href="https://reactjs.org/docs/portals.html" target="_blank">React Portals API</a> to solve this. This API allows you to render components outside the DOM tree where the micro-frontend is rendered. Using some well-known div IDs, we were able to expose an API where the micro-frontend can control these sections in the UI.</p>
<p>Another challenge was to have a seamless routing experience when the micro-frontend wanted to change routes. Managing this became a little easier since we are creating a single-page application (SPA) with HTML 5 pushState API. When initializing the micro-frontend, we could pass the history object, which the micro-frontend can then use. Also, we used relative routes, so it worked without a hitch.</p><h2>Challenges With Rendering Outside the Micro-Frontend — and the Solution</h2>
<p>One unfortunate side effect to having independent micro-frontends is the relative size of each micro-frontend JavaScript bundle. Nowadays, loading an average ReactJS app and all the standard libraries consumes several megabytes of bandwidth. By implementing micro-frontends, we were going to multiply this with the number of micro-frontends in use.</p>
<p>Some of the libraries that we use (such as React, Redux, Redux-Saga) are common among all the micro-frontends we have built. So, it did not make sense to download these common libraries for each micro-frontend. Instead, a better approach would be to bundle them together so you could download them only once.  We achieved this using <a href="https://webpack.js.org/plugins/dll-plugin/" target="_blank">dll-plugin</a>, a library for Webpack. It allows us to bundle the common libraries into a “DLL” (Dynamically-Linked-Library) that you can dynamically load within a webpack project. By using the DLL plugin, we achieved a significant 60% reduction in our bundle size.</p><h2>Summary </h2>
<p>Our application’s new user interface and some of our new incubation projects now have micro-frontends implemented, based on the approach given above. And all these apps have been working smoothly. We can roll out more changes quickly with less dependency on other teams, so  deployment and scaling become more manageable. </p>
<p>If you want the details of this approach, check out <a href="https://github.com/contentstack/micro-frontend-example" target="_blank">our micro-frontend example (with code) on GitHub</a>. </p><br>

Microservices have revolutionized the way we develop modern apps. And that’s primarily because of the huge advantage they bring along: Innovate faster by breaking down large products or projects into smaller, manageable pieces that you can move, update, or replace quickly. We have built our award-winning products based on this approach, and it has helped us scale incredibly fast.

Our frontend, however, until some time ago, was still monolithic. We wanted to take a similar approach for our frontend to get the benefits of “microservices” there. This approach is called a “micro-frontend.”

In the last few months, we tried and tested a few methods, and finally, we successfully implemented a micro-frontend for our application. We learned quite a few crucial lessons in the process. This blog is about these lessons. It’s not a theoretical introduction to micro-frontend nor a definitive guide to implementing it. It’s more about our journey of building micro-fronted for our applications, some lessons we learned, and sample code to help you build yours.

A single, unified frontend works well until your app is catering to only a handful of customers. As you grow and start adding more capabilities, the inflexibility of a single, large frontend starts to throttle the pace of your delivery.

We have broken down our product into several sub-domains, with each one being developed and owned by separate teams. When the different codebases from all these teams came together into a single application, there were natural consequences:

It was not an efficient approach and certainly not scalable. Dividing the frontend into smaller apps was the need of the hour.

There are several ways to build micro-frontends. We did some initial research and found the following two ways to be more suitable for our requirements:

We tried the “iframes” approach initially. It was, however, not a very effective approach, as it has issues related to security, usability, and SEO. However, it helped us bootstrap a repository and get the micro-frontend on the screen to start development.

. While the approach is well thought out, we realized that it could be overkill for us since we don’t use multiple frameworks — we use ReactJS across projects — and we don’t have many use cases for out-of-the-frame rendered components.

. It suggests a few methods to help implement a micro-frontend the way we wanted, and they eventually became the base for our implementation. Let’s look at the methods in detail.

As defined in the blog, the basic implementation includes using a dynamic 

 tag to load the micro-frontend JavaScript on the page. Once loaded, the container calls a method on the 

object. The micro-frontend provides this method to start the rendering process. The micro-frontend renders to a 

 as exposed by the container. Eventually, you get a setup that looks like the illustration below.

Challenges with rendering outside the micro-frontend — and the solution

While the initial success using the above approach was quite encouraging, it was short-lived. We faced a significant challenge, and we quickly realized that our implementation needed to be slightly different:

As you can see in the illustration above, the micro-frontend also needed to render a few components outside its DOM hierarchy. The left navigation bar and the top header need to render certain buttons, icons, and other components sourced from the micro-frontend.

After some basic troubleshooting, we realized that we could use the 

 to solve this. This API allows you to render components outside the DOM tree where the micro-frontend is rendered. Using some well-known div IDs, we were able to expose an API where the micro-frontend can control these sections in the UI.

Another challenge was to have a seamless routing experience when the micro-frontend wanted to change routes. Managing this became a little easier since we are creating a single-page application (SPA) with HTML 5 pushState API. When initializing the micro-frontend, we could pass the history object, which the micro-frontend can then use. Also, we used relative routes, so it worked without a hitch.

Challenges With Rendering Outside the Micro-Frontend — and the Solution

One unfortunate side effect to having independent micro-frontends is the relative size of each micro-frontend JavaScript bundle. Nowadays, loading an average ReactJS app and all the standard libraries consumes several megabytes of bandwidth. By implementing micro-frontends, we were going to multiply this with the number of micro-frontends in use.

Some of the libraries that we use (such as React, Redux, Redux-Saga) are common among all the micro-frontends we have built. So, it did not make sense to download these common libraries for each micro-frontend. Instead, a better approach would be to bundle them together so you could download them only once. We achieved this using 

, a library for Webpack. It allows us to bundle the common libraries into a “DLL” (Dynamically-Linked-Library) that you can dynamically load within a webpack project. By using the DLL plugin, we achieved a significant 60% reduction in our bundle size.

Our application’s new user interface and some of our new incubation projects now have micro-frontends implemented, based on the approach given above. And all these apps have been working smoothly. We can roll out more changes quickly with less dependency on other teams, so deployment and scaling become more manageable.

If you want the details of this approach, check out 

Abhinav Paliwal

Posts by Abhinav Paliwal