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

Rate this content

Micro frontends architecture is extremely powerful when it comes to splitting large frontend monoliths into smaller, individually deployable blocks, each is owned by an autonomous team and is focused on a business domain. But what about State? We are often told that micro frontends shouldn't share state, as this would make them coupled to each other. However, when it comes to complex UIs, it is not rare to encounter scenarios where state management between micro frontends is necessary. This talk is about finding the sweet spot — In which scenarios it is reasonable for micro frontends to share State? and how should micro frontends share State while remaining decoupled of each other? We discuss & compare different solutions in React.

23 min
21 Jun, 2022

Video Summary and Transcription

Micro-frontends allow development teams to work autonomously and with less friction and limitations. Organizing teams around business concerns, in alignment with subdomains, rather than technical concerns, can lead to software that is split nicely and user stories falling under the responsibility of a single team. Having a logical backup or reference point is important for implementing microfrontends without breaking their isolation. Microfrontends can communicate with each other using the window object and custom events. Microfrontends should be kept isolated while maintaining communication through various approaches.

Available in Español

1. Introduction to Micro-frontends

Short description:

Micro-frontends allow development teams to work autonomously and with less friction and limitations. We will explore a domain-driven perspective to understand communication between micro-frontends. Resolving user stories should be an end-to-end task of a single team, rather than shared between multiple teams. User stories are organized according to subdomains.

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.

2. Microfrontend Implementation and Communication

Short description:

Organizing teams around business concerns, in alignment with subdomains, rather than technical concerns, can lead to software that is split nicely and user stories falling under the responsibility of a single team. Microfrontends enhance segregation between subdomains and give teams autonomy over the technological stack. Domain-driven design, specifically strategic DDD, helps decompose the domain into subdomains. Each bounded context derives an implementation of a microfrontend, simplifying the implementation and improving communication. Context mapping tool helps understand relationships between different contexts and enables effective communication between micro front-ends.

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.

3. Implementing Communication Between Microfrontends

Short description:

Having a logical backup or reference point is important for implementing microfrontends without breaking their isolation. Using the backend to communicate selected products while maintaining isolation is a straightforward approach. However, this can lead to UX disadvantages and frontend complexity being moved to the backend, causing development bottlenecks.

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.

4. Direct Communication Between Microfrontends

Short description:

Microfrontends can communicate with each other using the window object and custom events. For managing complex states, a centralized Redux store can be used, with each microfrontend having its own store. Another option is to allow microfrontends to subscribe or view stores of other microfrontends without the ability to mutate them. To ensure security and alignment, a global store can be implemented, with each microfrontend implementing a specific API. In summary, microfrontends should be kept isolated while maintaining communication through various approaches.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up