Sharing is Caring: (How) Should Micro Frontends Share State?

Hi, everyone. My name is Eliran Atan. This is my second time in React Summit, but still very excited. I've been building scalable systems for the last decade now, and today I wish to focus on micro-frontends, and especially about micro-frontends' sharing state.

So micro-frontends is about breaking up this frontend monolith into smaller, more manageable pieces that allow development teams to work in a more efficient and effective way. This is because micro-frontends are often isolated from each other. They allow development teams to work in an autonomous way and with less friction and limitations.

A common problem that often comes up when we talk about micro-frontends is whether they should share state or communicate in some way. If so, then how should we do it without breaking their isolation from each other? Now, in this talk we will see a different approach to think about micro-frontends. We're going to tackle that from a domain-driven perspective. So, we would see how we can represent a micro-frontend using something we call a bounded context. Bounded context is this logical creature that mirrors our implementation and can derive the implementation. And we will see how that can help us understand a communication between micro-frontends.

So, let's start from another angle. Let's talk about Agile. In Agile, we often work with user story. So, user stories are this short description of an end goal that the user would like to achieve, right? And it always is described from the perspective of the user and in terms of the business. So, usually in many organizations, resolving a user story will involve the cooperation and coordination of multi-layer teams. And that's because the affected code of resolving that story is often shared between these teams. And that's because how organizations tend to structure teams, especially when we talk about front-end. We often see this arbitrary division of responsibility between teams.

Sometimes it's about owning components or pages or views. But that's not really how user stories are organized. What we really want is some way to organize our teams and code in a way that resolving a user story would be an end-to-end task of a single team. That means that the affected code of resolving that story would belong to a certain single team. That will make a much nicer flow, especially at scale. One question that we should ask ourselves is how user stories are organized. From a domain-driven perspective, user stories are organized according to subdomains. If we just take a standard e-commerce app, that's the most simple domain we can think of, then a normal split to subdomains will be something like a catalog, order, delivery, support, and perhaps some other subdomains. The catalog subdomain concerns about allowing users to browse and search products, while the other subdomains concern users throwing products into subcards and asking for delivery.

What we can do is to organize teams according or around business concerns in alignment with subdomains rather than around some technical concerns like components, pages of views, and such and so on. Together with Conway's law, which states that organizations tend to mirror their own structure in the software they build, we are very likely to get this software that is split nicely and that user stories are very likely to fall under the responsibility of a single team.

Now, that can be taken further, and this is where we talk about microfrontends again. by splitting up this monolith into different microfrontends that will enhance the segregation that we do between between subdomains, and it will also give teams a further level, another level of autonomy on the technological stack level because now they can choose their own tools and in the design patterns for example. Each team can optimize the design patterns uses for the specific target, the specific goals that you want to achieve.

So my point here is that a solid ground for microfrontend is to consider the alignment with business aspects. This is why when we talk about microfrontends we have to think about domain driven design, specifically about strategic DDD. So strategic DDD is this toolkit that allows us to properly or correctly decompose our domain into various subdomains in a way that will maximize the potential that microfrontend has.

DDD really tells us to gather our domain experts to take the time and brainstorm together with other stakeholders to form this unambiguous language that really captures the natural entities and processes that happen within this subdomain. And this language form is logical boundary that we call bounded context. Bounded context has a lot to offer, a lot of benefits to work with bounded context and derive from them the actual microfrontend implementation.

So each bounded context will derive an implementation of a certain microfrontend. We could summarize that by saying that a microfrontend is a technical implementation of a bounded context. So having a bounded context that derives microfrontends has numerious benefits. Bounded context can drastically simplify the implementation of each microfrontend because each term in each bounded context is described from the perspective of that bounded context. So you don't have a lot of redundant information that you need to handle. You only handle the stuff that are relevant within that context. And there is a deeper benefit to that. And now we have this in each context we have unambiguous cohesive language that everyone understands. And that makes communication much better. And that makes it makes a translating user stories much easier and so on.

But I want to focus on another benefit that relates to how a micro-frontend should communicate. We have another tool that is part of the DDD tool kit is the context mapping tool. Context mapping is about understanding, brainstorming and understanding the relationships between different contexts. So for example here although the product term usually means something else, something specific when we talk about catalog context, for example a structure that displays all the comments, reviews, a product details, product images, and so on, that means product will mean something else in the order context. It will probably have some id, price, discounts, or everything that relates to order.

But still although they are defined differently in those different contexts, they still have this logical connection between them, right? Because we want to allow users to drop products that they find in the catalog into some cart that is naturally part of the ordering context. And that can be, that really a really derives a communication that we must that we must have between catalog front-end and the order front-end, right? That pieces of information, a selected product, have to be communicated between these micro front-end.

So we see here a way to logically understand what are the connections that we should do between context, and then derive from there the communication between the implementation, between actual micro front-end. And that can help us avoid unnecessary communication, and it can also help us to understand if our model is right, whether we don't, we are not creating too much communication, and so on.

So I think it's very it's very important to have some logical a backup, or a reference point to your implementations. Now, once that we have this reference point, we understand how to map these communications, we would like to talk about, okay, how should we technically implement a communication between microfrontends, and especially without breaking their a isolation from each other, without coupling them. So, a straightforward answer to that will be okay, let's not have this direct communication between microfrontends, let's use the backend. So we are basically shifting our state to the backend, and a catalog microfrontend could communicate the selected products to the backend, while any other microfrontend that is interested in that information could consume that information. And this is very good because microfrontends are still isolated from each other. The problem is that, well, if you have a lot of microfrontends, different microfrontends in the same view, then you probably have some UX disadvantage because calling the backend is slower. It feels like less performant. Another problem is that we are moving a frontend complexity into the backend, where it's not really belongs. So it also makes some problems, some bottlenecks in development because now frontend developers are blocked by backend developers whenever they have to do some change.

So let's talk about direct communication between micro frontends. This is a very general problem in software engineering. We have these different units that are independent of each other. We don't want to have them coupled with each other, but they still have to pass messages between each other because they are part of a bigger team.

So if we take a look at what we are doing in backend software design, it's usually about micro services and micro frontend and micro services have some correlation between them. That's a chance to learn a lot about micro frontends. So if we take a look on how micro services communicate, one of the most popular and powerful patterns is the public subscribe mechanism, asynchronous messaging. Each micro service can publish information, interesting stuff that happens within the micro service to some shared space, like a message bus, and any other micro service could consume this information in case it's really interesting. So this makes micro services still decouple from each other in a way, but still allows a very nice, very powerful communication.

So we could derive from that a solution to our micro front-ends, right? We could use the window object, which is a great common space that every micro front-end can communicate with. And each micro front-end could publish interesting events about stuff that happens, like product that was selected for the card, and any other micro front-end could consume this information. So, different micro front-ends are not aware of each other, but they can still pass imported information. So, that can be implemented very easily and even natively using custom events. We can create custom events and dispatch them into the window, and we can add event listeners to the window to get this information back. So, you could wrap that mechanism with your React or Vue framework and build something more advanced that can help you automate some of this communication or make it more robust.

Now, that was nice, but sometimes, you just have to have a state. So, communicating with the event is great, but there are some complex operations or some complex constructs of data that we wanted to have a shared or some sort of states like a Redux state to manage the process, and that can happen quite often. So, what we would want is this a centralized Redux store and every microfrontend could communicate with in order to maintain these kind of complex states. And this is very problematic, especially when we talk about microfrontends, because this completely breaks the isolations that they have from each other, especially that they are owned by different teams.

So what we really wanted is these nice, aligned stores. We have a store per microfrontend. Each microfrontend can use that store like a Redux store, and these stores are decoupled from each other. But, of course, here we don't have any communication between them and that's also problematic. So another solution that I've seen to maintain a state between microfrontends in a way that still keeps them quite decoupled is to allow microfrontends to subscribe or view stores of other microfrontends, but without the ability to mutate these stores. So in this example the support microfrontend can really, the product microfrontend, delivery microfrontends can view the store of the support microfrontend, but still there is some problem, there are some problems here, because any change in how the support store is implemented would affect the delivery and product microfrontends. So what we can do to make it even more secure is to come up with this global store. This global store manages the different stores of the different microfrontends, each microfrontend can subscribe to the store, it has its own store that it can manipulate, and other microfrontends can consume and subscribe to their own stores or other stores. Because this global store would expose some specific API, then each microfrontend will just have to implement that specific API and that will make everything much easier that will align this API across those different microfrontends.

Well, so that was like an overview of three common ways to maintain communication between microfrontends while keeping them quite isolated from each other. So I would like to summarize the talk and the first thing that we say that is to strive toward highly autonomous teams we should structure teams in alignment with business subdomains and that doesn't relate directly to microfrontends you can definitely have a monolith that is aligned with a business aspect. Although applying microfrontend architecture could enhance this idea by segregating business concerns in a better way. And by applying strategic DTD we can identify subdomains model them into bounded context and apply context mapping to find relationships between them. And we also say that the microfrontend is a technical implementation of the bounding context. So context mapping can help us identifying the spots, the touch points where microfrontend should communicate. And a one important rule is that communication between microfrontends should keep them isolated from each other. So that's the summary of the talk. I hope I gave you some inspiration about how to apply DDD in problems that we encounter in front end, and how to facilitate a communication between microfrontends in a way that will help you achieve goals like team's autonomy.