70. Microservices Bootcamp 3 – Micro Frontends

Rich: In Episode 70 of Mobycast, we wrap up our bootcamp on Microservices with the discussion on Micro Frontends. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. Let’s jump right in.

Jon: Welcome, Chris and Rich. It’s another episode of Mobycast.

Chris: Hey, guys. It’s good to be back.

Rich: Hey.

Jon: All right. Great to have you here again, Rich. We’ve missed you last week.

Rich: Yeah, I’ve finally got a week of vacation behind me. I’m relaxed and now underwater, trying to play catch up.

Jon: You went to the presidential retreat in […] park?

Rich: I did. We were actually the closest house to their compound and all signals were blocked. I couldn’t get calls, wifi was decent but spotty. It was nice because I had a real excuse to not get work done.

Jon: Great. It didn’t fully work because I remembered talking to you a couple of times last week, but thanks for the extra effort just by being on vacation.

Rich: I don’t know yet how to break entirely. That’s a lesson that few have learned in my position. You have, actually. You’re the best of that.

Jon: No, no, no, no. I’m always available.

Rich: You’re always available, but you are able to vacation. You’ve figured that out.

Jon: Right on. Chris, what about you? What have you been up to?

Chris: Just enjoying summer. It’s been here in Seattle so we get a lot of bike riding and today it feels like March or April. Go figure. It’s July, it’s raining, and maybe 60 degrees. That’s just really weird for this time of the year. Looks like, hopefully, we’re going to have a couple of days of this, and then summer really, really, kicks in. I’ve been enjoying getting some miles on the bike.

Jon: Fantastic. Whenever the Tour de France is on and I see people biking around, I know that they’re putting in a little 15% extra effort just because the tour is on.

Chris: Yeah. I’m a little cycling junkie, so yeah, I’m watching the tour everyday. I can tell when I’m not on my bike, climbing up the hill, it’s like I’m suffering like a pig. I think back to the images that I saw on Tour de France are like, “Come on. I can’t go as fast as him, but I can suffer as much as he can, so keep going.”

Jon: Right on. Speaking of suffering, today we’re going to talk about Microservices applied to UIs. This actually does sound hard and it sounds like it could be something that can cause, it seemed, to suffer, but it might be worth it. These things are called Micro Frontends. I don’t know much about this concept. Chris, you were saying, maybe nobody does because it’s a fairly bleeding edge thing, but it’ll be part three of our Microservices bootcamp. Those are the words I was trying to say earlier. Let’s get into it. Tell us what we’re going to learn about, Chris.

Chris: Two previous episodes in this series was all about traditional Microservices, what they are, what they’re good for, some guidance, and tips and tricks on how do you actually use this in the real world, especially if you have an existing codebase. Today, we’ll be talking about can we take that concept of all of the good benefits that we can get from Microservices, why it is so popular for backend code, and can we apply it to the front-end code? Can we actually apply it to our UIs?

It’s an interesting idea. It’s all about decomposition. You’re splitting things up into separate independent entities. Can you deliver a cohesive single page web app in this style? That’s the whole idea behind Micro Frontends. As we get into it, we’ll see it definitely, some of the exact same benefits for sure, but probably much more in the way of challenges with UI.

Jon: You’re probably going to tell us a bit more about what this is. The first thing that comes to mind is that this is different than what frameworks like React or Vue or Angular trying to accomplish, where they are trying to break things down to component, but only different components still live within the same code base and are part of the same overall JavaScript app that’s running in the browser. This is […] then even more than that?

Chris: Yes. You can think of them, basically, as single repo. It’s single and all the code is contained single repo. That whole thing is standalone. By itself, it doesn’t really exist without that code in that repo and it is independent. That’s what all of those framework and the traditional style that’s really what by and large […] is doing. Micro Frontends applied to that would be breaking that up and now you have, say, four repos. Each one of those is independently standalone. They come together at the end of the day to form that same single page out, but it’s four separate projects.

Jon: Tell me more.

Chris: Setting the scene for this, like why we talk about this and whatnot. For me personally, going back maybe three years ago, real world project, not a huge development team, but fairly larger, probably about 20 people big, and trying to build a pretty big web application for customers that had various different subcomponents to it. This was for the company Arivale which was a scientific wellness company. Very, very complicated business in that. It dealt with lots of medical testing for all these customers. They get their blood test. They get genomic testing. They get stool examples done for microbiome. They had behavioral aspects to it. It’s on them and find out what they’re doing from an exercise standpoint. They would be paired up with coaches that would talk with them, communicate with them, come up with plans for how they can increase their wellness. Then, they have the follow-up on that like how well you’re checking against that.

We had many subteams, each one of those responsible for very large components of that. We were faced with, how do we go in and build this big application that has a fairly complicated UI and make sure that it’s consistent across these different subteams. That’s when I started looking into this whole, can we build this? Do we do this as a component or a plugin style architecture where we can have a main host—a parent application—and then have each one of these subteams independently go build their particular pieces. The coaching team goes and builds the coaching app. The visualization team goes and builds the app for visualizing all the medical information. The behavioral team goes and builds the app that’s purely about goals, your habits, and how you’re achieving on that stuff. 

That was the motivation for doing that was how can we do this? Spread the work across so many people, have these independent teams that are going and working on but still have a single cohesive application to the end user, so that to them, everything looks uniform. We explored this model; we’re doing that. 

At the end of the day, there’s not a lot of support for this. The tools, the library space, not a lot of their folks have done this. It was going to be a lot of heavy lifting. Of course, the business needed to deliver and ship apps. We ended up not going in that path. It’s interesting now. It’s definitely latched on. There have been real world examples of people doing these and being successful with these. It’s a good time to talk about this. Again, it’s going to be really applicable for folks that have teams that are bigger than one team. 

Jon: Before we get into more technical details, there are two things that come into my mind, too, just as a prelude to this. One is the Kelsus project that we were working with the team that had already built the Ruby on Rails app, that did a bunch of stuff to connect people to lawyers. Basically, let people browse a directory of lawyers, see what they’re good at, and communicate with them a little bit.

Then, Kelsus came along. We were supposed to build the meeting and scheduling component. That meeting and scheduling component, we wanted to do it with Node.js backend and React’s our frontend. The existing thing with the full on Rails monolith. Not only that, but the seamless switching that Rails monolith for whatever reason to reject Python Django monolith. I just really don’t understand why they were doing that, but that’s what they wanted to do.

We built this part of the UI that looks like its own page where you could click something in the Rails app that would take you to this other page that’ll let you schedule stuff, walk through your scheduling workflow—there’s several pieces in the scheduling workflow—then end up back in the Rails world with the thing scheduled, you could see that scheduled thing in there. As you can imagine, there are lots of little integration point between the Rails app and the Node app. Some of the hardest parts of that integration was just keeping and making sure that person was still authenticated. 

We did a hacky thing where we just passed some of the cookie information from one app to the other because both apps were in the same domain. Then, we could look at that cookie. If we had a match for that cookie in the […] database, we could be like, “Oh, yeah. For sure, that person must be logged in.” Sounds hacky and we could have done it in a more grown-up way by having an overall OAuth thing like a one login or something, managing the overall authentication experience across apps.

It feels like it’s a little bit in the direction of what you’re talking about. There is a seamless integration between the two apps. You can jump from one to the other and back. They all looked the same and we even pulled static content from the same endpoint that the Rails app pulled static content from. Is that what you’re talking about? Is that getting in that direction where we have a Micro Frontend just for that one feature?

Chris: What you were doing is exactly the reason why we’re talking about Micro Frontends. It’s the same reason you basically have multiple teams that are working on Frontend code. Sometimes you want to use different technologies and different tech stacks. You get one of those benefits of Microservices in general. This is the exact same thing with Microservices. You’ll want to be able to split up your architecture you did on the multiple teams. You want to be able to use the tech that’s most efficient. You want these things to be independent and then it’s just a matter of how do you integrate it all. From that standpoint, you can call it what you’re doing there.

Another example, Micro Frontends. We’ll get into this more. The implementation—how do you actually implement these things? What are some of the things you have to pay attention to? You alluded to some of that stuff. Communication between the separate apps is a huge piece of this. The way you had to do the communication was through cookies. Not the most robust way and not a very tight cohesive way of communicating between them. You also probably in a […] situation, but again, this wasn’t full of Micro Frontend. You really couldn’t change one that much.

Jon: Last thing. Those of us that have been around for a little bit, we still haven’t gotten to the implementation details of how you do this, but those of us that are listening that have been around for a little bit might say, “Wait, Chris. This is just portals. Everybody’s got portals. Don’t try to sell me out a new word,” right?

Chris: Yeah. Let’s go way, way back.

Jon: Go online and look up RSP to make a portal for an enterprise company. You’ll find a hundred.

Chris: I’m thinking back to the days of just MSN, Yahoo!, and AOL. When I was back there, Microsoft way back when we walked to work in the snow, we had a team called the portal team. That’s basically the homepage for MSN. They’re similar and you have multiple components that are composited together to deliver a single page. The big difference there was there was no communication between the components at all. You can think of it like the way newspapers do layout. They figure out what […] and they leave open blocks for these […] to go in, and they just fill them in. It’s like what portals really were and are.

Jon: Okay. Now, what are these Micro-UIs?

Chris: We’ve covered this in these talks and view some of these examples and what not. Again, taking the Microservice architecture concept and apply it now to the front-end development, not just to backend development. It’s not just services like exposing APIs. It’s actually UI applications and developing them in a Microservices style. Think of this as app construction via composition.

Jon: Sure, but I want to know more, do you have a bunch of IFrames in your page? What is this?

Chris: We will get into that when we get into more the implementation. For now, we can stay with the definition like Micro Frontends. They have a hosting—a parent—application if you will, that’s allowing these things to be plugged into it, inserted into it, and perhaps even taken out. They’re independent sub applications that are being hosted by that parent. Then, there’s communication between them. That’s just from an overall definition of how these things look. Then the implementation, there’s a million ways to implement this and we’ll talk about some of the pros and cons of how that works.

It’s constructing your app via composition. You’re splitting your UI into multiple applications. Each one of those projects is developed, tested, and deployed independently. Even though now your application is split into multiple different projects, they all come together and they integrate it into that single page app. That runtime shell is responsible for presenting. For the end user that using it, to them they just see a single app. They’re not thinking this is for separate things. It’s just a single app.

Jon: I would imagine one example of this would be Gmail. You have Gmail, it’s got your email in it, and then, off on the corner it’s like this Google chat thing. Everybody has that experience. I’m sure that the Google chat part of your Gmail page is not in the same repository as the rest of Gmail. I can almost guarantee it.

Chris: I would absolutely agree with that as well. Again, how much this falls into a Micro Frontend?

Jon: […] Otherwise, we’re never going to know. We have to get into the implementation details in order to know what these really are. We’re looking at examples. We were saying yes, that maybe Micro Frontend, but it’s not officially a Micro Frontend. In order to know what’s the difference between this new official Micro Frontend and what we might call as just separate apps that we built like Google did or like Kelsus did in the past, we have to know what’s the implementation details on Micro Frontend are. Maybe we can do that, and then, after that we can talk about some of the benefits of using Micro Frontend. Would that be okay?

Chris: Yes. For us, if we just stick for this particular discussion, Micro Frontend we’re talking about, there’s some parent application that allows sub apps to be hosted within it and there’s communication architecture between them so that the parent app knows that they are responsible for doing things like routing and initializing these apps, managing their life cycle, that communication between them.

It’s actually been designed from the beginning to be this integrated cohesive thing versus you’re going to find lots of shades of gray out there in the real world for things like Gmail and GChat. That is something that is definitely not part of the original architecture. There’s probably not these robust communication channel between the two. Instead, they figure out the same way for those two things to talk. It can very well just be a post to some API to pass information or whatnot and that could be posted in an IFrame or something. In the real world, we’ll see lots of examples of applications that are moving towards this. 

Jon: Yeah, like multiple applications composed on a page, but not necessarily with this in mind.

Chris: We won’t call them strictly like a Micro Frontend. They are being built that way because of the benefits that Micro Frontends give you. It’s all been driven by the same benefits. You want to have multiple teams working on independent code bases, you want them presented to the users so they really don’t know or care that it comes from separate apps. You want things to be able to be deployed independently. They were built that way and they exist that way because of the strong benefits that you get. That’s just the way they were implemented, it’s not necessarily what we’re calling Micro Frontends.

Rich: Hey, this is Rich. Please pardon this quick interruption. We recently passed an internal milestone of 50,000 listens and I want to take a moment to thank you for the support. I was also hoping to encourage you to head over to iTunes and leave us a review and a rating. Positive feedback and constructive criticism are both incredibly important to us. Give us an idea of how we’re doing and we’ll promise to keep publishing new episodes every week.

Okay, Let’s dive back in.

Jon: How are they implemented if that makes it a Micro Frontend?

Chris: They […] some of the differences between Microservices and Micro Frontends. They share a lot of the same terminology, they share a lot of the same benefits, but they are implemented, there’s some limitation differences here.

Microservices, each of those services are typically standalone. They’re not typically hosted within another service, although they can be. They’re just not typical. In that case, it might base your library or you could say it’s […] dependencies or whatnot, but for the most part, they’re standalone.

Composition is happening outside of them. They are routing with a reverse proxy such as a load balancer type thing versus Micro Frontends. They have that parent app, that shell, and these things are now running inside of them. It’s a bit more modular or library style. It’s the component plugin style of architecture.

In that sense, it’s more like a monolith, like a low design monolith in a way. You can think of it as a low design monolith is a parent shell and then you have the various pieces. If you designed it really cleanly and modularly, then you might have a module for authentication, you might have one for logging, you might have one for the ecommerce part of the site, you might have one for the profile or something like that. It would probably be more analogous to that. 

Jon: Now we’re getting where I wanted to go. That is a fundamental thing I wanted to know. Are the things IFrames or are we actually able to call JavaScript functions because we’re loading JavaScript into that interpreter? These other “standalone applications,” they’re really just JavaScript that you can call directly from your parent application. If that’s the case, that helps me get my head around this.

Sounds like it’s the latter. You really are loading up some JavaScripts, the interpreter has access to it, and all the dangers and everything comes along with it, you might have just blown away, rename something that was already there or whatever. It’s interpreted language, so everything happens at runtime. You have to be careful with your naming and everything like that, but once it’s in there, you can call it, you can do stuff, you can run functions and look at the results. Those functions might call an HTTP service like they might call a Microservice, yes?

Chris: That is getting more into the nuts and bolts of it—the implementation—what does this mean. It’s definitely not just this, “Hey, I’m loading up an IFrame. It’s a whole another web app hosted inside that IFrame.” That’s not a Micro Frontend. That’s not what we’re calling a Micro Frontend architecture because it doesn’t have that integration and with the rest of the communication channel and just being a cohesive app.

Jon: You could, right? You could have a bunch of IFrames making each other open WebSockets, you can have one IFrame do some stuff that changes state, and the other IFrames are listening to the WebSocket that tells them about states. It looks like it’s all a signal thing, but it’s just really […].

Chris: Yeah, but how do those IFrames share information with other IFrames?

Jon: Via the server. The IFrames are like, “Hey, I’m doing this, I’m doing that,” and the server’s like, “Okay, anybody that’s listening, this is what’s happening.” The other things that are listening are like, “Oh yeah. I’m going to change the way I look because I just heard something that happened.” They might not be aware of the other IFrames where things are happening, but they just know that they have to update itself whenever it gets the command or a message down from the WebSocket.

You can do this it’s what I’m getting at, but like I said, it’s a lot of work.

Chris: You can do it, but please don’t. 

Jon: When I told you about that Kelsus story about we had our whole separate React app and he was at his own page. It was implemented as an IFrame and there are parts of the outer page that had to be updated when inside the IFrame changed. The outer page had to ask the server. It was like, “Server, what’s going on?”

Chris: Again, it’s a good example. When we talk about Micro Frontend for the purpose of this discussion, what are some of the features and what are some of the characteristics it has? Again, having that communication channel with things being able to talk to each other and being a cohesive architected app, you wouldn’t have to do these kinds of… 

Jon: Tell us the name.

Chris: Yeah. What you’re describing there feels it’s multiple clients. It’s a client-server application, multiple clients. Each one of those IFrames is an individual client. You can use WebSocket or something like that for receiving basically push notifications when things do change and you go on update versus with the Micro Frontend, you can keep all that communication right there inside the browser, not having to go over the inner tubes. They notify when those things change. One app to another one can just see that information, that channel exist. That’s one of the big differences here and the benefits of going down this route, of having a full Micro Frontend.

Along those lines, when it comes to the implementation of these things, what are some of the things that you need to take into account that you need to deal with? You think about routing and loading apps. You have this parent app, it’s going to be responsible for running the request to the appropriate app, loading and unloading those apps. It’s going to have to manage the app life cycles as well, like when a page reloads. It’s going to be responsible for establishing that communication channel between itself and the apps.

Then you have to decide, how does communication happen? Is there any direct app-to-app communication or does it all go to the parents, whatever, but that’s an implementation detail. You’re going to be thinking about shared code and how these apps get access to that code. Maybe this is exposed to the interfaces of your parent shell. You’re defining what those interfaces are, what services are going to be available, what common services are basically available to each one of these apps.

We’ve talked about this, we’ve been to it several times, but just from the standpoint of implementation IFrames, don’t do it. You’re really going to want to have that parent shell application to give you all those benefits that we’re talking about versus the IFrames. It’s really just a collection of independent apps that can’t really talk to each other in an efficient manner. 

Jon: We talk about different apps and I’m still trying to give my head around what that means. In your mind, are you implying a particular framework like ReactiveX? Because ReactiveX does have a concept of an app. Are you imagining there’s multiple React apps running inside a parent page? What do you mean by app, is what I’m getting at.

Chris: In this particular case, you can think of an app as a bundle. It’s a bundle that’s built independently and it’s deployed independently. Just like in a normal single page app like a React app or Angular app, that’s part of it’s startup. It’s going in and it’s getting that bundle and loading up that JavaScript.

You can think of Micro Frontend as being the meta version of that where it has its own bundle, loads up, and then it has some way of being told, “These are the other apps that are part of it. Go fetch those bundles. Also, have a way for those bundles to be updated while I’m running this well.” As far as, is it a full blown React app? Is it Angular app? Is it Vue? All of those are going to end up becoming very implementation-specific.

The other thing that’s really important to call out here is, this is not a robust mature architecture pattern. Micro Frontend is definitely not something that a lot of people have done. I’m not really sure there’s any good libraries or frameworks out there that actually support this kind of architecture. There’s plenty of Frontend frameworks out there for dealing with single page apps, but I’m not sure that there’s really any out there that are addressing the Micro Frontend framework, if you will.

Jon: You could, if you want to, have a React app, it can have different components in it, and it can be like, “Hey, guess what? I’m putting my different components and different GitHub repositories.” You can do that and make those GitHub repositories sub modules or something, but you’ll just live with pain because your React app won’t run unless it has all the code that it needed and all that code would need to be served somewhere from the same place. 

What I’m hearing you say is that you’ve got to build something—again, maybe it’s a React app—that’s like “I’m going to go get these things, these different URLs, and those things. Once I’ve got them, they’re going to turn themselves into the component.” That’s not quite how React works.

React works by getting everything all at once and loading it. What you’re saying is, “I’m going to get everything and load it. Oh, look at these smaller pieces. They come from URLs. Let me go get what’s in those URLs, and then inflate whatever comes back.” Even beyond that, you’re also saying, “Not only I’m not going to get this thing at this URL and inflate it, but every once in a while, I’m going to see if there’s a new change to that thing so that if this person leaves this page up for days and then end up with an old apps […], we can still go get the new one.”

Chris: Absolutely. For implementation standpoint, what makes this different is you need to build that parent shell that runtime. That is a big, hard, heavy piece to go built. That’s the part you have to think about all these things like routing, loading, unloading apps, handling application life cycles, the communication between the apps, what share services you’re going to have, all that. That’s actually the bulk to work here is building that parent runtime.

Jon: It’s funny because the HTTP mechanism for doing that easily is IFrames. But it’s like, “No, no, no. Actually, don’t do this with an IFrame because the IFrame comes with a whole bunch of just history and crap.”

Chris: Again, it depends on the situation. Maybe we’re really […]. Micro Frontends is not easy. It’s very difficult, it’s very complicated, it’s not very mature as an architecture pattern. This is a lot of work and you have to make sure this is right for you. If it really is like, “Hey, I just want to have this other ‘app’ hosted on this and put inside this,” then it could be something like that, an IFrame works well for you. IFrames, in general, they’re going to be sandbox so they really can’t talk to anything else inside that.

Jon: You almost have to build like an API when you have IFrame like that […] “Hey, this world,” and the world can be like, “Okay, I’ll listen to that and do something.” It’s an API, […] and the hosting page.

Chris: You do have some security issues as well. Some users […], IFrames, in their browser as well, and that just […]. There’s a lot of tradeoffs there and back and forth. 

Jon: You’re going to a URL getting some code, inflating it, and saying, “Okay. DOM, make these components now because I just got them.” All of those things that have grown up around the IFrame world to protect us are not going to be something you have to worry about. That does help a lot.

Chris: You just need to wrap this up a bit. We’ve gotten into this where Micro Frontends are definitely not for every project. Warning, there are clips ahead and you do run the risk of running to a lot of problems here. Be aware of it. It’s interesting and it maybe something that you’re going to want to go and look into more. It’s going to be much more simple for large applications.

If you got a team of five or six people, that’s probably not big enough to justify this, but if you’ve got a team of 50, then you have a very big, very large UI application with lots of different components to it, then you’re going to want to look at this pretty seriously.

Jon: You know where it would be so good, Chris? A lot of large applications, they purposely are designed to keep the different stuff you can do on completely separate pages so you don’t have this problem, like I’m going to do my billing over here on this whole other page and I’m going to do my profile management over here on this other whole page. That way, those two papers can be totally separate apps, totally, totally separate apps. There’s no parent app keeping them together like we’re talking about Micro Frontends.

If you were able to do this with Micro Frontends, there […] to be certain interaction between things that you can accomplish. That could be really cool. If two things that normally I have to flop back and forth between two pages in order to get work done, if I can see them side by side, that’s pretty powerful.

Chris: Here’s a very real world example where the Micro Frontend architecture would be really useful and interesting—the AWS Console. 

Jon: Yeah. That’s what I was thinking about too. How funny.

Chris: It’s just a collection of many different UI Frontends for interacting with the various AWS services. Each one developed independently by a different team and it shows. Totally different UIs on each one of these things. No coordination back and forth. We have the links, but it just navigate your way from that back over the other app for it. Imagine if it was one big Micro Frontend architecture.

Jon: Right. […] and you’re like, “What’s your service role for this and when you click a little ad button, instead of going over to IM, it’s like, […] and there’s little plates right there where you can make a new role.

Chris: New business idea right there. Someone, go build it. Go build a better console for AWS. Nothing’s stopping you. You have all the APIs, everything is supposed to be API.

Jon: Yeah. Make it open source and AWS would just use it.

Chris: No. Not open source. Build it and sell it.

Jon: You know that we’ve talked a lot about open source in AWS in the past.

Chris: Indeed.

Jon: All right, very cool. Is there anything else you wanted to add before we close it up for today?

Chris: No. That covers it. I definitely just want to talk about Micro Frontends. This is a way to wrap up this mini series on Microservices. It’s very well-established […] for doing Microservices approach with backend code, with services that expose their functionality via APIs. You can also look at this approach for your UI frontends as well, just as a matter of completeness. Something to check out, look more into it if you’re interested.

Jon: Right on. Thanks, Chris. Just last, last thing before we close here. I was just thinking with Rich on the phone or on the line that WordPress itself is build in a Micro Frontend type way. They have a pluggable architecture, they have all kinds of things that you can add to it, and they […] into the UI. They’re all built by totally separate teams that have never even met each other. That’s an example of this. What do you say, Rich?

Rich: Sort of. Typically the plugins focus primarily on business logic and then you would still use the theme to display any of that.

Jon: Okay.

Rich: So it is pluggable and extendable in the sense that if you’re writing your themes and your codes right, you’re adding hooks that you can filter through, remove, edit, update, and then actually replace. But the frontend is still controlled by the theme, which is why the idea of taking WordPress headless is more exciting. You can’t get away from that.

Jon: Interesting thought. Very cool. Thanks everyone, we’ll talk to you next week.

Chris: All right. Thanks guys. See you. Bye.

Rich: Well dear listener, you made it to the end. We appreciate your time and invite you to continue the conversation with us online. This episode, along with show notes and other valuable resources is available at mobycast.fm/70. If you have any questions or additional insights, we encourage you to leave us a comment there. Thank you and we’ll see you again next week.