The Micro-Frontend Revolution at Amex

Hello, everybody. My name is Ruben and I am a software engineer at American Express. And today I'm going to talk about the micro front-end revolution that took place at American Express.

So, first of all, let's start with a story. Let's imagine that you are just being hired as the new CTO for this very, very large corporation. So, you are responsible for the digital transformation of the company, as well as fixing issues with scaling. And you're in charge of fixing these issues.

So, the first decision that you make is, right, so, we need more developers. We need to add more people, and that's what you do. So, you also are a fan of the two-pizza rule, and you think, right, we need to create smaller teams and add those developers to those teams. So, we create smaller autonomous teams, and because in the past, you were part of this previous company and you had some previous experience, you think, oh, I think we should do microservices architecture here. It's a good idea. It's been proven. There are a lot of resources out there, and it's widely adopted.

So, let's make the most of the microservice architecture, and let's make the most of horizontal scaling, because we know that vertical scaling is not enough at some point, so we want to start doing horizontal scaling. And that is great. That is working very well. Until, well, until we try to apply these methods to the frontend. And what happens with the frontend? Well, the frontend, let's imagine this frontend is a really large monolithic application. It has a lot of legacy code. All the engineers are working on the same codebase. And if we want to add more engineers, obviously this is a bad idea, because they are working on the same codebase. So, the more engineers you add, the worse it becomes, because it will be just a nightmare to manage so many people working out of the same codebase.

So, the frontend has a lot of challenges. And these challenges are communication issues, friction, it takes longer and longer to add new features, fixing and finding bugs becomes a challenge, very hard to keep production and development environments in sync. And at some point of our careers, we all have had this question. We all were, like, what about a complete rewrite? And you think, oh, is that even possible? It seems like a very, very difficult task. Seems like an impossible task. But you're considering, right, we need to do a complete rewrite. Now, but hold on a second.

I think we have seen these problems before. We have seen all these communication issues, all this stuff. We had this when we were adopting microservices. So we think, hmm, what do we need to do to apply the microservices to the front end to solve these issues?

So the first thing you try is, well, I have seen this quote somewhere. Independent delivery could be a really turning point for large organizations to allow their teams to deliver faster and freely and to collaborate more effectively. And you think, well, that's it. I need to allow them to deploy independently. I want to allow them to deliver independently so they don't work on the same code base and they can deliver independently. And that's our first approach. And we try to divide the frontend and let's say that we are going to divide it into subdomains.

So, we give every single team a subdomain and they're going to build the application on that subdomain and everyone should be happy with that and we will solve a lot of issues. Well, actually, having that just independent delivery could more problems and more challenges than actual solutions. And let me expand on that.

Why this will cause more challenges. Well, if we give people their own subdomain or their own place on the website, teams will tend to start building applications in silos. And what is a silo? Well, it's a way of building software that is very difficult to communicate with another piece of software. So, the application and the features are built in siloes, and we start seeing people doing their own thing. Now, that also causes fragmentary user experiences. Because they're using their own tools and they're following their own thing, and they just don't care about communicating with other teams. We end up with a very disjointed user experience where the website might look very different if you go to one subdomain or if you go to a different subdomain of the website, when you're transferring, hold on a minute, the website doesn't look the same, and it starts looking very different.

Now, if we start also building the same functionality over and over, for example, if we want to build a different variation or if you want to translate that page to a different language or launch a different market in a different place, we end up building the same functionality again and again just because it has some variations in language or different regulation in different parts of the planet. So, we start building the same thing over and over again. There is no reuse. Also, because it's really difficult to upgrade and manage, things are everywhere and it's very difficult to have somewhere to update something in one place that will propagate throughout the website. This one is really annoying to me when you have authentication issues and you're on a website and it's asking you to log in again. But hold on, I just logged in on this part of the website and it's asking me to log in again. So, we end up with a lot of authentication issues and persistent authentication. Now, this is the big question. This is a big question on this presentation. How do we scale a web application to be developed not just by hundreds, but by thousands of engineers and upgrade it to use the latest technologies? It's a very loaded question.

And this is what we want to try and solve. This is what we want to achieve. So, let me just tell you, just drumroll, what is the solution? Well, this is one solution. Applying micro frontends. A micro frontend is just a way to apply the microservices architecture pattern to the frontend. And it's a set of tools that will allow us to do that and fix all those challenges and problems that we are facing.

So, how do we do it? A bit of history. American Express is actually a pioneer in the implementation of micro frontends. And since 2016, we have implemented this framework that allows us to create server side rendered micro frontends and compose them on the page. So, this framework solves a lot of these problems. And I'm going to talk a little bit about how this framework and how the concept behind the framework has helped American Express solve the scaling issues. So, let's have a look.

First of all, what we have solved and what features have helped us solve some of the problems? Okay. Let's start by the modular design by default. What do I mean by modular design? Well, we are building instead of entire pages or entire applications, we are building modules. And these modules allow us to deploy them independently but also we can give parts of the website, not just the subdomain, just very granular parts of the website to independent teams. An example of this would be there is a team that handles the header and the footer and the overall navigation. That overall navigation, the team will be in charge of making sure that it's translated to all languages, they will make sure that it has the latest version, latest colors, latest links and everything. And also we probably have another team handling the authentication. If I'm one of the teams developing a page, I know that I don't have to worry about the header or the footer or the newest links that have to be added, because I can just drag and drop that module onto my page and then just get on with my development. The same with authentication authorization. I don't have to worry about implementing authentication many times because I know there is a module that allows you to do authentication. This also provides server-side rendering and this application allows us to do not just client-side interactive experiences, but also server-side render our applications, which is important for SEO. It also provides us with enterprise security. It's very important that you manage that from a centralized place and make sure that everyone is compliant with security. Implement things like the content security policy, which is an industry standard, just ensuring that every single module provides the security required. If you remember before, I mentioned when you try to do different markets or internationalization, the app provides that option to translate those modules and just reuse them in different contexts. The main feature of all, as we discussed before, is allowing independent deployments. Every single team will have their own capability to deploy to production without having to deploy the entire website, entire application. And the most important of all, there is no server restart.

So you can deploy independently. You don't have to restart any servers when you deploy. The server will just carry on running. And this is probably when you start asking, okay, show me the architecture, show me the code, show me what is behind the scenes of this framework. Okay. So, we are going to see the technology behind this. And the technology is basically we have a Node.js server in the background that is just a long running server. That server provides the server side rendering, it provides the composition of different modules.

And on the right hand side, we have the Holocron modules which are basically micro frontends built on top of React. Yes, Star Wars reference. We like Star Wars and Holocron modules is the name we have given to the modules and the micro frontends. And these modules are in charge of the business logic. Are in charge of the user experience. So, there is no business logic or nothing is built on the Node.js server. The Node.js server is just the orchestrator. It's just the container that is in charge of the server side rendering and decomposition. But all the logic and all the applications are built as independent Holocron modules. And we are using React to allow this composition model.

Now let's take a look at the diagram and what happens when we are in production. So, in production, we have, again, the Node.js server is the long running process. And we have our Holocron modules deployed to a CDN. Those modules on the CDN are deployed and they have the static assets, the server code, as well as the client code. And the way that we know what modules are deployed to the particular application that we're working on is by using something that we call the module map. The module map is just a JSON file that is very similar. You can think about the module map to something like the package to JSON file where we have a reference, a list of modules and their versions and what modules should be active on this application. So, what the 1Up server does is keep checking this JSON file regularly for changes and it will find out if a module has been updated, if it has been removed or it has been added. And those modules are added into memory. Those modules in memory are ready to be rendered and to take requests. So, after the modules are loaded into memory, when the user types the URL, the request will come to the one app server and then we will have the modules composed on the page. So, if you look at the diagram below, we have the root module, which is basically the module where we configure the application and we contain the other modules and then we have individual modules on the same page.

You can also load different modules on different URLs and compose them it's up to the developer and up to their requirements how to compose those modules on the page. Right. So, this is more or less what happens in the production.

Now, we most of us are developers. Let's see. How do you manage this in development? Because the first question that we might have is, right, we have let's say 300 modules in production. How am I meant to use all this code? How am I meant to download this code and make a change? Well, every single module has their own repository. They have their own CI pipeline and they are they have isolated.

So, they have their own code base. So, the way we do this is we have a local development environment that will pull the 1-up server from a Docker image. We also have a CDN locally. So, what happens is if I want to make a change to one of the modules, I just clone the repository into my local machine, make the change, and the 1-up server locally from Docker will load all the rest of the modules that are in production and it will compose them for my application. So, I don't have to download all the code. I can just download the module I want to change, compose it locally, test it, and then it will be ready for deployment.

So, this is what happens in development. It's a very easy way just to manage separate codebases. And, again, the CICD pipeline and everything is individually for every single module. So, after I have made the changes to my module, I will do independent unit tests. I will also perform some integration tests to make sure that the module behaves as expected when running in the environment with the other modules, and then I will push it. After I push it to production, the CICD pipeline will publish it to the production CDN, and then the production one observer will pull that module from the module map and a new version will be installed. Everything happens at runtime. The one observer does not need to restart when a new module is added into memory. It will just find a new module, put it into memory, and then you have something in production. So, this is very powerful because it means that you don't have to worry about deploying things and restarting servers and downtime, because the server is always running and modules can be just added and removed at runtime.

Okay. So, this is just a conclusion. And the conclusion is, well, this is great. This has worked very well for us. Microfrontends has been an architecture that has solved a lot of problems with scaling, making sure that we can have thousands of developers working on the same application without having a lot of problems with single codebases and a lot of problems with deployments. But the conclusion is, there isn't a single approach.

There isn't a single solution for this problem. Microfrontends are a pattern. They are not a set of tools or a framework they can just plug and play. It depends on your use case. And your specific use case will likely drive the requirements and the architecture that you need to use to solve the scaling problems.

So, different companies will have different issues and you will have different things that you can solve. So, just to conclude, the one up framework is open source if you want to take a look at it and just let us know what you think.

So, yeah, thank you very much. And I hope that you enjoyed your presentation. Now I just hope that you have some questions. What do you think? Should micro front ends use a single framework language or have multiple? It looks like the majority think a single one. What do you think of that?

Well, that was a great question. Because the thing with micro contents is that people think they are all about mixing frameworks. And that is completely that's not true. That's not what micro frontends are about. You should use one. I mean, you can use multiple frameworks. And there is a valid use case. Let's say the application is built on Angular JS and you want to upgrade it to react. Then you could use micro frontends to do the upgrade, like the straggler pattern, which is upgrading the application incrementally. But at the end, I don't think it's recommended for performance issues. I mean, you could. And I have heard people saying we gave the developers the flexibility to use the framework that they wanted to use. And at the end, they ended up using just one framework because it's the one they are more comfortable with. So, yeah. Yeah, yeah, yeah. You also have to think about like the... I would think that you'd have to think of the team cost, you know. It costs a lot more to have a developer that knows all of these frameworks than to have one that maybe is just specific to one. Yeah.

That's a point. We have some questions from our audience, our lovely audience. Dr. Jessie Pye asked, does NestJs fit for my current front ends? NestJs. Well, probably we need to talk to them about this topic. Nest, sorry. Yeah. I'm sorry. I missed the question. Well, the thing is, adopting a Microfontend pattern onto an existing framework is a challenge because it's completely a way of building architecture. And the key feature of Microfontend to allow any framework to use this pattern is allowing independent delivery so that you can deploy parts of the application independently without having to restart the entire application. So possible is with any framework, the question is, you know, it has to be reworked to allow independent deployments. And features like Webpack, Modifederation could help with that. Gotcha.

That actually kind of leans into our next question from Maxim Leont. How do you solve problems with modules' communications? And Danji also asked how do modules communicate with each other? Okay. So communication is you can choose what communication mechanisms you want to use but the main thing that you need to bear in mind is that modules should remain as independent as possible. So it's not a traditional application development where you just pass data down cascading or using props. With microphone 10s it's very important to keep them independent so they load the data they need and they are not depending on other microphone 10s and they are not tightly coupled to each other. That is very important with microphone 10s. Now there are obvious cases where that's not possible and you need to send communication and you need to update other microphone 10s depending on the state of other microphone 10s. So at that point you can choose your mechanism. You can use just sending events, that's one solution. Other people prefer to use a state management like global state management like Redux for example but sharing a state is also a bit difficult. It's very important that you don't tightly couple those microphone 10s so it depends on your implementation. But again, very important, do not couple them.

Yeah, that sounds like it's bound to get messy if they're coupled too much. David Liam asks do you have any recommendation on how a micro services team with UI for each service would migrate to microphone 10s?

Actually, that is the best place to start consider on a microphone 10 architecture. So if your company is already using micro services, you have large scale applications and you're using kubernetes, and you have a lot of distributor teams who own their own part of the product, it's a very good place to start implementing microphone 10s because at that point, you can start a domain split of your application, where you can just give the team the responsibility for that part. And they will be responsible for the backend and the front end. And also there is a new trend, which is backends for front ends, where the backend micro service will be in charge to provide the information just to one front end. And if you follow the micro front end pattern, then that will be easier, because it means that the team can own the entirety of that product or experience.

That's really interesting. It ties into Andre Calisson's question. You've mentioned that the team can own the front end, the backend. Andre's curious about the infrastructure. So they ask, what does the composition of teams at Amex look like? You said each model has its own CI-CD pipeline. Are they also responsible for maintaining these infrastructures? How does it look like when a new team is formed? How do they get started with their own module?

Right. So the infrastructure is something that is managed by other teams, but we get everything set up by default. So when you start a new micro front end, you'll get your own repository and there is some automation to create infrastructure for it. So you could create some automation to add all the jobs that are required for the deployment of those micro front ends. So it's part of the infrastructure onboarding and with some nice automation, it's something that is very easy to manage, so you don't have to worry about starting from scratch. Every time that you create a new micro front end, everything will just come out of the box.

That's awesome and probably helps with team velocity so that it's less overhead cost when you start, right?

Yeah, that's correct. So you don't need to worry about the infrastructure, you just need to create your micro front end, deploy it and then everything will just be deployed to the different environments. That's so nice. I want that.

Yeah. We have another question. We actually have tons of questions. People love this talk, way to go. House of Alejandro asked, he says, awesome presentation. Agree. And they also ask, what do you think about micro front ends without server side rendering? Would it be as good as a solution as a server side rendering approach? Well, server side rendering is something that we added to our micro front ends, but it doesn't mean that you have to. And you will find the answer to that question is, do you need server side rendering on your application at all? So if you have a client side rendered application that does the job and you don't have to worry about SEO or anything like that, again, the rules that apply when you are choosing server side rendering or client side rendering apply in the same case. The only difference is that those applications are deployed independently.

So it's nice that we, in our framework have server side rendering, but also client side only applications with micro front ends will definitely be easier. That's that's something to bear in mind. Server side rendering does add some complexity as well. So if it's just a SPA, like a single page application, client side only, that would also work. Nice. Yeah.

So William asked and we have this is a very short last question. So no pressure. Did you see a big increase in download size when adopting micro front ends? I can imagine all those modules bring all kinds of dependencies. How did you solve it? This is a great question. So we have a limit. So 250K for micro front end as a baseline. And the way that you achieve that, so the bundle size is not bloated is by using a combination of webpack externals and combination of dynamic import. So you can achieve a smaller bundle size. But that is the main thing that we want to make sure they're not too big. That's a good rule. What a great question.

Thanks so much to all of the folks who asked questions. Ruben, there's a couple of questions left if you want to hop into Discord and give them an answer. And let's all give a big round of virtual applause to Ruben.