Building a Better Micro-Frontend Framework That Enables Platform Freedom

Rate this content

A modern tooling experience usually involves a user journey on multiple mediums, including Web, VS Code, GitHub, etc. Writing custom code and components for each platform is not the most efficient approach, leading to code duplication and, most importantly, the risk of a lack of a cohesive experience.
Multiplying Architecture is a set of patterns, techniques, and libraries that, using micro frontends and some innovative backend services, allow for the re-use of the tooling component in different distribution mediums
Come to this talk to learn how we are able to enable multiple tooling teams across Red Hat to deliver the best native experience of UI components (s and Views) on VS Code, Web, and Desktop, and directly integrate them on GitHub(Chrome Extension) with minimal changes on their code base.

28 min
12 Dec, 2023

AI Generated Video Summary

This talk discusses the challenges of scaling and maintaining applications and how architecture decisions can impact them. It introduces the concept of Microfrontend and its advantages of easier scaling, issue identification, and diversification of technology stacks. The implementation of Microfrontend at Red Hat is explained, including the use of a new framework, communication strategies, and the need for scalability and maintenance in large applications. The talk also covers the multiplying architecture framework of micro frontend and its core components. The implementation of Microfrontend in VS Code and examples of combining different frameworks into a single application are showcased. The issue of duplication of library loading is addressed using federated modules in webpack.

1. Introduction to Micro Front-end

Short description:

Hello everyone, welcome to my talk on building a better micro front-end application. I'm Sarvana Balaji Srinivasan, a senior software engineer at Red Hat with experience in JavaScript frameworks like React, Angular, and Node.js. Today, I want to discuss the challenges of scaling and maintaining applications, and how architecture decisions can impact them. Let's dive into the Red Hat story, where we enhanced the Jbpm product with the latest tech stacks and cloud technologies.

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.

2. Introduction to Microfrontend

Short description:

This part discusses the experience of breaking a huge chunk of monolithic web applications at Red Hat. It introduces the concept of Microfrontend, emphasizing its objective of decoupling and breaking a monolithic application into smaller pieces. The advantages of Microfrontend include easier scaling, issue identification, and diversification of technology stacks.

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.

3. Overview of Application Options

Short description:

You can choose between monolithic-based applications, micro-friendly approaches, modular monolithic applications, integrated applications, and micro-frontend. We aimed to build a better micro-frontend application that offers platform freedom. Our target platforms include VSCode, Browser Extension, GitHub, and WebApp. Web technology has become the go-to solution in software development due to its strong foundation, patents, techniques, and standards. The availability of browsers everywhere motivated us to target these platforms.

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.

4. Microfrontend Implementation and Features

Short description:

This part discusses the experience of implementing a new framework for Microfrontend at Red Hat to run web components on developer tools platforms like VS Code, browser extensions, and web apps. It provides an example of breaking down a tool called BPMN editor into smaller microfrontends, highlighting the need for scalability and maintenance in large applications. The use of BFF (Backend for Frontend) as a communication channel between microfrontends and the backend is explained, along with the two types of integration strategies: runtime integration and build time integration.

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,

5. Microfrontend Architecture and Styling

Short description:

The container application has full control over the application and components. Team A can deploy Component C independently, with the container deciding which version to use. The Build time integration approach allows easy setup and maintenance but requires redeployment of the container. Styling concerns in Micro-Frontends can be addressed using CSS and JS libraries or iframes. These solutions have their pros and cons. The new architecture was needed to deploy the same components on multiple platforms with minimal code changes.

So user navigates to the URL, 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.

6. Introduction to Multiplying Architecture

Short description:

The multiplying architecture framework of micro frontend introduces the core components: channel, envelope, view, and editor. The channel represents the hosting environment, such as VS Code, GitHub extension, or browser extension. The envelope enables transparent communication between the view and the channel. The view consists of a portable set of widgets, while the core editor, including BPMN and DMN editors, can run on different platforms. The envelope acts as an abstraction layer, facilitating communication between the channel and the view. The envelope and view are wrapped inside a div, eliminating the need for iframes and providing a more realistic UI. The envelope component offers context isolation, allowing autonomous teams and independent cycles, while enabling type-safe communication between micro frontends.

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.

7. Microfrontend Implementation in VS Code

Short description:

Let's explore the implementation of micro frontend architecture in practice using VS Code. We'll walk through a repository that contains examples like Todo List and Ping Pong, which are classic React examples. The repository also includes a webapp folder that serves as the container application for individual channels. We'll focus on the Todo List view, which is a JAK application and utilizes an envelope for communication with the channel. The channel itself is a TypeScript extension that initiates the view. Additionally, we'll examine the ping-pong view, which offers two options for rendering: iframe and div. This approach eliminates the need for iframes.

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.

8. Microfrontend Implementation and Examples

Short description:

We used div so that our UI looks more realistic. The basic idea of Microfrontend is to use different text tags. In one UI application, you must be able to incorporate frameworks like Angular and React, but still, for the user, it should just look like a single application. This example showcases the combination of individual examples into a web app application, with separate pages for each channel. You can try out different options and even explore the BPMN-DMN editor on different platforms.

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 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.

9. Addressing Duplication of Library Loading

Short description:

Our end goal was to use the same web component editor on multiple platforms. However, we faced the issue of duplication of library loading when combining micro frontends into a single container application. To address this, we utilized federated modules in webpack to share dependencies between micro frontends. By lazy loading micro frontend components and implementing the multiplying architecture framework, we achieved our goal of running editors on various platforms with minimal code changes and bridging the gap between different tech stacks. The code for this implementation can be found in the provided repository.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Summit 2022React Summit 2022
23 min
Sharing is Caring: (How) Should Micro Frontends Share State?
Micro frontends architecture is extremely powerful when it comes to splitting large frontend monoliths into smaller, individually deployable blocks, each is owned by an autonomous team and is focused on a business domain. But what about State? We are often told that micro frontends shouldn't share state, as this would make them coupled to each other. However, when it comes to complex UIs, it is not rare to encounter scenarios where state management between micro frontends is necessary. This talk is about finding the sweet spot — In which scenarios it is reasonable for micro frontends to share State? and how should micro frontends share State while remaining decoupled of each other? We discuss & compare different solutions in React.
React Advanced Conference 2021React Advanced Conference 2021
27 min
Micro-Frontends Performance and Centralised Data Caching
Common myths about Micro-Frontends hold that they are bad for performance or that developers implementing this architectural style don’t care about the performance implications because they are focusing on fixing the developer experience and organizational issues rather than focusing on the user experience, however, the reality is altogether different. Micro-Frontends are not inheritably bad for performance and, as is often the case in software development, making best use of the technology depends on correct implementation. This talk will demonstrate how Micro-Frontends can make your applications faster and more resilient while keeping the benefits of independent deployments.
React Summit 2022React Summit 2022
25 min
React Microfrontend Applications for TVs and Game Consoles
DAZN is the fastest-growing sports streaming service and during this talk, we will consider our experience building tv applications (for ps5, xbox, LG, Samsung and other targets) with micro frontend architecture. You may expect time travel to see how it started and what we have at the moment, what makes tv development different compared to the web, same as techniques that allow us to share code between targets. You will learn how we test our application with an in-house remote testing lab as well as our deployment and release process.

Workshops on related topic

JSNation Live 2021JSNation Live 2021
113 min
Micro Frontends with Module Federation and React
Did you ever work in a monolithic Next.js app? I did and scaling a large React app so that many teams can work simultaneously is not easy. With micro frontends you can break up a frontend monolith into smaller pieces so that each team can build and deploy independently. In this workshop you'll learn how to build large React apps that scale using micro frontends.
JSNation Live 2021JSNation Live 2021
113 min
Micro-Frontends with Module Federation and Angular
Ever more companies are choosing Micro-Frontends. However, they are anything but easy to implement. Fortunately, Module Federation introduced with webpack 5 has initiated a crucial change of direction.
In this interactive workshop, you will learn from Manfred Steyer -- Angular GDE and Trusted Collaborator in the Angular team -- how to plan and implement Micro-Frontend architectures with Angular and the brand new webpack Module Federation. We talk about sharing libraries and advanced concepts like dealing with version mismatches, dynamic Module Federation, and integration into monorepos.
After the individual exercises, you will have a case study you can use as a template for your projects. This workshop helps you evaluate the individual options for your projects.
Prerequisites:You should have some experience with Angular.