Multiple apps, one code to rule them all

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.

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.

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.

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.

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.