8 Things You Did Now Know Micro Frontends Can Do

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.