Keeping Sane with React Micro-Frontends in Production by Applying Observability

[♪ 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.

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.