Building a Better Micro-Frontend Framework That Enables Platform Freedom

Hello everyone, hope you're having a great time listening to some of the really interesting talks at React Day Berlin remote event. Definitely, my talk, we'll keep up this momentum and we'll deliver some interesting stuff about micro front-end. With that note, welcoming you to my talk, Build a better micro front-end application that offers platform freedom.

I'm Sarvana Balaji Srinivasan. I work as a senior software engineer at Red Hat, with the role of full stack developer. I mainly do JavaScript technologies. I have been contributing towards Red Hat OpenShift AI platform. I work on UI stuffs as well as some edge computing stuff. I have got experience working on various JavaScript frameworks like React, Angular, Node.js etc. So yeah, that's about me.

You are watching to React conference, right? So let's talk about JavaScript and React. It's been 28 years, JavaScript was introduced. Already, it has passed its silver jubilee years of 25 years mark. And the growth of JavaScript has been tremendous over the years after the introduction of exciting frameworks. Even the top frameworks built on JavaScript are here for quite some time now. React is here for 10 years. Angular Node.js are here for almost 14 years. Vue.js is here for almost 9 years and the list goes on. It means that we have had applications that are a bit old now. Now, I mean that applications have been developed and maintained for a long time. Eventually, the applications keep growing, growing and exponentially growing. When the applications are growing big, they are really hard to scale and maintain. You will start getting complaints from your customers about various things and issues associated with it. Of course, it is not just because of JavaScript or JavaScript framework, there could be various reasons associated with it which is a separate topic to be discussed. But one reason could be the organization decision on how they want to build their application, the architecture. We at Red Hat had a similar kind of situation.

Now this takes me to the next slide, the Red Hat story. We had a product called Jbpm which is a business automation product which is considered as one of the main pillars of Red Hat. It was a legacy product. At some point, we decided to enhance the product and accommodate some latest tech stacks, making it available as a service with cloud technologies.

That's when we were in a situation to break a huge chunk of monolithic web applications. We already had Microsoft Visual at that point of time at the back end, but our front end was a huge chunk of monolithic applications which we wanted to break. This talk is about sharing the experience we at Red Hat had while building the monolithic application and how our new framework, the multiplying architecture, allowed to run the web components on the platform that we targeted.

Before getting into Microfrontend, let's discuss about the available architectural patterns. Architectural landscapes are changing a lot in recent years, starting with the evolutionary architecture, building software that is designed to evolve over time as business priority changes, customer demand shifts, and new technology emerges. Then we have microservices, which structures an application as a collection of independent services. Then we have the buzzing word, which is serverless at this point, which incorporates backend as a function. Finally we have Microfrontend here. So Microfrontend is not something new. It is already here for quite some time. Before getting into Microfrontend, I would just like to present a quote from a renowned software developer called Cam Jackson. According to him, an architectural style where independently deliverable frontend applications are composed into a greater whole. We'll discuss what he meant in this quote in detail in the upcoming slides. But we'll get into what is Microfrontend. I'll just pass it to you. I don't want to bore you guys with the definition of Microfrontend. I am sure that you would have already heard enough about it in other talks and presentations. So if you still want to know the definition of Microfrontend, I would strongly recommend you to go through those talks to understand the definition. But I would like to jump directly into the main objective of Microfrontend, which is decoupling. So the main motto of Microfrontend is to break your bigger monolithic chunk of application into smaller pieces and make the developer's life easier. It has a lot of advantages. Some of them are scaling and identifying issues will be made easy. And there is a saying actually, you don't have to put all your eggs in one basket, right? So like shown in this image, you don't have to put everything in one basket. So it will be hard to manage. You tend to break it. So this applies for your technology as well. You don't have to put everything on your one basket so you can just diversify your application. So diversification is just not for your wealth or money. You can always diversify your tech stacks as well, making your application easy to access and maintain. So while discussing about microfinance, microfinance is just not the only solution we have at this point in order to maintain your application.

We have other things to discuss as well. This slide will give you an overview about it. You can still go with monolithic-based applications. To be precise here, choosing any option from this is based on your organization decision. You can still go with micro-friendly or any other approaches that we have mentioned here. You can still go with monolithic-based application considering you have a simpler application where you have your front-end application and you have a back-end application. They communicate to each other in order to produce some results. If your application is smaller and easy to maintain, you can still go with monolithic-based application.

Or you can opt for modular monolithic application, which is similar to monolith and offers modules that can be easily replaced. It is a kind of reusability. You can also go with integrated application in which you have independent applications and they communicate or integrate at the built-in composition. And finally we have micro-frontend. I'll just pause here and go back to my title, build a better micro-frontend application that offers platform freedom. I would like to emphasize what I mean by the term platform here. As I mentioned, I work for the team where we build toolings for business automation products or serverless workflows specifications, etc. So, which are being used by the developers and communities across the world. So we wanted our web components to be running on platforms that our developers and communities use more often. So those are VSCode, Browser Extension, GitHub and finally WebApp. So these are the platforms that we were targeting. So why did we choose these platforms? So we are in a world where web technology has complete dominance in software development. It is considered as the go-to solution for anyone who wants to build an application for their use case. This is because web technology has stronger foundation, stronger patents, stronger techniques, stronger standards. It has reached an ecosystem which is fastly growing over the years. After the introduction of TypeScript, people like me who started a career as a Java developer started liking web technology after working on TypeScript. I personally feel that my code is totally type safe, while working with TypeScript. Another reason for choosing those targeted platforms being, now you can find browser anywhere. A browser is just not a tool to access your internet in the current world. It has become more than that. You can find browser in the platforms that I mentioned, like VS Code as an extension, VS Code extension or GitHub extension, browser extension or mobile devices. So we wanted to target those platforms since the availability of browser everywhere.

And we wanted to make our web companies to be running on those places so that even the developers can access those web applications more easily. So now you must have got what I mean by the term platform in my title. This entire talk is about sharing the experience we at Red Hat had while implementing new framework for Microfrontend to run our web components on developer tools platform. This is how we wanted to run our web components on our target platforms like VS code, browser extension or web app, etc.

Here's a small example on how we wanted to break one of our tools called BPMN editor. BPMN editor is a tool to design the business process and to represent in a graphical manner. You may think why did we choose to implement Microfrontend for such a small UI looking at this screenshot. Of course, it is just a small part of our bigger application. Our actual application has got nearly 600 to 700 components which is really huge. Coming back to the screenshot, if you closely look at this screenshot, the UI is broken down into smaller microfrontends. The header is separated as a microfrontend and made by a separate team. The explorer on the left could be made as a separate microfrontend and the actual editor at the middle could be made by a separate team as a separate microfrontend. So again, this is a small UI. This screenshot is a small screenshot but just imagine a bigger application like Amazon, Twitter, Instagram or something like that which is going to have a huge number of components. Again, you can't maintain such a big application as a monolithic based application. You definitely have to break down into smaller microfrontend applications so that it can be easily scaled and maintained.

Let's get into the features of microfrontend. So one of the core patterns that microfrontend proposes is the use of BFF. Yes! You heard me right! It is actually not abbreviated as best friend forever but it is a best friend for the microfrontend. Again if you look closely, look at this diagram. BFF stays in the middle between the microfrontend and the backend and acts as a means of communication between them. Whatever request comes from the microfrontend is being tweaked by the BFF in the middle and passes on to the backend in such a way that backend can understand it. It does the same in handling the response coming from the backend and it passes through the frontend. So again, then comes the types of integration. So this is considered the most thing to consider while implementing the microfrontend. So there are two types of type of integration strategies that are available. One is runtime integration and the other one is build time integration. We'll take a look deeper into these two things. First, Runtime integration also known as client-side integration. Imagine Team A decides to develop a new version of Component C, they deploy it and publish it as the URL mentioned here, mydomain.com.c.js.

So user navigates to the URL mydomain.com, the container application is something that has the entire control here. It loads the application and it loads the components. The new Component C is fetched by the container. So here as I mentioned the container takes the entire control over this application. The advantage of this approach is the Team A can deploy the Component C independently and can deploy different versions of it, the container decides which one to use. The disadvantage being tooling and setting up this approach is a bit complicated.

Then comes the next approach, the Build time integration, also known as compile time integration. Here Team A decides to develop a new version of Component C. They put it in a public registry as an npm package and the Team B which wants to use that version of Component C, installs the component or just bumps a version of it and they just use it. The advantage of this approach is it is easy to set up and maintain but the container has to be re-deployed every time, that is considered as a disadvantage of this approach.

There are other concerns associated with styling while using the Micro-Frontends. It could be like if you imagine multiple Micro-Frontend applications and there could be certain classes repeating, CSS classes repeating across the Micro-Frontends. The CSS properties of one class could be overridden on other Micro-Frontends and which could result in breaking your UI. There are certain solutions to overcome this problem. One famous solution is to use CSS and JS libraries. There are many libraries available. One of the famous ones is Tiled Components where you can write CSS code directly on the Java files as well. Another solution is an age-old approach using iframes. It solves the problem of isolating your micro frontend from the outside world. But, it is again considered an older approach. Here is a simple example of how you can use iframe to wrap your micro frontend and just render on the container application. If you look closely at this code here on the line 18, iframe.src contains the source code of another micro frontend so this is how a micro frontend will be rendered on an iframe and that iframe will be rendered on the container application. So there are certain pros and cons associated with iframes which I listed here. The pros could be again you can isolate your micro frontend from the outside world. But on the other side there are a list of cons like it makes your application to look a bit old and it is less flexible.

So why did we need a new architecture? We had these requirements we wanted to have multiple distributions to deploy same set of components on various platforms with minimal code changes to embrace different generations of tech stacks. These were our end goals. Now we will understand what is software architecture before getting into the multiplaying architecture. As per Ralph Johnson architecture is about the important stuff whatever that is. The important stuff of an application should be considered as priority.

Now let's get into a short introduction to multiplaying architecture which is a framework of micro frontend. The main idea of multiplying architecture is to have abstraction. These are the core components of multiplying architecture. The channel, envelope, view and editor. The channel is the top level of abstraction that represents the hosting environment. In our case it could be VS code, GitHub extension or browser extension. So if you are using this multiplying architecture you can have your platform or your environment as the channel.

And then we have envelope which enables transparent communication between the components. Here the components, what I mean by is the view and the channel. So it enables the communication between the view and the channel. Then view is a portable set of widgets. And finally we have the core editor. The actual BPMN editor and DMN editor that we wanted to make it run on different platforms. So we wanted to have our editor running on the online channel, like this. We see here the yellow line marks as the channel and then we have the envelope inside it, and then we have the actual editor inside it. So that's how the abstraction layer of this multiplying architecture works. And then we wanted to have our editor to be running on the desktop channel like this. GitHub extension acts like this, and VS Code extension like this. So this diagram explains how the envelope enables the communication between the channel and the view. So it acts in the middle. And then the envelope and the view are wrapped inside a div. If you closely look at this diagram here, there is no iframes are used. So we have got rid of iframe usage of iframe. And then we have used div, so that our UI looks more, I mean, more realistic, right? And finally, we have the channel wrapping all these components together inside it.

So envelope is considered as the more important component of this multiplying architecture. So we need to discuss a little deeper about it. So what my envelope offers is it provides you context isolation. It makes your team work as a tone. I mean, as I mean, you can have autonomous team in your projects, and you can have independent cycles. It enables type safe communication between the micro frontends.

So let's see micro frontend and architecture in practice. Let's get into VS Code. I'll be sharing the repository URL. There will be a slide at the last where you can access that. It's just an open source code. You can feel free to access that code and see how this multiplying architecture is implemented and how the micro frontend strategies are used in it.

So I'll just walk you through this repository and show you how the folders are created, how the project has been set up so that it will be easy for you when you try it on your own. There is a folder called examples in this repository, which contains some classic examples that you would have already tried in some of your previous POCs like Todo List, Ping Pong. These are the examples that anyone will try when they learn React for the first time, right? So yeah, again, those examples are built here.

So there's a folder called webapp, which is the container application, which is going all the individual channels or individual applications inside it, and run as a single web application. So I'll be running this webapp and show you how it looks on the browser. But before that, we'll just go through this folder, and see how this actual multiplying architecture and how the folders are created, and how the configurations are made. We'll start with this channel here. This Todo List view, VS Code extension is a channel. And this Todo List view is the view, actual view. So if you just recall the components, the four core components of multiplying architecture we discussed in our previous slide, the channel, envelope, view, and the editor, right? So here, this Todo List view is the actual view, which is a JAK application, if you see here, it contains envelope. So this envelope is responsible for enabling communication between this view and the channel. So if you just go through this envelope file, it contains some abstract methods. If you have tried Todo List before, you must remember the actions that we can do on Todo List, to create a note, edit a note or delete a note, and to mark a note as complete, something like that. These abstract methods contains the definition of each of these actions that you can do on Todo List. And this view is going to be communicating with the channel and it will be going to be abstracted inside the channel. So this extension is a TypeScript, based on TypeScript. So yeah, it just initiates this view. So if you see this package Json, Todo List view is installed as a dependency and in the extension it is just imported here and just it just initiates it, that's it. So the channel does nothing apart from that. It's as simple as that. And if you take another example of ping-pong view, again, this ping-pong view is the actual view which is React component is going to contain all the TSX files. And for this ping-pong view we have two types that is one with iframe and the other with div, so that you can try both the ways. So in my previous slides I also mentioned the same. So this multiplying architecture we managed to avoid usage of iframes.

We used div so that our UI looks more realistic. It doesn't look old or something. So this ping-pong view angular, again a channel. Ping-pong view React is again a channel. The basic idea of Microfrontend is again to use different text tags.

In one UI application, you must have able to incorporate framers like Angular, React but still for the user, it should just look like a single application. So that's what again one of the core responsibilities of using Microfrontend. So that is what we were trying to achieve as part of this multiplying architecture.

In order to try this particular example, you can just try this ping pong example, which will give you more idea about. Let's get into this web app application and see how all the individual examples are combined into it. So there is a pages folder inside this web app, which creates individual pages for each of the channels that we have. So for ping pong, base64, tudoless, etc. Since I have this application running, I'll just go through the browser and see how it looks. So yeah, this is the tudoless. React Day Berlin is awesome. I'll just add this note. Maybe I'll just mark it as complete. Remote. Successfully remote. So you can just try ping pong React iframe1 and dev1. Similarly, you can try Angular iframe1, dev1. So yeah, you have a lot of options here to try out. And to demonstrate in our team, as I mentioned, we're building editors or tools, BPMN and DMN editors, so this is how we're able to render those editors on different platforms using multiple architecture. So in case if you want to try this BPMN editor, you can go to com.webstore and search for this BPMN-DMN editor. There will be this extension which you can install. Since I have already installed it, I can just directly go into bpmn.new. So this loads my editor. You can just add the notes here and create a business automation process. I'll just show you how it looks on the VS Code as well. So this is again the editor.

The same editor, if you just look closely at the UI of this editor, it's the same web component, I mean used on both the platforms, so that's what our end goal was. Even after achieving this, there's one concern that we wanted to address is the duplication of library loading. So if you just recall again the integration strategy that we were discussing, these are the issues that we were having from both the integration strategies that we were discussing. The common thing among these is duplication of library loading.

What does that mean? Imagine if you have multiple micro frontends in your application and each micro frontend has React as a dependency to it. When you combine all these micro frontends into a single container application, just imagine the size of this container application is going to be. Right? Just one dependency coming, I mean, duplicating across micro frontends is totally fine. But still, if you have more number of dependencies that are duplicating across micro frontend and it is going to create a huge space, right? And it will slow down your application, as well, you don't have to do that.

We also wanted to avoid this problem, that's when federated modules came to our rescue. You would have already heard about this federated modules, which was released as part of webpack and which enabled us to share the dependencies between the micro frontends. So, this is how the configuration of webpack configuration looks like. The federated module is imported at the top and here in the plugin section, you can just create a new instance for the micro, I mean, federated module. And you can just share the dependencies here, pointing to your packages and dependencies. And to lazy load your micro frontend components, you can always use this lazy loading feature of React so that you can just render the micro frontend UI whenever that particular micro frontend is visited. You don't have to load everything at once on the beginning so that it will just load on your application anyway. So, you don't have to do that. You can just render it whenever it is necessary or whenever it is visited.

So, after implementing all the micro frontend strategies and coming up with a new multiplying architecture framework and then again by using federated modules, finally, we were able to achieve our end goal to have our editors to be running on various platforms that we targeted. And we were able to achieve multiple distribution with minimal code changes. And we also had I mean able to bridge the gap between the generations of text stacks that we were using in our application. Yeah. So these were the achievements that we were able to make out of this multiplying architecture. So the code that you saw here resides in this repository. You can snap a pic of it and then you can just give it a try on your own. In case if you have any questions, you can feel free to reach me out.