8 Things You Did Now Know Micro Frontends Can Do

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Did you know that micro frontends can be much faster than their monolithic counter parts? How about rollbacks of specific features? In this talk you will hear and see 8 examples of things that will not only teach you a bit about micro frontends, but also in what cases they are most useful.

This talk has been presented at React Summit US 2024, check out the latest edition of this React Conference.

FAQ

The session is focused on introducing microfrontends to individuals who have had little to no contact with them and aims to educate on various aspects of microfrontends.

The presenter is Flo, a solutions architect from SmartPio in Munich, Germany, who specializes in distributed web applications and microfrontends.

Microfrontends are the technical representation of a business subdomain, allowing independent implementations with the same or different technologies, similar to microservices.

Microfrontends can be developed locally and offline using a build tooling and emulator that allows integration of other microfrontends and testing in isolation.

HMFR is a process where updates to microfrontends are automatically inserted into a browser, allowing for streaming updates similar to hot module reload.

Microfrontends allow partial rollbacks by swapping specific versions of a microfrontend using a discovery service, enabling targeted updates without affecting the entire application.

Yes, microfrontends can be used for A/B testing and personalization by utilizing a discovery service to deliver different microfrontend versions based on user criteria.

No, microfrontends can be used in various platforms, including server-side rendered applications, making them versatile and transportable.

Microfrontends can enhance performance by allowing smaller, independent updates without affecting the entire application, improving caching and reducing load times.

Generative AI can be integrated by using a discovery service to create AI-enhanced variants of microfrontends, enabling experimentation with different versions for user feedback and optimization.

Florian Rappl
Florian Rappl
22 min
22 Nov, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Welcome to the session on microfrontends. Microfrontends allow for independent implementations and local development. It is possible to develop and integrate microfrontends locally using an emulator and achieve automatic updates. Fine-tuning modules and user experience can be done using a discovery service. Rules can be created in the discovery service to selectively load microfrontends for specific browsers. AI can be leveraged to generate AI-enhanced variants and compare them with the original implementation. Microfrontends are highly portable and can be used in different applications. Code isolation and enhanced performance are important considerations in microfrontends. The benefits of microfrontends include improvements in file name changes and performance overhead. The Netflix application is a case study for microfrontends. Overall, microfrontends offer various benefits and opportunities for architectural discussions.

1. Introduction to Microfrontends

Short description:

Welcome everyone to the session, 8 Things You Did Not Know Microfrontends Can Do. The session is targeted towards people with little to no contact with microfrontends. The speaker, Flo, is a solutions architect specialized in distributed web applications and microfrontends. He will provide a general definition of microfrontends, explaining their technical representation of a business subdomain and the organizational pattern behind them.

Welcome everyone to the session, 8 Things You Did Not Know Microfrontends Can Do. The session is mostly targeted towards people that have, let's say, had barely or even no contact with microfrontends, so if you consider yourself a microfrontend expert, I would assume that you know already one or the other thing in here, but hopefully I can still teach you, let's say, a variety of things that should be possible.

Before we dive into the topic, a few words about me. Hi, my name is Flo, I'm a solutions architect from a smaller company called SmartPio. We sit right in Munich in Germany and we are mostly dealing with IoT platforms, modular applications, security audits, and whatnot. I myself am specialized in distributed web applications and microfrontends. I'm giving also workshops, doing code reviews, and helping of course teams to scale up the frontend development. So if any of what I just said makes any sense to you and you want to get in touch and potentially want to discuss how we can, let's say, improve your architecture, always just ping me.

The LinkedIn URL is written also on the bottom of all the slides. All right, but we don't have much time and there are eight things to go over, so let's just jump right into topic, and what I want to do is I want to start with general, let's say, definition of microfrontends, because there are a couple of definitions out there and potentially you are a little bit unsure what microfrontends are. So microfrontends are the technical representation of a business subdomain. What you can already, let's say, know from that definition is that there are no restrictions and also no guidelines what you need to do for a technical implementation. All the things that I said here is that it's more or less organizational pattern that arises here that's, of course, geared towards solving a technical issue.

2. Implementation and Local Development

Short description:

Microfrontends allow independent implementations with the same or different technology. They can be thought of as an extension or the next step after microservices, touching both the frontend and backend. The goal is to have autonomous teams, each owning isolated microfrontends. One implementation approach is local and offline development, using build tooling and an emulator to work on microfrontends locally. This allows for automatic updates and integration of other microfrontends.

Now, if you want to dive a little bit more into it, of course, then you would need to continue reading because they allow independent implementations with the same or different technology, meaning you can, of course, use, I don't know, React to write your components, but you could also use something else. So a little bit of the promises that you know already from microservices. In general, microfrontends can be thought of as just an extension or, let's say, the next step after microservices and they, of course, also touch the frontend. They don't need to be exclusive to the frontend. They can, of course, have some backend part in there and the best, let's say, scalable solutions out there, they really are full stack, meaning that there is, of course, some UI fragment that gets delivered, but there are also backend fragments that are delivered here from these teams. Now, what they should do in order to achieve that is they should minimize the code shared like you already do with your backend. And, of course, you don't want, let's say, to have interleaving areas with other subdomains, meaning other teams that are also creating microfrontends. At the end, the goal is to have autonomous teams here. So one team can also have multiple microfrontends, but the real important part is that there is no microfrontend that's shared among different teams. So also the microfrontends represent really an isolated unit that you talk about. Now, as I said, there are multiple things that you can do actually implement them. This will not be a talk where I go over all of these things. I just then use, of course, sample implementations to show you now the eight things that you can do instead. So let's start right away with local and offline development. Quite often when you get in the area of microfrontends, people say, well, then we need to have an aggregation environment, and only in that environment, can you not say, let your microfrontends run? So you always will have, let's say, this kind of weird feeling that you just not develop something. We don't even know how it then looks when it gets integrated and really used by end users. And that's not really good. So what you can do instead, and what, of course, we always encourage people to do is, we have a build tooling that, of course, triggers the start of your development session locally against your microfrontend, but then also takes into consideration some other sources. And very often these sources can be installed already upfront, for instance, in form of NPM packages, but they can also reside somewhere online. And then when you start your development session, just be grabbed or not, right? If you already have some locally, the cache one could be used, but this allows you to automatically update it. So now you run a studio microfrontend, but it now runs in the context of this, what we usually refer to as emulator. The name was chosen because it's the same idea that you have, for instance, when you develop, for instance, an Android app, you also don't do it on your phone right away. You don't do the integration, but you work against this emulator. And this, of course, can give you some bad tips. Now, looking at this scenario here, we have one microfrontend, it's just a standard Node or NPM project. So here based, of course, on React, and you see, we have a lot of development dependencies already installed, but the code base is rather small. If you look in the depth dependencies, you also have this strange one, which is our emulator. Now, if you just start this, then of course our microfrontend will run, but it looks rather empty, but it's already in something where we see not flicks. So that's the demo behind. So we have this Netflix shell, but it's rather empty because we are developing isolation, right? But what it can do via browser extension, for instance, is bring in other microfrontends.

3. Developing and Integrating Microfrontends

Short description:

You can develop and integrate microfrontends locally using an emulator. The hot microfrontend reload allows for automatic updates in the browser. The application can listen to a discovery service to update and reload microfrontends. It's easy to activate, but user feedback is recommended. Rollbacks are easier with modular microfrontends.

So suddenly you started with just developing your microfrontend, you already run it in the emulator. And now this even allows you making the integration locally. And so now the favorite microfrontend that we are developing here for the watchlist feature is 14 pin. All right. So quite cool, right? So you can just go ahead as you would usually do with your monolith, and you can even bring in other microfrontends on demand, but you can even go one step further. You can even do the same approach that you have in local development where updates, of course, are automatically inserted into a browser using a hot model reload, for instance. You can apply that and actually make instead of HMR, HMFR, so hot microfrontend reload. So it was a streaming update. So your application can listen to a so called discovery service, which is kind of the man in the middle here. So between your development and of course the end application, this thing knows what microfrontend is currently active in the system. So now when you ship a new version, like you ship a new version 2 of your microfrontend, the application can listen to this change and just say, hey, just unload the current version 1, reload or load the version 2 that we now have, and there you go. You just hot updated your application. So consider this example. Here we have the browse microfrontend, and let's say one just to change how the link is called, we change it to overview in this example, restore it. But so far nothing happened, right? We haven't published it. So let's just publish it now to the discovery service we use to see it. Again, usually it would be done via CICT system. We would just do it in the demo purposes on the screen. So now that we've published it, let's look at the page and it should also update any second. So let's go there. Once we're there, the browse changed to overview. So quite nice. And we just had a streaming update and there's essentially no effort needed here to introduce that. The system already knows how to do that usually. So the only thing is you'll need to opt into that. We usually recommend not doing it because, well, I mean, you would at least have a little bit of a user feedback, not just change something. There are other potential problems, but yeah, if you want to do that, it's quite easy to activate. The same thing of course can now be said about you already have something up there, but for some reason you want to have a rollback. Now previously in a monolith, of course, you need to roll back everything and that can be, well, not so nice always. But now of course, given that we are already quite modular, we have all these micro-frontends that bring of course certain components in.

4. Fine-tuning Modules and User Experience

Short description:

We can use a discovery service to swap between different versions of micro-frontends, allowing for easy updates and partial rollbacks. The discovery service can also tailor the experience for different end users based on criteria such as region or browser. A micro-frontend called random is responsible for the 'surprise me' button in our Netflix application.

What we can do is a scenario like this where we say we have version three of a certain micro-frontend. And now we just swap in our discovery service that the currently selected version should be a previous one, like version two. So same concept. Here we see the UI of a discovery service and we see that of this browse micro-frontend we have the older version. And right now overview is active. So if we jump back, we see, oh, it's now browse again. So we just swap that out and on the fly, we just made a streaming update again. And in this case it was partial rollback. So only this one area that was affected has been changed. Quite nice.

Now, of course you can already guess what's coming next because having this discovery service and there was all the modules. And we see that the modules of course can now be really fine-tuned, for instance, choosing a previous version or a version that's available in the future. We can of course think about, well, having a kind of deterministic way to roll out modules in general. So what we could do is we talk from the application to discovery service and for the first user, the red user here, the discovery service says, oh, awesome. So these are the three micro-frontends that should be used now for this one user. Great. So the application just integrates those three and we are done. We have purple, we have orange, we have red. But another user comes, we are now the blue user. And if the blue user asks the discovery service, it will say, oh, but you're coming, I don't know, from a different region or you have a different browser or whatever criteria is now used. The discovery service will now pick a different set of micro-frontends. For instance, of the orange one, it chooses a different version. So that's like AP testing. The purple one is just the same. And then the red one, that should only be exclusive to the red user. Instead, we now got a blue micro-frontend for the blue user. So nice, the discovery service already allows us to tailor the experience for the respective end user.

So one example we can see here, again, we are in our Netflix application. We have Firefox open, we have Chrome open. Now we see the surprise me button comes from a micro-frontend called random.

5. Creating Rules for Browser-Based Loading

Short description:

We can create rules in the discovery service to distinguish between browsers and selectively load micro-frontends for specific browsers.

So what we can do, for instance, here, we can create a new rule. In this case, we set the rule up to distinguish between the browsers. So at the moment, it's just loaded in Firefox. But if we say, only in Chrome, voila, it's no longer there. Same, of course, applies to Chrome. Right now it's there. If we swap the flag and say, hey, instead of going now exclusive for Chrome, maybe let's go exclusive for Firefox. And if we just set that up, then of course, now we get it rolled out in Firefox. So here it is, the surprise me button again. And of course, it would have a page behind. And the same thing is, of course, true for Chrome, right? So this now doesn't load it anymore, and we are done.

6. Leveraging AI for Variant Generation

Short description:

We have the power to tailor the user experience by writing modules behind the decoupled system. An interesting use case is involving generative AI, where the discovery service selects microfrontends and the AI service generates AI-enhanced variants. This allows us to compare the original implementation with the AI-enhanced version and analyze user retention and attractiveness. A-B testing with AI enhancement is accessible through the service's information exchange with another service.

All right, so you already see where the power comes in because we have this decoupled system where we can now write all these modules behind. We now have the possibility of really tailoring the user experience. And we don't need to do it in code anymore because we have this thing in between the established service. And I can do even a little bit more.

So I can, let's say, get a lot more things out there. But one of the quite trendy use cases is to also potentially involve generative AI here. So what you could do is just one example, and there are startups who are just doing that, like Atomic AI is one of those, is you have your discovery service in between, and as before, and it selects, of course, a set of microfrontends.

Now, whenever you publish a microfrontend, the discovery service talks to a specific service and puts this microfrontend to the service. So the AI service that's behind will generate a new version of this microfrontend. We usually could call this a variant of the microfrontend or, let's say, a suggestion. And so we have for all of the available microfrontends another variant, or let's say AI-enhanced variant. So now for a specific different user group, we could now ship all the variants that we derived. And this way we can actually compare what is our original implementation versus what is the AI-enhanced way. And what we, of course, want to see at the end is are there maybe more leads that can come out, or is the AI more attractive towards the end user? So what's the user retention here, and what can we say about it? So it's quite nice to have this kind of experiment or A-B testing, let's say, already with an AI enhancement. And you can easily do that because, again, the service receives all the information. It can just work with another service. And then, of course, it loops the variant. So this is something you can quite easily do.

7. AI and Portability of Microfrontends

Short description:

In a monolith, it would be more problematic to involve AI due to the need to ship the entire code base. Microfrontends are not limited to single-page applications and can be highly transportable. They can run in different applications and can be filtered using a discovery service. A-B testing can be combined with the concept for further experimentation. Let's proceed to a demo.

Now you might say, oh, this I could potentially also do in a monolith. But in a monolith, it would be quite more problematic because you would need to ship your whole code base to the AI service. It would need to know a lot more. Plus, of course, it can't just install and use new dependencies, whereas here, of course, you use dependency sharing and all these things. So it has a much more, let's say, flexible system underneath. And it can just leverage very easily.

Next thing that you could look at is, oh, microfinance, isn't that just for X? And I'm not meaning Twitter here. What I'm meaning here is a specific platform, like a single-page application, for instance. Very often, people think, oh, this is really all about, I don't know, single-page applications. But that's actually not the case. The microfinance itself should be, if it's properly done, quite transportable. There might be, of course, as usual, some special rules. So you might write a microfinance that only consists of components where you say, well, I assume they only render in the browser or on the server. That might happen. But quite often, you should think here beyond that. And if you do that, your microfinance itself is quite portable.

Now, that means it could run in different applications. So for instance, in one application, that's a single-page application. And in another one, that's a server-side rendered web application. Again, you could have a discovery service in between. But for this, let's say, point, it's not really required. Still, it could help us, because the discovery service could already be used to filter out certain things. So for instance, for app one, it still delivers blue and orange. For app two, it delivers orange and red. Why doesn't it deliver blue? Maybe blue has a special flag behind only for browsers. And red only has a special flag behind only for Node.js servers or something like this. So with this information, of course, it would already deliver something that would be, let's say, usable with target system. Now, there might be other things. And you might combine it, of course, with some A-B testing and so on that is, of course, composable with the concept before it. So let's look at a straightforward demo.

8. Netflix Application and Microfrontends

Short description:

The Netflix application is a single-page application that heavily relies on JavaScript. If JavaScript is disabled, the application will be empty. However, other applications using the same micro frontends can still render perfectly even without JavaScript, thanks to their progressive design. There are some exceptions, like the search bar, which is only available in the client-side rendered application when JavaScript is active.

We are back in our Netflix and that's essentially just a single-page application. As a consequence, if you disable JavaScript here, well, the user experience will suck, more or less, right? So there's just nothing. Well, it's empty. Sure, we could have extended the demo and there could be a little bit more information, like you need to have JavaScript to have it running. But yeah, that's just the experience you get here. So everything is done in the browser.

Now, this thing also uses the same micro frontends, but it's a different application. And this application, if you disable JavaScript, it's still rendering perfectly. And while this is a server-side rendered application, it just makes use of the same micro frontends. It's even behaving as it should, right? Because micro frontends have been written, let's say, already in a progressive way. But there are some exceptions to this rule. For instance, I don't know if you noticed, but there is the search bar. The search bar is only available when you render on the client. So it's not just exclusively available in the single-page application, but it will only then render properly in the server-side rendered application when JavaScript is active. But I mean, that's something you can still do.

9. Code Isolation and Enhanced Performance

Short description:

Code isolation is an important topic, especially when dealing with sensitive information on the server. Running micro front-ends in isolated contexts with dedicated globals can increase security and resilience. Additionally, enhancing performance in microfrontends involves using smaller modules and implementing effective caching strategies to minimize changes and improve user experience.

All right, since time is approaching to the end, there are no more demos for the next two ones, but I still want to mention them. The first one is code isolation. That's also a topic I had in my talk at the recent JS Nation US. So if you happen to be there, great. If not, I guess the talk will be online at some point in the future, always get active there and get your pass to have access to all the talks.

Now, what you can do with code isolation is quite simply explained on the browser. It's a very difficult topic because, well, you can't really isolate different JavaScript files. You can do maybe things in iFrames, but that's always difficult from a layout thing. You can do, for instance, workers, web workers, but then you need to proxy certain things and that becomes also very messy. So I usually don't do it. But on the server, it's doable and you should potentially even do it because on the server, there's anyway much more sensitive information. So for instance, all your environment variables. So what you can do is that you can run your micro front-ends in isolated contexts that have dedicated globals, so not the standard require, for instance, and they usually shouldn't have any environment access. So you would mock away the process of ENV in a Node.js server, for instance. And you should actually do that because not only will it increase security, but it will also let you sleep much better at night, right? So you don't need to worry about what could now happen. Even if you trust all the players in the system, it makes sense. Plus, of course, if one of the micro front-end fails, if it's anyway running in an isolated context, your usual main application would automatically not fail. So this is already, in my opinion, the resilience part quite good to take.

Last point that I want to make is enhanced performance. And I'll try to be quick on this one. There are multiple things one can say about it, but let's just have the following argument. In a monolithic app, you really need to go up to great lengths in order to avoid if you make one change to have everything changed. And usually you still have quite some cascade in there. And so even if you have a long caching strategy, people will always see everything is changed, right? So maybe not the assets, like the images, but JavaScript wise, well, you're in deep trouble here. On the other hand, in a monolithic app, if you really have the smaller modules, they're usually just a few kilobytes. Well, if something changes and you have good caching strategies, everything remains the same except the small part that actually changed. And there's a difference, of course. So you would still, of course, in the monolithic case, have lazy loading and whatnot. But these things are still bound by, for instance, the file name.

10. Microfrontends Benefits and Closing Remarks

Short description:

Microfrontends offer improvements in terms of file name changes and performance overhead. Additionally, they provide the opportunity for architectural discussions and access to a free trial or community version of the discovery service in TED.

But these things are still bound by, for instance, the file name. So any kind of, let's say, hash value that changed in the file name has a cascade coming up and that's not the case here. So quite an improvement.

There are other areas, of course, where you say you could actually be even better with a microphone in solution as compared to a monolithic solution. There is, of course, always a downside that we need to have the orchestration scripts in there and that will usually be a little bit of overhead, but you can make up for that and they can usually give you other benefits.

All right, so that's everything from my side. As already mentioned, get in touch. We have a website where you can also book free architectural sessions if you want to discuss certain things. And finally, we also want to encourage you if you like the discovery service in TED, you can always get a free trial or access the free community version online. Just scan the QR code and there you go. Thanks a lot and enjoy the conference.

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

Scaling Up with Remix and Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Understanding React’s Fiber Architecture
React Advanced 2022React Advanced 2022
29 min
Understanding React’s Fiber Architecture
Top Content
This Talk explores React's internal jargon, specifically fiber, which is an internal unit of work for rendering and committing. Fibers facilitate efficient updates to elements and play a crucial role in the reconciliation process. The work loop, complete work, and commit phase are essential steps in the rendering process. Understanding React's internals can help with optimizing code and pull request reviews. React 18 introduces the work loop sync and async functions for concurrent features and prioritization. Fiber brings benefits like async rendering and the ability to discard work-in-progress trees, improving user experience.
Full Stack Components
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
RemixConf EU discussed full stack components and their benefits, such as marrying the backend and UI in the same file. The talk demonstrated the implementation of a combo box with search functionality using Remix and the Downshift library. It also highlighted the ease of creating resource routes in Remix and the importance of code organization and maintainability in full stack components. The speaker expressed gratitude towards the audience and discussed the future of Remix, including its acquisition by Shopify and the potential for collaboration with Hydrogen.
Thinking Like an Architect
Node Congress 2025Node Congress 2025
31 min
Thinking Like an Architect
Top Content
In modern software development, architecture is more than just selecting the right tech stack; it involves decision-making, trade-offs, and considering the context of the business and organization. Understanding the problem space and focusing on users' needs are essential. Architectural flexibility is key, adapting the level of granularity and choosing between different approaches. Holistic thinking, long-term vision, and domain understanding are crucial for making better decisions. Effective communication, inclusion, and documentation are core skills for architects. Democratizing communication, prioritizing value, and embracing adaptive architectures are key to success.
The Eternal Sunshine of the Zero Build Pipeline
React Finland 2021React Finland 2021
36 min
The Eternal Sunshine of the Zero Build Pipeline
For many years, we have migrated all our devtools to Node.js for the sake of simplicity: a common language (JS/TS), a large ecosystem (NPM), and a powerful engine. In the meantime, we moved a lot of computation tasks to the client-side thanks to PWA and JavaScript Hegemony.
So we made Webapps for years, developing with awesome reactive frameworks and bundling a lot of dependencies. We progressively moved from our simplicity to complex apps toolchains. We've become the new Java-like ecosystem. It sucks.
It's 2021, we've got a lot of new technologies to sustain our Users eXperience. It's time to have a break and rethink our tools rather than going faster and faster in the same direction. It's time to redesign the Developer eXperience. It's time for a bundle-free dev environment. It's time to embrace a new frontend building philosophy, still with our lovely JavaScript.
Introducing Snowpack, Vite, Astro, and other Bare Modules tools concepts!
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
React Summit 2022React Summit 2022
17 min
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
Top Content
Today's Talk discusses building flexible, resilient, and future-proof React components using composition and configuration approaches. The composition approach allows for flexibility without excessive conditional logic by using multiple components and passing props. The context API can be used for variant styling, allowing for appropriate styling and class specification. Adding variants and icons is made easy by consuming the variant context. The composition and configuration approaches can be combined for the best of both worlds.

Workshops on related topic

AI on Demand: Serverless AI
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Top Content
Featured WorkshopFree
Nathan Disidore
Nathan Disidore
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
High-performance Next.js
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Michele Riva
Michele Riva
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.