Multiple apps, one code to rule them all

Rate this content
Bookmark

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.

20 min
21 Jun, 2022

AI Generated Video Summary

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

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
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.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
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.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Workshops on related topic

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 Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
WorkshopFree
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.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
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!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
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.
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.