React-First Micro Frontends in Regulated Industries

Welcome, everyone to the session about React-first micro-frontends in regulated industries. I hope you enjoyed the conference so far, and I hope to bring you some new insights into developing scalable front-end web applications.

My name is Florian Rappel. I'm a solution architect working for a smaller company called Smartpjot. We are specialized in the creation of scalable IoT solutions. I, myself, am specialized in the creation of distributed web applications. Besides doing consulting work, implementation, etc., I'm also busy doing workshops and doing architectural reviews. And I would like to be in touch with you. So whenever you have the chance, come on and let's get connected on LinkedIn.

But enough about me. Let's just dive right into the topic. Before we can start, I need to give you a little bit of a terminology course. We are talking about the right thing. When I say micro-frontends, what I mean is that micro-frontends are the technical representation of a business subdomain. These micro-frontends allow independent implementations with the same or different technologies. They should minimize the code shared with other subdomains and are owned by autonomous teams. So what do I mean with all these words? Well, first of all, we mean that your web application is no longer developed by a single team. It's developed by multiple teams, which are working on different fragments, different parts of the same frontend.

In order to cut these parts, you need to identify subdomains. That means not technical, but functional areas of your application, which, let's say, have a common ground. So you wouldn't say team one only takes care about all the dialogues in the application and team two takes care about all the pages or whatnot. You would rather say, okay, so my whole domain that I have here consists of different subdomains. Team one, for instance, does everything with, for instance, product details, and team two does everything about pricing of something. So you will always, let's say, juggle these things around and potentially give something like a checkout or a basket to team three. That means that at the end of the day, these teams will not be, let's say, completely separated from each other. But from the end user's point of view, they will always come together on individual pages.

Sure, there are pages where just one team contributed, but it is very often that multiple teams will contribute to the content seen on a single page. Now, we could talk, of course, a lot about microfinance in general. But in this talk, I want to take a special subcase and that is microfinance in the context of regulated industries. So what are these regulated industries? They are a little bit different than, let's say, non-regulated industries in the sense that there are more strict rules to follow. As an example, in healthcare and pharmaceutical applications, you always have to get FDA approval and that requires you to follow a set of standards and also provide audits, for instance. Therefore, you can't just, let's say, publish whenever you want to. But for each, let's say, update that is not a critical hotfix, you will always need to go through the extra rounds to get everyone on board with that and have their proper authorities signing off on it. Likewise, industries like finance and banking or critical infrastructure, for instance, in energy and environment, but also food and agriculture are heavily regulated.

Now, what are these challenges that will await us when we create an application in those industries? So, first of all, as already mentioned, general regulatory, but also compliance regulations that you need to follow. As an example, for medical devices, FDA rules apply and medical devices are no longer restricted just to the hardware. The software is also really critical. So, for instance, FDA 21, CFR Part 11 is one example that could be mentioned here, which you need to, let's say, adhere in your application. Likewise, if you have an application in the automotive sector, you will need to follow things like ISO 26262, which is about automotive safety. And in there are a lot, of course, legal restrictions and rules and guidance that you need to follow and things that you need to provide as paperwork before going live. But safety assured, not everyone on the team needs to know these rules. It's just important that someone does. And this someone, of course, is then responsible for the whole application, which already is a little bit of a conflict, as you can already hear, with the independent nature of these micro-formats.

Now, we've heard automotive sector, likewise in aviation. We got some rules to follow. There are also some general rules which even non-regulated industries might conflict with you. For instance, GDPR rules or HIPAA rules, they might always come into conflict with you. Also there is the new EU Cyber Resilience Act, which might be something that you need to follow. And therefore, it touches you and you need to make sure that all your teams are on board with that and provide fragments following the guidance that is written in these documents. Another, and that's the last example in the sector, if you're creating an application for the critical infrastructure in Germany, what you need to have is you need to follow British V, and this British V also tells you what kind of security you need to implement in your application and what needs to be provided. Very often, penetration tests are mandatory for many of these regulations that are there. Now, many of these other things, they are fulfilled with the other challenge that we will face, which is documentation and audits. In order to provide the necessary paperwork to really see that you are compliant, you need to provide documentation.

Very often, penetration tests are mandatory for many of these regulations that are there. Now, many of these other things, they are fulfilled with the other challenge that we will face, which is documentation and audits. In order to provide the necessary paperwork to really see that you are compliant, you need to provide documentation.

So the question of course is who writes this documentation? If you have multiple teams working on it, and let's say things that just flow into your application naturally, you don't know what's happening there, who's providing the documentation, how to make sure that these things follow a general architecture, and you are responsible to actually make that happen? There is also, of course, the whole sector of alignment with these teams, especially with respect to regulatory documentation and other needs, but then also the fact, what can you share?

Because let's say if you have now multiple of these independent fragments for your front end, how can you make sure that, let's say a dependency you want to share is in fact in the version that will be compliant at the end of the day? And what if you need to change this version? What kind of effect would it have on these different independent parts? For a monolithic application, these questions can quite often be answered very simply, right? You just try it out and you just update and that's it. But in a micro front end solution, that is quite often not so easy because these things are independent and so you can just change it somewhere.

And what are now these independent pieces doing? You would really need to test now the aggregated application in all detail. And that gets cumbersome really, really quickly. So at the end of the day, what we have is kind of a struggle. Tension arises and in the end, there will be a lot of, let's say, friction and lightning potentially between the freedom that we desire and why we opted in for an architectural pattern such as micro front ends. And the regulations and the burden that come with this kind of fulfillment that needs to be provided here.

So what can we do here? As already mentioned, what we wanted to do is go from a centralized approach where we have, let's say, a monolithic application, everything is done by a single team. Maybe some of the people know everything that's going on there to a distributed approach where all the responsibilities and everything is fully distributed and not a single person knows everything. That is where we want to go. But again, the friction will kill us. It's just not feasible to go there. So we need to take a hybrid approach.

One potential way that could be taken here is the following. You have a central team. Usually it's the app shell team, but it could be much larger than that. Let's just call it a central team. And this team, it will give some boundaries, architectural boundaries. Ideally, these things, they can't be broken. So if you want to be part of the full application, you need to follow these architectural boundaries. There is not a way. So technically, you couldn't violate those, at least not easily. In practice, however, quite often it is a way to get around those. And yeah, there will still be some reviews, etc. required. But nevertheless, the aim should be to go for as strict as possible that it's not even possible to break out there.

The easiest way to ensure control in a microfront-end sandbox is to have all activities contained within it. This approach allows for a defined environment with limitations to prevent unauthorized actions. However, practicality and performance considerations may lead to a decision against a full sandbox implementation.

Distributed aspects like development processes, individual team responsibilities, and deployment strategies play crucial roles. Deployment does not equate to automatic inclusion in the full application; an aggregation orchestration layer helps select relevant microfront-ends. The centralized team shoulders the responsibility of setting boundaries and orchestrating the end-user experience.

To ease the burden on the centralized team, individual teams handle documentation and pre-validation. This empowers teams to ensure their microfront-ends comply with architectural and regulatory requirements. The central team's role shifts to communication, boundary setting, and providing self-validation tools for teams. Ultimately, the central team conducts testing and approval to ensure compliance and successful application functionality in both production and non-production environments.

So just because a team deployed version two doesn't mean we need to take version two or this microphone at all, we can just stay with version one. And the other is orchestration, meaning what gets provisioned for the end user. We can have feature flags and whatnot. Now, this is great. So far, this is going well. But maybe there's a lot now on the plate for the centralized team, which means we need to take a little bit of the pressure off here.

We can do that, for instance, by saying, hey, documentation and pre-validation should still be in the hands of the individual teams. So they document what changes they did because they know their microfront-end best. And they also make sure that it follows already all the boundaries that have been given, not only from the architectural perspective, but maybe also from the regulatory perspective. So that means the job from the central team is to really communicate these boundaries that need to be fulfilled to provide tools, for instance, that they can self-validate.

At the end of the day, it's really important that we get something that is as good, as fully validated as possible. Because the final step is that a central team does testing and approval. That's it, then. Right. So we fulfill all the regulations and we have our application running, meaning we have now a production app, we have a non-production app. And now here comes the difference on where we can really utilize that we are using microfront-ends. The non-production application, that goes, of course, to a non-production environment. But that here is not just indicated as a database for nothing. The basic essence here is that we only draw now the microfront-ends in that have been designated for non-production use, which could be the latest version of every microfront-end, just because we can.

However, in production, we really have a carefully set of pre-selected microfront-ends. So here we really took care that only the versions we wanted to be in there are in there. So how is this whole chain now looking like? We have our teams. Let's say here we have three microfront-ends, maybe coming from three different teams, and they just publish whenever they are ready or whenever they have a new version, something, they publish to a microfront-end discovery service.

Now, usually you could have your application drawing the microfront-ends directly from the discovery service. This is a great pattern and this works really well, but not in regulated industries, right? Because here we need to be careful. So what we can do is that whenever there's something published, we directly put it in a non-production environment, maybe not all of them, but a dev environment, let's say, and it's available. Great. However, for the production app or maybe other environments that are closer to it, we have a pre-approval step.

So we make sure to only select those that really seem to fulfill it. And then at the end of the day, the whole thing, what we selected for this production environment together with our production app, that gets regulated, gets approved, and this fixed composition is then what is shipped to the end users after we get all the audits and everything ready. So quite nice. We still have a little bit of a monolithic approach because we don't just, let's say, go into production. That is not the way here. But again, we need to stay within the regulatory boundaries. We need to be compliant at the end of the day.

What does that mean for the individual microphone that has just been published here? I already draw it not in isolation because we have our code, of course, that we write using React. And there are good advantages for using React because we don't have to care so much about the runtime version. We can actually say it doesn't matter if we started with 18. Someone might update to React 19. As long as we have no direct dependency to, for instance, React DOM, that works quite well. And this is a really great advantage of React, that as long as we are not using something deprecated, we could just update it. And there is never, to my knowledge, been a case where something didn't work so nicely. So that's really good. So we can do it and follow such an approach.

And then we have three kinds of dependencies. First kind, dependency that, well, is either rather small, rather specialized, or gets tree-shaken really well. And, again, has only a limited use and can only be seen, for instance, in this microphone. And one example, it could be lodash. We don't want to ship the whole lodash to everyone, but maybe just the selected functions that have been used in the code phase. Now, if we do that, as we can see here, the microphone in React just bundles that in and we are good because they can now verify that whatever they have is working and ship it. Now, there are two kinds of other dependencies, the shared dependencies. We have centrally shared one and React itself is a good case because, again, we should always use that. We shouldn't select our own version, maybe. And the app shell, which is the area where these are usually centrally shared, that one should always, let's say, bring more or less the latest version, at least some recent version.

And then we have other dependencies which are distributed shared, which means it's not coming from the app shell, but it's rather coming from a micro-frontend and that then only loads it if there is not a compatible version available yet. So, it means if you have two micro-frontends and both come with tons stack query, in this case, and both use, let's say, more or less recent version, then we just load it once. However, if you really want for some case to have an older version, let's say version 3 of tons stack query and the other one goes with 5, then, well, you will load your own version in this case. So, you will always bring those, but you don't validate that. Again, the validation context here in purple only, let's say, consists of your code with the bundled dependencies. Everything else you will do centrally. So, the centrally shared dependencies and all the things that are not distributed shared will be validated in the central context because only then you'll know also which version is really loaded when you have the selected set of micro-frontends. So, don't do work that is not necessary to do. Of course, if you already know the version you use has a vulnerability and wouldn't pass regulations or some compliance tests, then don't select it. As simple as that. Final thing I want to mention here before we look at a small demo is the following.

If you have now three micro-frontends and you want to take components from one micro-frontend, maybe another from another, you could think of an approach like this. You call a function like load component, whatever is this, or load fragment, whatever your favorite micro-frontend framework gives you. Then you have something like red page here. So, the name of the micro-frontend then maybe the name of the component. This is very standard, for instance, for module federation. You could do the same here with the TL microphone, TL dialogue, you load that. In my opinion, that is problematic in multiple cases. So, don't do that. That has nothing to do with module federation because even there you could reverse that flow. The main problem is that if that version of the red micro-frontend where, I don't know, page was chosen as the identifier is not there because you use an older version or maybe the interface changed or whatever, that will not work. So, this strongly coupled approach where directly grab a component from a micro-frontend is never a good thing.

Instead, go for a loosely based approach where you say, well, your central app shell has some kind of a registry and when the micro-frontends come, they just register their fragments that are necessary. For instance, I could register a page defined by its path and then the component. Likewise, I could register some other component here is called register extension as Pyrel, the Pyrel framework does it, give it a name and then the component. Now, what you can do with that is that in your component, in your other micro-frontend where you want to use that, you just have a special kind of component that you want to use, could be also a web component. Here, I use a React component called extension slot and this thing communicates with the registry from the app shell. Now, it finds all the registered components for open dialogue and it will render them at this location. This way, you get the component in there, but it's loosely, which means if you didn't register anything, nothing will show up. So great, nothing will break and also this app shell registry could make a validation and keep certain interfaces or contracts to be established.

Finally, I want to show you how it works in practice on a standard application, which is like a Netflix clone here. Let's say you have your discovery service, you could then even do things like setting a feature flag, which is the same as disabling it, but only selectively for some clients. So here, we just added for Pro and that means in Firefox, suddenly the surprise me button is gone, but also the content is gone. Everything is gone consistently because you work with it consistently. And that's the basic idea, right? If you have your microfrontends scaled up in a way where they can just work seamlessly and loosely together, then you can always make this composition. That's it from my side. Always get in touch, check out our discovery service if you want to have a look at that. We can always, of course, also book a free architecture session. Get in touch with me on LinkedIn if you want to discuss micro-frontends in general, or of course, if you're really keen on the discovery service, that's the missing piece for your architecture, scan the QR code, check it out, get a demo of it. But otherwise, have fun coding and always follow the right steps to stay compliant. Have a great conference.