Microfrontends in Safety Critical Aviation Systems

My name's Jared, and I'm a technical leader at AWS SafeKit. Today, we're going to talk a little bit around micro functions and safety critical aviation systems. AWS SafeKit is a global market leader in airport control software and visual docking guidance systems, and the software we're talking about today manages the entire operation of an airport from arrival to departure, including real-time aircraft position tracking, gate and stand planning, and integration to all core systems to deliver a single source of truth.

Airports are connected to each other, much like the nodes of a network, and if one node is slow or failing, there's a domino effect for each node coming next. In addition to that, air traffic is actually doubling every 15 years, growing at a rate of 4.4% annually. There's a 50% capacity shortage expected by 2035 in half the world's airports if we don't take any action. This ultimately means that 237 million passengers won't be able to fly by 2035. So buckle up, sit back, and let's enjoy the flight.

A little bit around AWS SafeKit. We're a little over 1,200 employees in 38 offices spread across the world, and we work with over 2,700 airports. Myself, I've been having fun with code for 13 years. Started with a lot of robotics, and then moved into web and mobile applications, then received a degree in computer engineering, and I've been with AWS SafeKit for the past five years in various technical roles. A fun fact, I actually moved from the US to Sweden three years ago.

We begin our journey with a little bit of history. Our current application stack's been through a couple of major reworks. We started with a very simple monolith, a C++ backend and a Qt frontend. We started to get more demand for more feature-rich applications and tightly integrated solutions. So ultimately, we moved into the web, introduced Angular, and other teams started building new products on the same tech stack, and we found a lot of synergies in those products.

But with every flight, there's always a chance for turbulence. So if we go back to that traditional monolith, we all know this picture, teams contributing code into a single codebase. And you will hit a point where it's a good idea to separate these things. You have a frontend and backend, you have better separation of concern, and you speed up your development. And you might hit a certain point where the backend grows so large that you introduce microservices, a really popular concept. And for us, this is how we've developed products for years. We have a lot of microservices separated from things.

But one day you come to work and you get a really interesting question, a really complex question. Can we take 60 of these different products and combine them into a single web application? And for us developers, that meant we had 46 applications and 22 libraries spread across 20 repositories. Even worse, we're spread all over Europe. We have developers in Sweden, Austria, Germany, Poland, and the UK. And when you first look at the problem, you might picture something like this, where you have a lot of backend services and one giant frontend. It seems really scary. Luckily, much like an aircraft, there's some instruments and controls that we can use to make our lives easier.

So the big question, what are microfrontends? Of course, naturally it's just an extension of microservice architecture to the frontend. And what that means is we take our components or group of components and put them into standalone bundles and then combine these during runtime to create a single application in the browser. It's important to note that this is framework agnostic. You can have a React, Vue, Angular app all running in the same browser at the same time. It's hard to talk about microfrontends without mentioning module federation from Webpack. And this is the original mental model that's really popularized the idea of microfrontends. It allows you to take separate Webpack builds and to form a single application. And it facilitated the loading of these remote modules at runtime asynchronously. For you, it might look like lazy loading. And it also provides mechanisms to manage different dependencies across different builds and to have an optimized bundle size. If you're not using Webpack, there's some other options like native federation.

If you're not using Webpack, there's some other options like native federation. And this is a browser native implementation of the module federation idea. And this is actually able to be used with any framework or build tool.

Some other options, web components have been around for quite some time, as well as iframes. And you could even do the JavaScript orchestration yourself.

Now, for us in particular to manage all of this, we actually use a monorepository with index. And index provides an extensible build system, allows you to use modern tools like Cypress, Jest, Prettier in a standard way across all the applications in your repository. And it provides an integrated environment for developing apps with popular frameworks like Angular, React, Node.js, making it easier to manage code sharing and minimize redundancy.

All of this comes together with cool features like computational caching, effective commanding, code generation, which streamline the developer experience and process.

Now that we know the tools, instruments and controls, I think we're ready to navigate. So, if we go back to that really scary picture, we have this huge frontend and all of these backend services. But what we want is something like this where everything is separated. And we can still have that while delivering a single web application by using micro frontends where we wrap these individual feature based frontends into a host application. And if you do it right, it might look something like this where we have a menu that has a lot of options. And every single one of these options in the menu is actually an independently built frontend.

Some of the benefits of micro frontends include incremental upgrades. You can break your application down piece by piece, introduce new technology, frameworks, packages and maintain your velocity while also taking care of technical debt. You also gain a lot of deployment independence. Your applications are decoupled and you have less chance of negative impact from other teams. And all of this kind of comes together to enable team autonomy. You don't have to coordinate so much with each other and you gain freedom in choosing the tools and frameworks that you want to use.

Now, whatever benefit, there's also downsides. You can have poor performance if not well architected. You can have really large bundle sizes. You can increase your browser workload. So, you need to be very careful about how you're orchestrating this during runtime. You can also run into trouble with styles. Different teams are using different styling approaches. You could introduce conflicts leading to inconsistent UI. And, of course, complexity.

As a more distributed architecture, you'll inevitably lead to having more stuff to manage. You have more tools, more pipelines, more repositories, more applications.

With this in mind, I think we're ready to land. So, when should you use micro frontends? Now, the first thing to think about is, of course, a single high-level architectural decision like, hey, let's do micro frontends is not a substitute for good old-fashioned clean code. We're not trying to get out of thinking about our code and putting effort into its quality. But rather, we're trying to set ourselves up to have success by making bad decisions hard and good ones easy.

So, if you work on large-scale enterprise applications developed by multiple teams and if you have distinct business or technical requirements in different corners of your application, or if you need the ability to experiment without risking your stability, micro frontends might be good for you. But before you go any further, you should ask yourself a couple of questions. Do you have enough automation in place or the ability to add automation to manage the complexity? Will your processes scale to a more distributed system? And how can you ensure a minimum level of quality, consistency, and governance across the independent frontends?

So, if the answer to that is, yeah, yeah, I do it, it sounds really good, here are some tips and tricks for migrating to micro frontends. One of them is to use domain-driven design to define clear boundaries around the different applications and functionalities and to have sole ownership over these in specific teams. It's also recommended to develop a shared component library for common UI elements to ensure consistency across your application and focus on automation. Implement comprehensive automated test strategies with integration test, unit test, and set up CI to CD pipelines to streamline this process. Whatever possible, choose tools and frameworks that are agnostic to specific frontend technologies. At the end of the day, this is JavaScript and it changes every other day. Thank you.