Microfrontend Architectures

[00:00:00]
>> Steve Kinney: Let's just get some general terminology straight where the idea is, yeah, it's like one of those things where the definition I'm going to give you is if I like took the word apart and explained it to you, right, it's many small front ends, like, oh my, really, that, you know, ideally, you can, you know, deliver independently. Again, if we go with the build time thing and you're all just merging into one like, you know, mother app that does nothing except like have a bunch of dependencies on the smaller pieces and sews it all together, you know, like, depends on what your definition of deployed is, right?

[00:00:39]
It's in, it's in the big app and when the big app goes, my thing is going like I'm moving that ticket to done, right? You know, these are all squishy terms. Are we ever really done? You know, you can deploy the pieces independently, and the idea, I think the part like the independent deployment, like, is really just about that second bullet point, the team ownership, right? The usual way that you end up in an architecture like this is the topology of just how things get done in this company, right?

[00:01:14]
The value system of this company. Like some of it will be around that team ownership, team autonomy, and so it's not always necessarily a technical choice, but it is the value system of the team. And so, you likely either A inherited that culture or inherited that technology stack, so we'll at least talk about like how to navigate that and manage it, right? And like that could happen no matter what, especially like if you work at a company that has like on the backend has a lot of distributive systems and microservices that becomes an ethos that predates probably even any kind of like large front-end architecture decisions, you know, and so it is the idea of breaking stuff to a lot of small pieces with the virtue hopefully being that teams are autonomous, they can deploy separately, and one team having a boat won't take down everything else.

[00:02:07]
Rarely does that happen, but it's a nice idea. And, you know, there are times when it could be the right choice. I've been doing this long enough to know that any of my strongly held beliefs don't always apply to every situation, right? There's some times where I talk to somebody and I'm like, yeah, yeah, that's probably the right choice, right, especially if you work at a, the problems that you have even at companies that maybe you and all of the like the people in your industry know about, like, are different than the problems at the companies that my mother knows the name of, right?

[00:02:43]
Like there are companies like the ones that make phones where some tech debt is like my age, right? And it's like that's a thing, right? And you'd be like, OK, given that this is probably the right choice, right? Like if you, you know, we'll talk about migration patterns at the end of day two, but like there's sometimes where it's like, hey, no, we ended up breaking stuff up into smaller pieces because the alternative was like rewriting a 15 year old codebase, and that was untenable, right?

[00:03:15]
And so then you end up in a situation where you're like breaking up into the small microphone is just 100% the right choice, right? And that's the tricky nuance, right? There's no like, pure right answer all the times. The answer is always going to be, it depends. So if you need to ship with different cadences, if there is, you know, you need clearer ownership and so on, and but again, the most compelling one for me has always been taking the big thing and refactoring it is untenable, right?

[00:03:45]
So we will begin to break it off into sizable chunks and then next thing you know, you have a federation of small pieces for the most responsible and right reasons and good. I have one quick question on this, just, you know, is a micro front end and right, the first word was multiple teams. What if there is just one team? Would you, could you ever imagine a scenario where a micro front end might work, might be the right move for one team that has a complex codebase?

[00:04:21]
Here's the like paradox I'm in right now, is I've literally just said I don't think that there are hard and fast rules that apply all the time, and all I want to tell you is no, right, like I can't see a world where one team needs to like maintain 4 CI/CD processes and like, OK, we gotta like open up the PR on that repo, publish that package to npm, OK, wait for npm to get that one, then bump it down into this one and do all those other things.

[00:04:53]
I struggle with like, and someone's, somebody in the chat is going to be like, uh, let me tell you about my very specific use case. I'd be like, oh, yeah, it probably makes sense, but like my gut says now, like I like like the burden of proof is on that you would need it, right, and the case would have to be made in that sense. So, and let's talk about the flavors of putting together micro front-end because like when we say micro front-end, if I said everyone tell me about your micro front-end, we would get as many people as answered different flavors of micro front ends, right?

[00:05:31]
And so one of them you have is surface eye composition which, yeah, we're going to build a bunch of HTML pages, and then we'll progressively enhance them with some JavaScript, which is giving 2008, a simpler time, honestly, right? Like it's not trendy, except that it like increasingly is, we'll talk about like island architecture later. It's like all these things like, you know, the past is again the future kind of thing, right?

[00:06:01]
But like, there's something about like if you had a PHP page and the other team had a PHP page and they were all server rendered, you don't end up with a lot of these problems, right? So obviously that 100% works, but like, typically, like if you've got like a single page application, you're not living in that world. We have a specific use case where it was the settings in the Frontend Masters dashboard and I remember the architecture started out as like a spa of like clicking between forms and you have to have the validation states and then, you know, all of the data has to be sent down and it just, it got to be like a nightmare.

[00:06:46]
I'm like, why don't we just make these separate pages and each, each section of the settings is a separate page now and it's, oh, OK, like only the data that's needed for that form is on the page and it's just so much simpler, which is like now what stuff like Next and SvelteKit are trying to give you, right? Like I haven't used Next in a while, but SvelteKit like literally has this idea of like, you've got like maybe a some loading function or whether it's on the Node side or isomorphic, right, where you can define HTML form actions, right, and it will then just set up the endpoints on the Node side and you're, instead of like all of this like crazy form validation stuff, you just use an HTML form that sends a POST request, and it says about as much JavaScript as it needs to show you the errors under the things, and it's wildly elegant, and it's just a schema and like it is, it feels like you're living in the future as you are definitely making a page that could have been made with jQuery, you know, like.

[00:07:57]
And so everything old is new again, and everything is cyclical, and I think we are, we are going to this like, new phase, which is, it's interesting to watch. Then we've got the build time integration which other than like the like standard deploys, right, it means like if you have to merge everything into the app shell or the kind of like main like host application, and then that gets deployed. On one hand, you got none of the individual team velocity.

[00:08:30]
On the other hand, there's no coordinating deploys, right? And, you know, even if you've never felt that across front-end teams, if you're a front-end engineer, you have felt it with the backend team, right, which is, well, we're going to let this PR sit here and rot because the backend team is behind schedule and we can't, the API is not there, and so now we've got to rearrange our entire like next few sprints based on that kind of stuff, right?

[00:09:00]
Versus we can merge into this thing when everything's ready to go, it can go out at once, right? That's again, autonomy and complexity, right? Autonomy leads to complexity, right? There's, you know, like a larger philosophical thing here, but we won't go down that road. But like, it's, you know, it has some problems of like, you don't have any of that like individual team, but like you also have some, you can, you can deploy everything atomically, right?

[00:09:26]
When the big app goes out, it's all been tested together to Robert's point too, like the QA engineer can like test it across the entire thing versus like, OK, this part's going out, but that part needed to be out there and you have dependency management, right? And that's tricky as well. So you gotta, you know, it's not necessarily, despite me getting a little cheeky with the subtitle, a bad thing per se, but like, understand, at least we, like if the whole idea was I want team autonomy and freedom to deploy whatever I want, you didn't get that.

[00:10:02]
OK, let's just be honest with ourselves, which is definitely what somebody was lecturing me on when I wrote that subtitle. So, that's some context. Then you've got various ways that you do it at runtime. We will talk about module federation as its own unique thing. There are all sorts of fun flavors that I have either seen, heard people complain about, or worse, heard people think that I absolutely need to be lectured on, or ones that I have considered and possibly rejected over time, this being one of them, which is that everyone deploys separately and each part lives in its own iframe, right, which will, like, you don't have to worry about your CSS spilling over into somebody else's CSS, I'll tell you that.

[00:10:55]
You know, good luck figuring, like, you will get isolation, you won't have to worry about global spilling over or anything along those lines. Each team can deploy individually into their little iframe. The bad parts are like everything else just got harder, right? Like, now, oh, you wanted to like have the Nav reflect the current page you're on. I hope you like either like postMessage or Broadcast Channel or something along those lines, right, or firing custom events to the global namespace to then post a message out of your iframe to the global to send a message down into the next iframe.

[00:11:36]
Like you got some things, it is simple, but you've made most of the, and like where I've I've always like vetoed this one is like, explain to me how responsive design works, and now you have container queries. I don't wanna hear it, but like, you know, like the web's getting better. Most of my counterarguments will probably not be true in a year, and then I'm going to have to re-record this and stuff along those lines, but there are like, it's important, you know, as if we weren't even talking about like when you're architecting anything, whether it's solo with a team, with your good friend Codex, like thinking through all the constraints and all the tradeoffs that you're making is the important part, none of these options are perfect because we would just do it if it was perfect and we wouldn't have this workshop.

[00:12:31]
It's about like which set of like trade-offs do you want, and the probably more recent entrant into the field is the idea of using JavaScript modules, right? You know, those old ups remember like the idea of like even having the ability to like require import code is not always a thing and there was like, I'm going to make a bunch of AMD modules which will work differently than a bunch of other stuff, so on and so forth.

[00:12:56]
But in the modern web, we have the ability, we have ECMAScript modules, right? And not only can you break your code apart into more than one file and import it, you can also do stuff like lazy loading, right? And so you, you know, a lot of us, I think we've all seen the import whatever from whatever file system, you know, whatever file and something like Vite will sew all that up for you or Webpack or what have you.

[00:13:21]
But there's also just a primitive in, you know, the web platform, both, Node supports it as long as you're using ECMAScript modules, Bun supports it, the browser supports it. Everything supports it where it's like an import function where you give it a path or a URL in the case of the web, and it will at runtime go fetch it, return a promise, the promise will resolve to the code, you do stuff with it.

[00:13:44]
And so with this pattern, this is module federation for those, you know, like this sounds like module federation. It is, is the idea that like we could load something that then imports all of the other pieces, so I could deploy just my JavaScript bundle, you can deploy just your JavaScript bundle, and then at runtime, the shell will pull them all. So we're not blocked by the deploy anymore, but like, you can just start to imagine, right, what happens if your CDN goes down, you know, or something along those lines, right?

[00:14:18]
Like now any given part, at least with the atomic deploy, it all went out or nothing went out? This is how you end up with a whole, like now everyone can deploy individually and autonomously, you're like, that's great. The bad part is that everyone can deploy individually and autonomously. And to kind of Robert's story from earlier, how do you test that, right? How do you test that like it wasn't just, you know, the team that had this plum job of just working on the navigation, you know, like that bundle is no longer working or like that S3 bucket, someone set the policy to auto delete.

[00:15:04]
I say that because it happened. You know, there a whole new set of problems come up and then like, who gets paged for that? You know, it's all, it's all a fun game. The other ones that I have seen, and this is something that like somebody also asked me about, which is, OK, what about runtime integration with web components. So we had kind of three ways ahead us we saw iframes, which everything is isolated, it's atomic, you know, it's like by itself, but everything is harder in terms of interacting across the pieces.

[00:15:37]
We saw the what we're just going to call module federation, but like the idea of like importing JavaScript modules dynamically at runtime, that doesn't have any of the isolation that the iframes got us, right, because you decided to put a global style in there and guess what, now everyone has that global style and there are things you can do. I know, layers, so on and so forth, but like generally speaking, I've been in enough codebases though that like, a lot of them predate those things and don't have all of those niceties.

[00:16:10]
And so the other idea is like, well, what if instead of an iframe or instead of a JavaScript module, we all deployed independently, but we deploy my thing lives in my web component where all the CSS is isolated, your thing lives in your web component where all the CSS is isolated, right? And I think it's one of those things where it all depends on what you're building, right? Like, we always talk about like frontend performance or all these best practices as if there is like a right way to do it.

[00:16:38]
If you think about something like the New York Times website where like getting you reading that page, like, is incredibly important, like they can trace it to dollars from ads is different than when you, this doesn't happen as much anymore, but like when you go to load Gmail and you wait for that little progress bar to fill up, you're willing to wait for it because once that single page application loads, you're going to be in it the whole time, right?

[00:17:12]
And so, if you don't need to worry about server-side rendering, then this might work for you, right? It has a lot of the advantages. You get everything encapsulated and isolated, you can deploy independently. The thing is that to this day, right, the server-side rendering story for web components, I like effectively non-existent. Like, if you go to like the lit HTML page, there's like a little like experimental, like, you know, it's like, there's some ideas.