React Summit

React Summit 2022

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. by <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

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

Hello, everyone. Can you hear me all right? Are you excited to be in the React Summit today with me? Yeah! Whoo!

So, hello, everyone. My name is Konstantinos. I'm coming from London. I'm a software engineer. 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 gonna be in a while. But for the time being, we're gonna 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 with using microfrontends? Okay. 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 monolith 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 the business domain. But the teams are, as you can see here, they're 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 Dazen, we're actually using New Relic for logging our runtime 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. 

And this is, of course, because React in production minifies the code base and avoids sending down the full error. 

Okay. 

And how many actually of you have seen this kind of error before in production? 

Are you logging runtime errors? 

How many of you are logging runtime 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 to the issue down to the root of it. 

So, what we're going to do here, source maps won't help because they don't, 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-frontends. 

What I want to focus on is on micro-frontends, the 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 runner up 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, we're able 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're 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 with also with Terraform. You can automate all this stuff much, much easier.
And, yeah, that's pretty much all for now. A really short introduction in the journey to observability for micro-frontends.
Thank you very much. If you have any questions, I'll be around after this talk and on Discord and Twitter with this handle. Thank you very much.

Konstantinos Leimonis

DevOps.js

DevOps.js Conf 2022

Teams are getting bigger and bigger following the micro-frontends architecture. Observability for teams on a scale becomes even more important in order not only to be able to identify potential issues in the runtime, but also separating the responsibilities. In this presentation we’ll learn how this can achieved. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>