We Accidentally Built a Plugin SDK for Micro Frontends

Welcome everyone to the, as mentioned, last talk of at least this track. I'm first and foremost super excited to be here. One of the reasons is that this is actually the first time I'm talking at a conference, and the other reason is that I will be sharing how we accidentally built a plugin SDK for microfrontends, which I refer to as microfrontends on steroids, but the responsibility in me put in the disclaimer, so really bad.

Quick intro for me or about me, it's, my name is Andre, I'm a principal engineer at Betamax, which is a Berlin based education tech company and happens to build, have built the world's most advanced adaptive learning and teaching systems for school. So besides, as mentioned, building digital products, I love to build actual things also, so in case you get already tired about talking about code, then hit me up and we can talk about woodworking or water sports for that matter, but back to the topic, how did we get there?

In order to answer the question, I want to give you a little context of the problem we are trying to solve and how we ended up in the position of having to solve it in the first place. So I'm old, which is not the root cause of the problem of course, but it means that back in 2008 when Betamax started development, I was amongst the first developers who, who kicked us off and we built a traditional multi-page application powered by PHP, which got us quite far.

In fact, so far that four and a half years later, we were able to announce that Uruguay has chosen Betamax to provide all math material for all the schools, which was a huge win back in the days, but it also meant that we will have a problem pretty soon because from the data we got in Germany, we know this setup would not scale on the level of a whole country. So, we thought it would be a nice idea to build a single page application, hot shit back in the day. By chance, any one of you know, when React was open sourced? One month later. So I think it's time to address the elephant in the room. We are at the React conference, but at this point in time, we went with the only reasonable choice being AngularJS.

So we, we in fact built the app, we shipped it and we built upon this base ever since actually. So, but fast forward, nine years later, the inevitable happened and Google discontinued the long-term support for AngularJS. I mean, quite some time to be fair. Um, at this time I was, I already rejoined Betamax, uh, with a mission to come up with a plan of how to iteratively migrate from AngularJS to React. So I rooted for a micro frontend approach and we executed it with a single span, which is basically a JavaScript router for micro services in the frontend. And it differentiates amongst other things, different types of micro frontends, which I will quickly explain because I will use the terminology moving forward.

So we have apps, of course, which are just like any other single page app, but without an actual HTML page. We have a root config which provides this root HTML page, it handles app registration, mounting, unmounting. So it is responsible for the whole composition of the micro frontend setup. Then we have utilities to share common logic and like services or component lib and we have parsers to share UI between frameworks. This will be important later. Um, our proof of concept was fairly easy done. So we implemented the navigation and react and kept the content area as a stripped down AngularJS version with bespoke bootstrapping process for the app, which worked pretty nicely.

So we put a whole team on it and started developing fast forward to this point. We now run a full blown micro frontend setup where apps can render parts within other apps where we are currently at 58 micro frontends and still counting. We have services, utility micro frontends that provide shared APIs, including global state management and behind the scenes, we do this with RxJS quite heavily. And yes, we still have some use cases in AngularJS, unfortunately, but we are getting there. Um, yeah, I did promise you that. I know.

Um, but first what are we trying to achieve actually from a goals perspective? So, um, we want to have no or close to no coupling between applications. The root config is the one and only place that controls the composition of apps. We want to be adaptable. That means, um, the composition of these apps is based on roles, permissions, licenses, feature toggles and settings so that different users can put, could potentially have different user experiences. And from an architectural standpoint, we want to, we aim for separation of concerns, encapsulation and bounded context on micro frontend level.

Yeah. So without further ado, I thought it would be a good idea for your very first talk to go with a live demo because why not? Um, so this is better marks from a student perspectives. We are looking at one of the most hated views from a student for students because when stuff shows up there, it means homework, usually. And the content there is just one of the most hated views for students. And the content there is from our practicing product. We also have a different one that is called teaching a school book, which is a digital replacement for physical student school books.

Um, the red line at the top marks an extension point that we call portal slots. Nothing shows up here. And I will show you why, because the feature toggle is not active. So if I, if I activate this feature toggle and reload. So now content shows up. Yeah, fair enough. So this is stuff that teachers distributed to the students to look at. And in order to understand our approach, I will walk you through the bootstrapping process of this page. Now you already saw the feature toggle. So root configuration takes care of registering apps, as I mentioned. So it has, uh, it knows about the user. Therefore it knows about potential licenses and if the license match or is sufficient, we also register the assignments app, what we just saw, the homework stuff. Then for activated feature toggle school book, we also, um, register the learning register, the learning units app that provides the distributed, um, content from the school book product, whether or not an registered app is active, is determined by signals bar for it by executing the is active function for every registered application. And this case, um, the route for the assignments and the allocated learning units match. So both are, both are mounted at this view. If now one view wants to offer one of these port slots, they just have to use our portal store with the desired slot, which will get them a callback ref. A component that wants to render into one of those extension points, a.k.a. portal slots, use our portal renderer to get a custom create portal function that will take care of rendering your content into the correct DOM node once it's mounted. And the really interesting part happens in our portal service.

Therefore you need to know what a behavior subject is because this is what it's based upon. In RxJS behavior subjects that we use to publish our set of mounted extension points, um, on, takes care that every subscriber will always get a value. So once you subscribe, you either get the initial one being an empty map, or if you come late to the party and stuff has already been published, you will still get the most recent value, which is important to keep in mind when we talk about timing.

Our use portal store hook that is responsible for getting you the callback ref on the other hand, takes care of the life cycle of this component. So if it's mounted, we are looking at this line here. Then it will trigger a dispatch or it will trigger a publishing of, of the current updated map of mounted portal slots on that storage. And if it, and if the target node unmounts, it will delete itself from the map of available portal slots and also publish it on, on this portal store.

On the consuming end of things, the portal renderer on the other hand, this one will subscribe with a desired portal slot on that storage. And if there is a DOM node mounted where it could render into, then it returns the react-create portal function so that can be used in the component, um, to render to the desired target node. And actually that's about it. Like 80 lines of code that took pretty long to come up with. And if you're not as excited as I was when we pulled this off, I don't blame you, but, uh, hear me out.

So quick recap, the app responsible for the main view offers one or more slots by using our previous portals, which we talked about. The app responsible for the main view offers one or more slots by using our portal service hooks. What will be rendered into those slots depends on registered micro front-ends and mounted micro front-ends. The secret sauce is that by publishing mounted slots on an RxJS behavior subject, we eliminate timing issues with lazy loaded bundles and order of rendering, because if you imagine you have a huge setup with different micro front-ends being lazy loaded, you have to take care that you have on the one hand, the target node has to be mounted, but also the app that will be lazy loaded and so comes late to the party, as I said, um, also has at some point knows when, where to render into. And by having these, um, bounded context or isolated, um, bundles on, um, isolated bundles, we also isolate runtime errors. And what that means, um, is that in case a developer messes up and I know this barely happens, but, um, in case it happens, the only thing visible for the user is that some content is missing in case for homework, students will be happy. Usually the teachers won't be, but the whole app is still functioning because it's isolated in just one app that is using an extension point. So if you think of this approach at scale, it means your application or our application for at least is pretty resilient towards a human error or infrastructural problems like endpoints not available or bundles that could not have been loaded. Um, and furthermore, it is super easy to determine or to predict the state of your application because we have exactly one place where the composition is determined, which is the root config. And therefore it's, and there it is based on licenses and feature toggles as I mentioned. So it can be easily tested. And from a product perspective, on the other hand, if you have quite a lot of these, uh, apps responsible for bounded context, that means you can use them in different compositions to build up different use cases. So I would dare to say we actually built a plugin SDK for micro frontends, which is not yet ready to be like shared in the world, but for our users, this is our use cases for our needs. It suits very well.

And I think we have time for one more thing because I don't know if anyone read the whole pitch. I also claim that we can render REC.js within AngularJS. And yeah, so here we are. This, the nice little widgets on top are widgets from our teaching application rendered within the old school AngularJS app. And now I hope you paid attention. Um, how we actually do this is super straightforward. Um, we have the concept of passes. I told you where we can share UI between different frameworks. So I created a parcel that does nothing more, but providing a portal slot. This portal, portal parcel, naming is really hard, um, can be imported in AngularJS by using system.js. Therefore we, and with this approach, we get the life cycle functions. We configure the parcel properties that are needed and in the AngularJS template.

Yeah, this is how an AngularJS template looks like. We can use a parcel element directive. And this is how it's called an AngularJS that will take care of rendering your parcel. Luckily, single-span offers this for very, for quite a lot of frameworks, actually. So switch, view, you name it. But from there on, it's back to what you already saw. So we will have a react component being a report the slot in AngularJS and everything else is what you just saw. So pretty easy, pretty straightforward, but was a great effect. And actually three minutes early, but this is all I have for today.

The QR code leads you to a gist I created on GitHub where you find the portal service, this a very basic example. So you can play around if you like. Hit me up on LinkedIn, if you have questions or later, I mean, better in the speaker, the Q and A corner, but yeah, that's about it. Thank you so much. That was such a good talk. And what was hilarious as well is during the talk I was listening and you were describing what you're going through. It was like, yeah, it's a micro frontend. Oh yeah. That's the point of this talk.

You mistakenly built a plugin SDK for micro frontends. That was really interesting when you started talking about Angular, I was like, where are we going with this? And you were like, oh, yeah, that's a good point. We actually do have a bunch of questions coming in. Remember also that you can rate the talks as well. So a five out of five as well would be great. And let's just dive straight in to our content.

The first question was about sort of the different microservices that you have and how do, can they communicate between them, are there ways that they can let another sort of micro frontend or piece know that something's happening? Yes. So I mentioned the services, utility micro frontend. This one, there are quite a lot of React services that use RxJS under the hood. So whenever you want to have cross application communication, you will do this via the service because this one will always be mounted so it is in, it has a cross application communication. So it is in, it is, has a state that is persisted and with RxJS you can really build really nice pipelines via transformation filtering, and you can notify basically without coupling to another app, you can just push it out there and interested parties could subscribe to these events and act accordingly.

Another question that's come in, this one's from Ross. Oftentimes when you work with micro frontends, deployment gets a little bit tricky and can grow into a big problem. How do you handle deployment of each of these micro frontends and a show application and are they deployed together or deployed separately? So we would love to be in a state where we can deploy only a set of affected micro frontends. We are not there yet, unfortunately, because this is just two and a half years old or so, so currently we deploy all frontends together. We aim for the deployment I just mentioned where, you know, you have updated one micro frontend and other depend on them so we know, okay, we have to deploy these four.

Another question from Ross again, which was about breaking changes. So how do you handle breaking changes between micro frontends and the main shell application? And to main what? Main shell application. Well, if a team wants to introduce a breaking change in their, in the microfrontend they are responsible for, you have to start talking to other teams and then make sure you, as we deploy in one go that you also provide that you also address these breaking changes and mitigate them. No, absolutely. I think this is interesting because, and I kind of want to add to this question where there is the technical parts and then there is also the team management, getting the team to work together part of this question. Yes. So imagine, so I said we have 58 micro frontends. That means we are obviously not just one team working on these.

Well, if a team wants to introduce a breaking change in their, in the microfrontend they are responsible for, you have to start talking to other teams and then make sure you, as we deploy in one go that you also provide that you also address these breaking changes and mitigate them.

No, absolutely. I think this is interesting because, and I kind of want to add to this question where there is the technical parts and then there is also the team management, getting the team to work together part of this question. Yes.

So imagine, so I said we have 58 micro frontends. That means we are obviously not just one team working on these. So we have, I think four or five teams now working on this monorepo. And so there is a lot of talking going on, on a weekly basis and on demand. So yes, it needs some coordination for sure, but it's also leads, um, leads to a nice exchange between those teams. Absolutely. Teamwork and collaboration is always the key. Always the key.

The next one is about sort of local development environments, uh, especially because you've got, uh, quite a lot of different things going on. So how, uh, are you handling or how are the different members of the teams handling, uh, local developer environments between these different micro frontends?

Well, it depends. Um, I wish I had the door for every time. I know that answer. Yeah. So when you're focused on front and work mostly, um, what you just saw were my, um, we call it micro stack up and running, which is, which is a whole mock backend, uh, based on just Node. Really simple. Um, there are other, uh, when you, when you want to, want to work full stack, we have, um, we have a Kubernetes desk stack that is supposed to run on your machine entirely with all the effect, uh, backend that you need, because also on the backend side of things, we have microservices. Um, so yeah, these two options run it completely locally with mocked backend stuff or, um, the full blown application.

And I'm guessing that's probably something that is going to start to include the preference of particular users or what they need at what point into developer cycle as well, development. Yeah, fair to say. No, for sure. For sure.

And another question is about module federation. Have you considered using module federation concept to share code between parcels? Well, I think what I might, should have mentioned regarding parcels is that we try, not we try, we stayed away from, from this as long as possible. And this very specific example you just saw was solely made by me for showing off purposes to be really transparent here because it adds a whole another layer of complexities that we try to avoid. So, because it is always an in-between solution. Our goal is to get rid of AngularJS really soon.

So we don't want to make it tempting for product people to come up with new feature ideas where you can just put a parcel in there and here we go. So we haven't considered it. We don't use, we don't use parcels in our production app. And that's actually just made me remember that the whole reason they started is because of migration. That's the driving force and balancing migration with kind of moving forward must be something interesting that your team has to kind of. Yeah, it's interesting, demanding on every single level. So once we have to communicate to product people that we won't touch this code base unless we have severe bugs. So we don't feature development and the legacy code base and we go from one use, one use case after the other in terms of migration. So there's no like little improvements by just adding some React stuff to our existing code base.

And this is a kind of a different question that's about what you're building and more about how you're testing it. And you showed us the config and how you can switch between different config permutations. And this person has asked, how do you handle end to end testing between all of these different config permutations? So we go through the whole testing pyramid. So we have, we use react testing library on for low level testing, for doing and use snapshot testing for testing what would we expect for mounted micro front ends for every route and one level higher. We say, okay, we do integration tests for every setup where at least two micro front ends are involved besides the navigation one that will always be mounted. And then at the last stage, we do the really expensive end to end testing only for smoke tests. So we have quite extensive integration test suite. Yeah.

And I love how you kind of use the right level of resolution with your testing for whatever you need. And this kind of relates to another question that came in, which was about testing the interaction between micro front ends. So you talked about being able to select the test when these two micro front ends are involved. Can you also test the interactions between them? Well, if you want to test interactions between them, you have to rely on integration test because this is on unit test level. You just can't. You have to mock.

Now, great question. I was waiting for this one. No.

We're nearly out of time, so this will be the last one before we get to the most important question under this. Can you have different versions of React for each micro front end or do the micro services, micro front ends, I guess, share a version of React?

Now, great question. I was waiting for this one. No. So this is one of the basic limitations or one of the most important limitations that you have to keep in mind. We have one React and one version of React only, which is a so-called shared dependency, meaning it's of course not bundled with each and every micro front end. So we have one version of React, one version of AngularJS, nothing more. So yes, updating this can get pretty hard when you think of 58 micro front ends, but that's how it is.

Awesome. And honestly, when I saw it on the slide, I didn't realize the elephant in the room joke, but then after seeing your shirt, it really, really drilled home. For those of you who maybe are in the back, you can't see, his t-shirt is the schematics or the floor plan of a room, but if you look closely or you squint, you can actually see an elephant in that room and it's a really great t-shirt. Where did you get it from? Yeah, it's a t-shirt designer from, I think New Zealand originally, it's called Glenz, G L E double N Z. So, and once a year I order a bunch of t-shirts and ship them over from the US. So, Nice. I love, I love that t-shirt. And if you maybe want to find out where you can get that t-shirt, you can find him in the speaker Q and A room later, but also where can people find you online if they want to follow the work that you do? But, so I mean, mostly on LinkedIn, my work, I won't, I have not really, not really much to publish because my main focus is better marks and this is not in the, in the open. You can try to DM me on, on Twitter, it's defthisdog, but I'm not really active there. Well. Okay, LinkedIn and also catch him in person. And if you are online, you can also join the speakers Q and A virtually as well. Can we give it up for him one more time? A big round of applause. Thank you.