Multiple apps, one code to rule them all

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

More and more, React is being used for complex apps that accommodate numerous types of users, workflows, and mechanics. Sometimes it’s different people who each use part of the app, but a single-user multi-workflow scenario isn’t uncommon as well.

In this session, we’ll learn about our options when building multiple experiences within a single React app — without losing our sanity. I’ll use some examples from what we do at Wilco.

This talk has been presented at React Summit 2022, check out the latest edition of this React Conference.

FAQ

Jem Agnesi is the CTO and co-founder of Wilco, a learning platform for engineers to practice their development skills. He has previously worked as a senior engineer and staff engineer at WeWork and Meta.

Wilco is a learning platform designed for engineers to practice their development skills through real-life scenarios and quests.

The two main user experiences in Wilco are the Wilco platform, which features a sleek, dark theme, and a game that users enter through a portal mimicking an old cooperative company.

Wilco decided against using micro front-ends due to the complexity involved in deployment and state management between apps. They preferred a single app approach for easier state sharing, analytics, error reporting, and code sharing.

Using a single app allows for seamless state sharing, unified analytics and error reporting, simplified code sharing, a single repository, and easier deployment.

The Shell app is a hosting application in Wilco that decides which mini-app to connect to the user's view based on various parameters like user path, subdomain, or user role.

Wilco handles routing between different experiences using either domain or path-based routing. They opted for domain routing, despite its complexity, to distinguish between the two apps.

Wilco uses a dedicated subdomain for authentication and employs an iframe to handle token sharing and session management across different subdomains.

Code splitting in Wilco's architecture ensures that only necessary resources are loaded for each application, improving performance and reducing network load by creating separate bundles for each mini-app and shared code.

Conway's Law states that a product's structure reflects the communication structure of the team that built it. In Wilco's case, having a small, close-knit team influenced their decision to maintain a single app to avoid isolation in the product.

Shem Magnezi
Shem Magnezi
20 min
21 Jun, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
This Talk discusses the benefits of using a single app to host multiple experiences or mini-apps, as opposed to a micro front-end architecture. By using a single app, it becomes easier to share state, simplify code sharing, handle analytics and errors, and deploy and monitor the app. The Talk also covers the handling of the shell app, routing, authentication, and subdomains for authentication.

1. Introduction to Multiple Apps

Short description:

Hello everyone and welcome to my talk, multiple apps, one code to rule them all. Today I'm going to talk a little bit about one interesting use case that we had in Wilco back when we started. In Wilco, we had a couple of screens, a couple of experiences. We need to create two experiences for the user, they move between them. This is one is micro front-end, and we are able to break it to micro front-end, and we can play with the new hotness that JavaScript is always hyped on. But before we going and implement this very, very hard architecture, I want to tell our team to wait a minute and stop and think about this architecture, if this is really what we want to do. Because I don't want this to be a rant against micro front-end, I love micro front-end, I understand the value. In this talk, I want to maybe convince you and maybe stop you before you go in this path.

Hello everyone and welcome to my talk, multiple apps, one code to rule them all. Today I'm going to talk a little bit about one use case, very interesting one that we can learn about it. But before we begin, I want to talk a little about introduce myself.

My name is Jem Agnesi, I'm the CTO co-founder of Wilco. In Wilco, we are trying to build a learning platform where every engineer can practice their development skills and get real-life scenarios to practice on. Before Wilco, I've been working as a senior engineer and staff engineer at WeWork and Meta. You can find me on Twitter on this handle. And as I said, today I want to talk a little bit about one interesting use case that we had in Wilco back when we started.

In Wilco, we had a couple of screens, a couple of experiences. So as I said, we are building some kind of platform that lets users and developers to do some kind of quest, where each quest is some kind of practice for the development skills. So one experience is the Wilco platform, as it's called. And as you can see, we have a feed of quest of the future stack, the future quest, the previous quest that user did, the current quest that is now, the user profile, the skills, the number of coins and the points that you got. This is, as you can see, very sleek, black, dark theme look and feel. On the other end, we had the game. When you start the game, you enter some kind of portal of a very old and cooperative company. Again, you're able to see your current quest, what you need to do. You have all kinds of links. You have your users. Those two experiences are very, very different. This is one of the first requirements that we got from our product management. We need to create two experiences for the user, they move between them.

I know what you immediately think if we have one item. So, this is one is micro front-end, and we are able to break it to micro front-end, and we can play with the new hotness that JavaScript is always hyped on. And understand, and this is what we had in mind when we first thought about it from our product management. And before we going and implement this very, very hard architecture, I want to tell our team to wait a minute and stop and think about this architecture, if this is really what we want to do. Because I don't want this to be a rant against micro front-end, I love micro front-end, I understand the value. I even gave a talk about it, as you can see. And as one that play with micro front-end and see all kinds of solutions that we have there, we really need to understand that micro front-end can introduce many complexity around the deployment and how we are working with those apps. There's a lot of things that you should think before you dive to implement this kind of architectures. And in this talk, I want to maybe convince you and maybe stop you before you go in this path.

2. Benefits of a Single App

Short description:

When we pick one single app that hosts multiple experiences or mini-apps, we can easily share state between them. This simplifies the sharing of data and user progress, which would otherwise require a lot of work in a micro front-end architecture.

Because once you go this path of micro front-end, there is a lot of things to do. And it's not really that easy to revert. So, why would you, why would one pick one single app to create this kind of solution of two very different experiences? When we pick one single app that hosts those two or more experiences or mini-apps, we are able to share state between those apps. Okay? As you saw before, we have two very, very similar apps, maybe not in the look and feel but in the data that they show, the current quest, the user, where they're at, what are they able to do, in what state they are. And once you are doing it in one React app, you are able to share it easily. It's not that you're not able to share state between hyperfronted but this is a lot of work to do and you don't get it out of the box.

3. Benefits of a Single App (Continued)

Short description:

When working on a single app, we get the handling of analytics, reporting, and error handling for free. Code sharing becomes simpler, as there is no need to split the codebase into multiple repositories. Single deployment and monitoring simplify the technical aspects. Conway's law highlights the importance of team structure in the product's architecture. To implement a single app, a shell app is built to determine the appropriate mini app based on various parameters, such as the user's path or role.

Another thing that we get for free, when you work on a single app, is all the handling of analytics and reporting because remember for our use case, when the user journey looks very solid, they start from the Wilco homepage and dive deeper to the game and the playing end portal and we want to keep these analytics in the same view to track the user flow along the way, so we need to have the same analytics, same for error reporting, we don't want two instances of error reporting to follow and many more.

We also have a lot of code that is shared between those two apps, whether it's the user session that we need to manage, whether it's the code that fetches things from the server, maybe it's error handling and stuff like this, so once we have one single React app code sharing is something that's very simple. Again there are some kind of solutions also for micro-frontend but it is a little bit trickier and a lot of things to set up.

When you have one single app you are able to leverage one single repo. You don't need to split it into a couple of repositories that you need to maintain, that you need to watch, that you need to manage. One single repo, just like one single app, again, as I said before, also for a micro-frontend. You are able to work on one single repo but you have to set it up. There is some kind of overhead to set up young workspaces or learner and so there are solutions but there is some kind of overhead but you get it for free.

And one last thing, on the technical side, you are able to get only single deployment, one deployment to watch and one deployment to monitor. There are pros and cons, for example, if you introduce change to only one app you will get also deployment to the other app but from what we saw, most of the cases you are changing both ways, so that's okay for us. But outside of the technical thing that you need to keep in mind, there is also one thing that I want to talk about when splitting a repository and splitting applications and this is the Conway's law.

For the one that is not familiar with Conway's law, it says that your product, what you build and the stuff that the users get is really a copy of the structure of your team or how you communicate. So for example if you have many teams inside your organization, for example, one for the front end and one for the back end and another one for the messaging view, another one for the menu, the product will look like this. You will see an isolated or pillars where you see that there is some kind of isolated teams and for our case we had only one team, one very small team remember we are a start-up we just started we are very small and I didn't want to create some kind of isolation in the product because our team was very small and very close to each other so I wanted all teams to be able to work on both apps and will be able to write a PR or write code that change all of them together and that's one of the things that you need to keep in mind. It's not just technical maybe the technical issues. These are more easy to evaluate but maybe the hardest thing that you will need to change is the team structure. This is very, very important to think about.

Okay, so I hope I convinced you that there is some value to keep this kind of application as one single app. So, let's see how we are going to do this. So, at the end of the day what you're going to build is a shell app. This is the hosting app that will be able to decide what is the right application that they need to bundle or what is the right application that they need to connect to the user's view. In this shell app, we'll get a request and, based on all kind of requirements, or all kind of parameters, we'll be able to decide what is the right mini app that they need to connect to the shell app. And this decision can be in all kind of properties. For example, in our use case, it was based on the user's path. If user goes to app vilko, it will get the dark one, and if it will get to anything.vilko, it will get the anything portal. You can also get it based not only on subdomain. You can get it based on the path of the app. Maybe you get it based on the user role. Maybe a regular user will get one experience and admins or internals or logged in users will get the other one. Maybe based on the view of the users, whatever you want to decide on.

4. Handling Shell App, Routing, and Authentication

Short description:

The shell app handles common functionality across applications, such as error handling, global app state, session handling, API communication, web sockets, and caching. The routing can be based on the domain or the path, but using domain routing may result in difficulties with shared state in React. Authentication syncing between apps requires careful handling to ensure seamless login and logout experiences. Sharing cookies between subdomains can be challenging.

The question mark there. In the end of the day, it's a JavaScript function that you can decide. The shell app, as you can see, I hope you're able to see it. The shell app will handle all the stuff that's common to all your applications. Whether it's error handling, as you can see there, we are using WorldBar. Global app state that we say that you are able to share between those applications. Session handling, whether the user is logged in or not. And if not, we directed him to the right path. API, the communication with the server and maybe authentication, stuff like this. Web sockets and we get notification from the server, how to show notification, how to create and open this web socket, caching, etc. All those very common things that you need to handle, both on the Portal app or the WorldBar. And as you can see, all those happen seamlessly, no matter what application you are binding and based on, specifically here, the window location or region, we're able to plug in the right application.

Okay. So we handle the Shell app and then we need to decide whether we want to do it on on what routing we need to do it. Specifically for us, we had two options. Whether to use the domain, the sub domain, as I say, app.will.gg or anything.portal.gg. So we have the option to decide on the domain or the path. They will use the same domain, but we will decide based on the path, maybe. will.gg.slash.app will.gg.slash.portal. This is something that we talk about together with our product. One thing very probably that we need to keep in mind when using domain routing, you are not able to leverage the shared state seamlessly inside React with one context, because when moving between domains, you have some kind of refresh. You are not able to just use push state, this is in Mozilla specification. So this is something that we discussed a lot with our product and decided to go still with domain to distinguish between the two apps and maybe lose a very easy state management or saving state between these two apps. There are still some kind of solution whether to use iframe behind the scene, shared state, and moving the state to the server, but it's not that easy. It's not that easy and you don't get it out of the box.

So we have the shell up, we decided on the routing, now we need to handle authentication. And what we needed in our case, because we used Auth0, but it doesn't really matter what authentication provider you use, but you have to handle all the syncing between those two apps. When I'm logged into Wolco, to the application, I also want to be also logged in to Portal seamlessly without me or the users needing to register again, or putting their username and password again, and the same like when you're starting from Portal. And also when you're logged out, you need to clear all the session from all the other apps. We were taught that it's simple, but it's not that simple, because the sharing between subdomain, as we saw, is not working that easy, because you're not able to share cookies easily between those.

5. Authentication and Subdomains

Short description:

We set up a dedicated subdomain for authentication and used an iframe for sign-off authentication to obtain a token. For more details on this specific solution, I recommend reading our blog post by Eric, which covers the implementation steps and code requirements for handling session movement between subdomains.

So what we did is to create, and we set up a dedicated subdomain for the authentication that we are able to leverage for those two apps. And in one of them, we created an iframe behind the scene that's doing authentication, sign-off authentication to get a token. I'm not going to talk a lot about it. It's very, very specific for the solution that, if you choose a subdomain, but if you have this in mind too, I will recommend you to read our blog wrote by Eric from our team. There is a lot of explanation there. How to do it, what code you need to write, how the session is moving between all subdomains, and what you need to do to support it.

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

Scaling Up with Remix and Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Understanding React’s Fiber Architecture
React Advanced 2022React Advanced 2022
29 min
Understanding React’s Fiber Architecture
Top Content
This Talk explores React's internal jargon, specifically fiber, which is an internal unit of work for rendering and committing. Fibers facilitate efficient updates to elements and play a crucial role in the reconciliation process. The work loop, complete work, and commit phase are essential steps in the rendering process. Understanding React's internals can help with optimizing code and pull request reviews. React 18 introduces the work loop sync and async functions for concurrent features and prioritization. Fiber brings benefits like async rendering and the ability to discard work-in-progress trees, improving user experience.
Full Stack Components
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
RemixConf EU discussed full stack components and their benefits, such as marrying the backend and UI in the same file. The talk demonstrated the implementation of a combo box with search functionality using Remix and the Downshift library. It also highlighted the ease of creating resource routes in Remix and the importance of code organization and maintainability in full stack components. The speaker expressed gratitude towards the audience and discussed the future of Remix, including its acquisition by Shopify and the potential for collaboration with Hydrogen.
Thinking Like an Architect
Node Congress 2025Node Congress 2025
31 min
Thinking Like an Architect
Top Content
In modern software development, architecture is more than just selecting the right tech stack; it involves decision-making, trade-offs, and considering the context of the business and organization. Understanding the problem space and focusing on users' needs are essential. Architectural flexibility is key, adapting the level of granularity and choosing between different approaches. Holistic thinking, long-term vision, and domain understanding are crucial for making better decisions. Effective communication, inclusion, and documentation are core skills for architects. Democratizing communication, prioritizing value, and embracing adaptive architectures are key to success.
Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
Watch video: Debugging JS
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
A Framework for Managing Technical Debt
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Top ContentPremium
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.

Workshops on related topic

AI on Demand: Serverless AI
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Top Content
Featured WorkshopFree
Nathan Disidore
Nathan Disidore
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.
Building a Shopify App with React & Node
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
Workshop
Jennifer Gray
Hanna Chen
2 authors
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
Build a chat room with Appwrite and React
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
Workshop
Wess Cope
Wess Cope
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
Hard GraphQL Problems at Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
Workshop
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
Build Modern Applications Using GraphQL and Javascript
Node Congress 2024Node Congress 2024
152 min
Build Modern Applications Using GraphQL and Javascript
Workshop
Emanuel Scirlet
Miguel Henriques
2 authors
Come and learn how you can supercharge your modern and secure applications using GraphQL and Javascript. In this workshop we will build a GraphQL API and we will demonstrate the benefits of the query language for APIs and what use cases that are fit for it. Basic Javascript knowledge required.