Teams are getting bigger by applying micro-frontends using React, but complexity tracking production issues can become extremely confusing when no clear responsibilities are met. That’s when observability for teams and applications on a scale becomes even more important, in order to be able to identify potential issues in production, separate the concerns and the responsibilities among them. In this presentation we’ll learn how we can achieve this.
Keeping Sane with React Micro-Frontends in Production by Applying Observability

AI Generated Video Summary
Observability for microfrontends involves defining clear separation of concerns between teams and tracking errors in production with structured events. By using React boundaries, failures can be isolated and high observability can be achieved. Logging errors with metadata allows for querying specific error types and receiving notifications. Automating the process with Terraform simplifies observability for microfrontends.
1. Introduction to Observability for Microfrontends
Hello, everyone. My name is Konstantinos. I'm a software engineer working for DAZN, where we're building a live and on-demand streaming service for sport events. We're going to explore observability for microfrontends, which have become a paradigm for microservices. While they help separate frontend monoliths into smaller applications, there can be challenges in defining clear separation of concerns between teams. We'll also discuss logging around time errors and the limitations of error decoders and source maps.
[♪ Music ♪ and applause ♪ Hello, everyone. Can you hear me all right? Are you excited to be in the React Summit today with me? Yeah! Woo! So, hello, everyone. My name is Konstantinos. I'm coming from London. I'm a software engineer, where I'm actually working there for DAZN. And we're actually building a live and on-demand streaming service for sport events. We plan to become the home of all sports, and this is going to be in a while. But for the time being, we're going to see what about observability for microfrontends.
So how many of you have already used or plan to use microfrontends? Okay. And how many of you, have you been building already in production using microfrontends? Okay. That's much better than expected. That's great. So microfrontends have actually become like a paradigm for microservices. They come here in order to separate the frontend monoliths and split it to separate smaller applications. That's why we end up having end-to-end teams responsible for a specific business domain. And they're able to have a specific mission. That's how we have frontend, backend, and database teams focused on a specific mission of a business domain. But the teams are, as you can see here, they are really pretty well-defined until when if we zoom in, in some of these cases, they're not actually that clear separation of concerns. So, for example, we might have a team A responsible for the header and footer, but we might have a team B responsible for the account details. We need to find out ways to separate these kind of modules and better ways to observe them in production.
I don't know about you, so in design, we're actually using New Relic for logging around time errors. You might be using, like, a similar tool. So I'm going to New Relic dashboard and I usually see this kind of error. This is, of course, because React in production minifies the code base and avoids sending down the full error. How many of you have seen this kind of error before in production? Are you logging around time errors? How many of you are logging around time errors in production? Okay. So what we're doing, we're going to visit the React docs and we're going to see this error decoder. The information that we get from there is really valuable. But it doesn't help us identify the issue down to the root of it. So what we're going to do here, source maps won't help because they're not aware of the internal modules. And what we need to do is, we need to take a step back and check the principles from micro front ends.
2. Observability for Micro Frontends
Micro frontends require clear boundaries to isolate failures and achieve high observability. By using React boundaries, we can wrap container and module components to create scope around errors. The first step to observability is tracking errors in production with structured events. This allows us to log errors and define metadata such as module name and version. With this data, we can query specific error types and receive notifications via email or integration with support systems like PagerDuty. Automating this process with Terraform makes it even easier.
What I want to focus on is on micro front ends that need to isolate the failure and be high observable systems. It's easier to observe a single system, but it's a bit difficult to observe a system split into multiple modules.
So here, for example, we have my account, which is the container application. And we are also having menu, which is a specific module. Footer, which is another module. And profile, which is another one. So how we're going to solve this problem. We're going to need clear boundaries. And the way that we're going to do that is by using React boundaries. This is like a solution for quite some time now. So we're going to wrap our container components and the module components using the boundaries. And that way, we're actually able to create some scope around these errors.
Another thing, and the very first step to observability, is to be able to track the error in production with structured events. What this means is that by using the error boundaries, we're able to track on the New Relic system or any other of your tools that you're using. We're able to log the error and we're also able to define some metadata about these errors. And this is about, for example, module name, module version, or whatever else we want to create some context about. This is what we're going to do for the module error boundary as well.
And finally, now that we're tracking all this data on New Relic, we're able to start querying this data from the New Relic tables. This is how New Relic query language would work. And we are able to query down to very, very specific error types and define it in the component source based on the context that we define from the metadata from the error tracking before. And we're also able to get notified from them in the simplest form with an email, or otherwise integrating with a online or on-call support system like PagerDuty. So you can actually do this, actually, also with Terraform, you can automate all the stuff and it's much, much easier.
And yeah, that's pretty much all for now. A really short introduction on the journey to observability for micro frontends. Thank you very much. If you have any questions, I'll be around after this talk. I'm on Discord and Twitter with this handle. Thank you very much.