Scalable React Development for Large Projects

Rate this content

Scaling React development across multiple teams can be incredibly difficult. Teams need to share core functionality while staying autonomous. Changes need to propagate through many projects while being tested. Nx is an open-source toolkit that allows organizations to scale development more easily than before! Nx makes setting up Cypress, Prettier, Storybook, Next.js, and Gats faster than ever. You can also develop full-stack using Node frameworks like Apollo and Nest.js and share code between frontend and backend. In this talk you’ll learn how large organizations like Facebook, Microsoft, and Google are able to successfully scale across multiple teams, business units, and products.

35 min
02 Aug, 2021

Video Summary and Transcription

Scalable React development made easy by NX, a monorepo-based approach used by large tech companies. Challenges of sharing code in multiple repos include duplicate tooling, separate workflows, and version conflicts. Benefits of a monorepo include unified tooling, single version of dependencies, and simplified development. NX enables monorepo workflows with intelligent build systems and easy code sharing. It also supports custom code generation, enforces standards and dependencies, improves build times, and provides modern tools and plugins.

Available in Español

1. Introduction to Scalable React Development with NX

Short description:

Hey, everyone. My name is Jason. I'm here to talk to you about scalable React development made easy by NX. I'll introduce the concept of a monorepo and explain why it's beneficial. Monorepos are used by Facebook, Microsoft, Google, and other large tech companies to develop and deploy code independently.

Hey, everyone. My name is Jason. I'm here to talk to you about scalable React development made easy by NX. So first, I'm going to go through an introduction of myself, and I'm also going to introduce the concept of a monitor about to you, and then I'm going to go more in detail about what NX is and how it can help you scale your React development. Then we'll do a live demo at the end, given that we have time. So let's get started.

A little bit about myself, you can find me on Twitter, at Fersenpandas. I'm an architect at Narwal. And I'm also a part of the NX Core team. So I work on NX as part of my full-time job. At Narwal, we consult for Fortune 500 companies. We are experts in monitoring code development, and we also create dev tools to accelerate monitoring code development. So my whole job is to accelerate companies' work faster and more efficiently. And that's where NX comes from.

But before I go into NX, let me tell you a bit about monorepos. So first I want to say what a monorepo is not, because there's a lot of misconceptions. Then I'll tell you what it is, and then I'll tell you why one might want to use monorepo. So a misconception about a monorepo is that it is not a monolithic application. This means that you don't have to build it all at once. You don't have to build one big application out of a monorepo. And you also don't have to deploy the whole monorepo at once. And let me go into more about what a monorepo is, so that you see where this is a misconception. A monorepo is just a single repository that has multiple projects, meaning there's one piece of the code living in one directory, and another piece of the code living in another directory, but it's all one version control. I think of it like a warehouse for code. In a warehouse, you have packages that are packed separately by different people. They're stored together in one warehouse, but then you ship them separately to different people. And the same is true for projects within a monorepo. They're developed independently with a repository, but they're deployed independently. Who uses monorepos? So, Facebook, Microsoft, Google, they all use a monorepo, as well as other large tech companies. And I don't think it's a coincidence that a lot of these successful large tech companies have gravitated towards a monorepo approach to development.

2. Developing Apps without Monorepos

Short description:

Let's take a look at how we usually develop apps without monorepos. I have my app, but I also split out the functionality into different pieces of the code. I stick everything into one Git repo, set up NPM, Jenkins, or Travis, and work on different pieces of the code and the application simultaneously. This workflow is familiar to many.

So, let's take a look at why they choose to do so. Let's take a look at how we usually develop apps without monorepos. So, I have my app, but I also split out the functionality into different pieces of the code, right? So that my code is organized. I stick everything into one Git repo. I set up NPM, and I set up Jenkins, or Travis, and everything works together. I'm able to work on different pieces of the code, as well as the application itself at the same time. And then, I'm able to test everything all at once. And this is a workflow that many people are familiar with.

3. Challenges of Sharing Code in Multiple Repos

Short description:

Soon, we'll need to share code between different applications within our organization. This becomes challenging when everything is in one repo. Splitting code into multiple repos introduces duplicate tooling, separate workflows, and loss of context. Analyzing the relationships between repos becomes difficult, and versions can become out of sync, leading to confusion and conflicts.

However, soon we're going to need to share the code between different applications within our organization. Not only do we have the car application, but we might have an API and a shop application as well. And they might want to access parts of the code that we had written previously for the car application. So, this is really hard to do because everything is in one repo, and you can't really bring in the pieces of car without bringing in car as a whole.

So, I'm going to talk about share code in multiple repos, how many of you are probably used to doing things, and this is going to be the more complicated way of the two. So, when you realize you want to share code, you decide, okay, that means I have to split out all my code into different repos. So, you go ahead and make all these get-up repos, and people all work on them. So, this immediately introduces the need for duplicate tooling. Not only do you have multiple repos, you also have multiple CI flows, you also have multiple versions of NPM dependencies, and all that. And for every repo that you set up, you need this.

So, along with duplicate tooling, you also have to separate your workflow. When you work on this library over here, you can only run those tests because the other tests live in different repos, so you're stuck with running only these tests. Therefore, you don't know if the car application is broken or not, so you have to do some work over there as well. Then you can run those tests, but you'll also notice that API also depends on its library, so you have to do the same thing over there. And this is kind of like three different phases of your workflow, it's very discontinued, and you lose a lot of context when switching from one place to the other. Not like before, where we could work on the car application and our library at the same time. But, because people want to share code, this is what we have to deal with.

Also, those clear lines that I have drawn between these projects, they are less analyzable when one is using multiple repos. Multiple repos are usually linked through methods like npm, through package.json, and stuff like that, and it's really hard to be able to analyze them, so those lines become less visible when we're looking at our organization as a whole. All we know is that we have, you know, six different repos, but those are related in ways that we can't easily analyze through code analysis. Then, we also can grow out of sync. A lot of times, when we split things into different repos, we publish different versions, so at the beginning, everything might be a version 1. It works together. It's great. But then, in the bottom library over here, we might release a second version, right, that has some changes, and other libraries have to pull those changes in. So, the one on the right will pull it in and upgrade to version 2 of this bottom library, but the library on the left will choose to do it later.

So, they're gonna stay on version 1 right now. And that might seem like a fine decision at this view of the world, but when we go back to our organization, the car application that uses both of these libraries is very confused right now about which version is the correct version. And more than likely, it'll actually bring in both versions, and we kind of run into the jQuery days where there's three versions of jQuery on the page. And this goes the same for external dependencies as well, such as React.

4. Benefits of a Monorepo

Short description:

When different repos depend on different versions of React, it can lead to confusion and complications. However, using a monorepo, all the code can be stored under one repository, providing unified tooling, a single version of dependencies, and the ability to test only what's necessary. This approach simplifies development and benefits the people within the organization.

When things are different repos, they can depend on different versions of React, and in our organization, we might have version 16, version 15, and version 0.14 all at the same time. And each application might use a different version, it might be confused about which version it should bring in, and things like this. So let's talk about how we can do this easier and less complicated.

Using a model repo, we would store all this code under one repo. And I know what everyone's thinking, this goes out of scale, but later on I'll show you that it doesn't. One thing we see is that our tooling is once again unified. We have one repo, one CI flow, and one npm dependencies. Also, those dependencies that we had drawn are very analyzable now. They look like import from this file, from this file, and we're able to see what projects depend on other projects. That way I can work on both of these at the same time. I can work on my library, I can work on my application, and when I push it up to see if my changes look good, I can also run the specific set of tests that are sufficient for verifying that my change is accurate and good. So the other libraries towards the left of the screen, those don't have to run because my changes don't affect them at all. There's also a single version of every project and all your dependencies. So it just moves ahead. Whenever you check out a new branch, you have the same version that works together with everything. This also means that you can commit to multiple projects under one commit and you don't have to worry about keeping it synced to versions. And the same is true for React. So once we upgrade to version 16 of React, our whole repository and all of our applications are on version 16.

So I went through a lot of information. Let's just take a step back and review. So using multiple repos, you don't have clear dependencies. You have multiple versions of everything, and you have a lot of duplicated tooling. When you do the same thing via a monorepo, you have one set of tooling. You have one version of dependencies. And you're also able to test only what's necessary to be tested at a time. Sounds pretty cool. So at the end of the day, why use a monorepo? Isn't it just how you store your code? And I don't think so. I think it's actually about the people. It's not just about the code. And our people are organized under one company and one organization.

5. Implementing a Monorepo Workflow with NX

Short description:

We can use nx to implement a monorepo workflow, enabling scalable development across multiple teams. nx allows us to develop like Facebook and provides an intelligent build system. It supports modern tools and facilitates easy code sharing between teams. Through code generation, we can create workspaces with zero manual setup.

And we're all one team. Even though we might have different responsibilities within our organization, we work as a team and have one goal. So let's take a look at how we can use nx to implement a monorepo workflow. nx is an open source toolkit that enables you to scale your development across multiple teams. So this means multiple applications back-end, front-end. It allows you to do it all.

The first thing that's a major feature is it allows you to develop like Facebook. We'll go into more detail as well what this means. The second thing is that it has an intelligent build system. So like before we were able to see our different projects be analyzed and tested appropriately and nx is able to do that. It also supports the use of modern tools, such as storybook and I'll go into more detail about each of these.

So for developing like Facebook, as you saw with the moderate approach, you're able to share code very easily between different teams. This also gives you a holistic development experience. You have all these different projects under one hood and you're able to see how different pieces work with one another and what's going on in each part of the repo. It may not be important at all times, but when you're working on a specific task that involves another library, it's wonderful to see what's going on there. So the next thing is how you can stay consistent. Through code generation, we're able to create a workspace with zero manual setup. We run mpx create-nx-workspace with a preset of React and we get this workspace generated with our new app for cart.

6. Adding Shared Functionality and Generating Code

Short description:

You can easily add shared functionality without creating a separate repo or setting up a CI flow. With nx generate-lib-shared-button, you can generate a shared button that can be used across multiple applications without publishing to NPM or setting up CI. You can also generate Redux state with nx generate-redux-cart-directing-into-the-project-of-cart-state, creating a cart slice with predefined actions. Additionally, you can add Next to your project using nx generate at rwnellnext app shop, allowing you to generate a new shop app in the same repo as a cart application with minimal setup.

You can add shared functionality very easily. Before, you'd have to create a different repo, you'd have to set up a CI flow, publish the NPM. But now you can run nx generate-lib-shared-button, and now you have a shared button that you can use across multiple different applications without publishing the NPM and without setting up CI.

You can also generate Redux state. Everyone knows there's a lot of boilerplate and even with the changes that are in the Redux toolkit, there's still a lot of code that you have to write to get started. Well, now you can generate it using nx generate-redux-cart-directing-into-the-project-of-cart-state. This is automatically generated for you, and you can see that we're able to create a slice with a cart, and it even has some actions predefined for you that you can change after you've generated the code.

You can also add things like Next. Using Yarn at rwnellnext and nx generate at rwnellnext app shop, you're able to generate a new shop app in the same repo as a cart application without much setup at all. And Next is fully configured and ready to go.

7. Custom Code Generation with Workspace Schematics

Short description:

If you don't like what NX generates, you can write custom code generation using workspace schematics. This allows your organization to generate code that implements your desired best practices. It's useful for integrating with different projects and ensuring a consistent code layout.

What if you don't like what NX generates? There's so many tools in the ecosystem that we all love and want to use, but it's understandable that you might not like what NX decides to generate for you. And we've also taken that inspiration, you're able to write workspace schematics, which are custom code generation that suits your organization, using NX workspace best practices. And this really allows your organization to stay consistent by generating the code that implements the best practices that you want to have. This is really useful when you want to integrate with different projects, you want to have a consistent way of laying out your state, and stuff like that. This is one of my favorite features of NX.

8. Enforcing Standards and Dependencies with NX

Short description:

NX helps enforce standards and best practices by allowing you to tag different projects and ensuring that dependencies are structured correctly. It provides linting errors for incorrect dependencies and can infer dependencies based on code imports. The NX Step Graph allows for visualizing dependencies, which is crucial for the Intelligent Build System.

Also NX helps you enforce standards and best practices throughout your organization. So before we were talking about generating code in the right format, but what about the code that we write? One thing that is confusing about a Monorepo sometimes is that people think that any library can depend on any other library, and you get this ball of mud that you can't untangle and understand. So with NX, you can tag different projects, so the one on the left is tagged as state and the one on the right is tagged as UI, and we all know that state should not depend on UI. It should go the other way around. So if we make a dependency from the state to the UI, we get a linting error within our editor. Let me zoom in for that so that you can see the whole thing. A project tagged with state can only depend on state, right? It can't depend on state or a type of UI. NX is also smart enough to infer your dependencies. As we were seeing before, projects depend on one another, and it's important to know how those dependencies are structured. So taking the code like this, where I import product UI and also product state from my application, NX is able to infer that this application, the current application, depends on these two libraries without you having to explicitly say it. Then, once we know these dependencies, we're also able to visualize it for you. Running NX Step Graph, you're able to have an interactive view of all the dependencies within your project. So on the right, you see the product's home page depends on product UI. These dependencies are also crucial for the Intelligent Build System.

9. Improving Build Times and Using Modern Tools

Short description:

When using NX, you can build only the affected projects, reducing testing time. Building projects in parallel and distributing builds across multiple agents further improves build times. Caching previous builds and using a remote cache, like NX Cloud, can bring build times down to just two minutes. NX also provides modern tools like TypeScript, Jest, Cypress, and Storybook, allowing for efficient development and testing.

When people think of monorepos, a lot of the times they think of just running everything, right? And this is what Lerna does. And sometimes this grows to 60 minutes, or even more. And this isn't very scalable if we wanted to make a PR and check that it works within five minutes.

So let's take a look at some ways that we can improve this. NX allows you to build only the affected projects. As we saw before, for a little change in this really big monorepo, we don't need to test everything. So we can take out the bits in the project that are relevant to us at this time, and test only those, cutting our times by more than half, to about maybe 25 minutes in this hypothetical scenario.

Also, because we have different projects that are run independently from one another, we're also able to build them parallel now on the same machine. So we can run across two different threads, and you can see that our times, once again, have lowered by more than half. Then, you can also distribute builds across multiple agents. Not only can you parallelize them on the same machine, but you can actually distribute them. So if I have five different workers, I can now test these five different projects across different nodes in my CI. And as you can see here, the red bar over there is still quite long. In order to make that shorter, we can also cache the previous builds. If we've already done this build before, even though my change actually affects it, it can realize, hey, I've already done this build before. Let me not do it again. And it can pull that from a cache, bringing the times down to two minutes.

Now, the best way to do this is via a remote cache, which you can add by adding NX Cloud, which is our paid add-on to NX. But NX is open-source, again, so you don't necessarily need to. Six minutes is more than a favorable time going down from 60 minutes. But NX Cloud allows you to never build the same thing twice.

So, the last thing is being able to use modern tools. NX comes by default set up with TypeScript, Jest, Cypress, and Storybook. I'm sure everyone is familiar with Jest, and you might even have your own opinions of TypeScript, but you can also use JavaScript within your repo with NX. Two things that you might not be familiar with are Cypress, which is an end-to-end testing experience, so not only does it allow you to write your tests, but it actually gives you a UI where you can time travel through those tests, and make sure that you're not doing, kind of like running into issues when you're running your end-to-end tests. Storybook allows you to develop your components in isolation, the way that we like to think about it during our React developments, and this is really important to be able to see how these UI components look when they're isolated from the application that they're developed under. You can also install all these plugins a la carte. If you don't want Storybook, you don't have to install Storybook. You can install only React and Next if you want to use it. You can also install Node.js, Express, and HTML if you want it, and you can even install Angular and Nest.js plugins.

10. Using Plugins and a Live Demo

Short description:

All this is a la carte, so you pick and choose what you want. We also have community plugins for favorite tools. You can create your own plugin using mpx create-nx-plugin. Let's jump into a live demo. In our car application, the functionality in shared header is imported. Changes can be made and tested easily without having to go to a different repo. The application can be checked and updated with the latest changes.

All this is a la carte, so you pick and choose what you want, and you don't have anything extraneous that you're not using. We also have community plugins. We have the ability for people in the community to create plugins for their favorite tools, such as migrating from Karma to Jest or deploying serverlessly. On our wall, we can't support every single technology out there on every single community project, but the community has done a great job of creating plugins for other people to use. And you can actually create your own plugin. If you do mpx create-nx-plugin, it'll actually create a different workspace for you that's suitable for plugin developments.

So with that all out of the way, let's jump into a live demo. So I'm going to jump into a regular workspace here. This is already laid out, so I'm not going to show you all of the code generation steps, although we saw that it was fairly easy. Most of this code here was set up on a single page. Most of this code here was set up through code generation, but I want to take a look into our car application. In our car application, in our main component, we see that this file right here imports from a different project called a shared header. So we know as developers that, oh, obviously the car application depends on the functionality in shared header. So that when we have our NxExample header here, the functionality doesn't live within this directory right here. It actually lives in a separate directory. So let's follow that import. And we have our header elements. Being this is our header elements, we're able to see that this is the way it works without having to go to a different repo. If I wanted to change the way this works, I can add a console block here. Hello, React Summit. Save this. See that my changes are in Git. And so this is great. I can make a PR. I can check my cart application here by running current start cart. And now I can see my application running with our latest changes. So if I open this. Give it one second. Okay, so we're able to see that my console log shows up here. We have the header, and our car application still looks good.


Code Testing and Dependency Visualization

Short description:

NX can show you the dependencies in your code and automatically determine which tests to run. The depth graph feature allows you to visualize project dependencies and focus on specific areas. This eliminates the need for manual dependency tracking, which can quickly become outdated. You can find the example repo at narwhal/NX examples, showcasing the use of multiple frameworks in the same repository. Follow me on Twitter at Verzopandas and check out for more information. Now, let's move on to the Q&A session.

Going back to the code, now that we've changed this, we don't really know for sure until we run our tests, that the car application looks good within CI. So I could go in and test my shared header, and then after that I can do share or I can test my cart. So I can let those run. I'm going to trust that they both work, but it's kind of tedious to have these dependencies in my mind at all times.

NX can actually show that to you. So if I run effective test, it'll look at my changes in Git and realize that, hey, I need to check my cart and I also need to test my header. So it automatically knows this for you and you don't need to tell it. And this is great to be used in CI where you have an arbitrary number of changes across multiple projects and you want to test only what's necessary.

And I told you earlier that you can actually see the depth graph. So by running NX depth graph, this will open the interactive depth graph in a browser. So you can see a lot of projects here and they all depend on one another. But let's say I'm only working on my cart page right now. I can go in and focus on my cart page and see that these are the only dependencies that my cart page has separated from the rest. And if I don't really care about my product date, data here, I can exclude that from the view and see an even clearer picture. I can also group things by folder so that you can see where things live within the repository and stuff like that. This is really useful because in the past, an architect would go into a Wikipedia page and update with what they think is depending on one another and it very quickly goes out of date.

So that's about all the time I have to show you stuff in the code for now. So let's continue on with the presentation. You can find that repo that I was showing you examples from at narwhal slash NX examples. Please check it out, it has a car application written in React and the product applications actually written in Angular. So you can see how multiple frameworks can be used in the side same repo, but still share code between the two seamlessly. That's it for my talk. You can follow me at Twitter at Verzopandas and also please make sure to check out nx at, is for NX Cloud and follow us at Twitter nx DevTools. All right. Thank you very much and I'd love to answer your questions now.

Leadership, Code Dependency, and Deployment

Short description:

Thank you, Jason and Gene, for the outstanding talk on scalable React development. A monorepo can greatly improve collaboration and reduce friction between teams. Companies like Facebook have successfully used monorepos to deploy code quickly. With NX, you can easily migrate away if needed without changing your codebase. NX supports deployment to different environments, and monorepos can work well with micro front ends, simplifying management and reducing repetitive work.

That was great. Thank you so much, Jason, Gene for that talk. It was outstanding. And it reminds me, when I was working at IBM, we had these lots of micro services and it took a long time for us to get those things deployed and something like Nx really would have been helpful.

So, let's welcome back JJ. Thank you for coming on. We got some great questions from the audience. So, I'm just gonna launch right into it.

The first one is really interesting to me because I think it's almost the most important part of software development that we always don't talk about, which is how do you convince leadership and other people on the team to make a switch like this? And more specifically, how do you convince leadership that a monorepo isn't a tight coupling of code? Yeah, so, I think from the leadership standpoint is that you're gonna see a lot of collaboration across multiple teams. And there's a lot of dependencies between different teams that create friction when they're not working together well, and a monorepo drastically changes that. Companies like Facebook are able to collaborate between multiple different teams. And we actually have a case study with T-Mobile about how they were able to use a monorepo and deploy their new shop like really quickly, relatively speaking. And about tight coupling, like you have a lot of code but you can feel free to make multiple different copies of that code like Kent was talking about in his talk and stuff like that. So you can still have different relationships between your code and not necessarily tightly coupled.

Okay. So another great question here is, if you start using NX, how dependent does the code base become on NX? Like, if you decide later that you wanna stop using it, is it something that you can migrate away from easily? Yeah, NX is a dev tool, right? So it doesn't have to do anything with your production code. And the things that are under NX, while it's like really smart and we have it available for everybody, you can do it yourself, right? Or you can use another tool that also works with this. So companies like Facebook don't use NX internally, but they have their own tools. Like I think it's called Pants or Buck, one of them, right? And it does very similar things, but it's much harder to set up. But yeah, like if one day you decide NX is not working for you and you need something else, then you could move away from it. It doesn't change the way that you write your code, it just works around it. So, yeah.

So, let's see. Does NX support deployment to different environments, like if you wanted to deploy to Heroku? Yeah, NX supports... Every different project can be deployed differently depending on what they need. So there is actually a community plugin for Netlify and a lot of other services like Firebase. So it's like down to the project level. If you wanna deploy an API this way, you wanna deploy a front end another way, another front end another way, it's free, free room for you. A question that I saw that I really liked here is how could monorepos and micro front ends work together? Yeah, so I think there's a misconception that they're mutually exclusive and people talk about breaking up their monolith and into different repositories, but you can have all these different, micro front ends is different projects than this monorepo. And I actually think monorepo actually makes it easier to manage micro front ends right because when you break everything into separate front ends, when you get the task to change like the universal header across all of them, you just have this like huge plate of work going in different repos and making the same change multiple different times.

Working with Monorepo and Workflow

Short description:

With a monorepo, you can make changes and updates to all micro front ends at once, eliminating the challenge of working across multiple front ends. NX allows you to move publishable parts into NX and see the relationships between them. It also has the intelligence to run only a portion of your projects when necessary. Merge conflicts are less common in a monorepo, as developers typically work on different parts. For changes that affect the entire monorepo, there may be merge conflicts, but resolving them once is still more efficient than dealing with conflicts across different teams. A trunk-based development workflow is recommended for big teams working on one repo.

And with the monorepo you like make the change, you do all the fixes in one go and every micro front end is updated, right? So you've actually just gotten rid of that huge hurdle of working across these micro front ends by putting them in the same place. And I have a blog post about it. So you can check out like React micro front ends with monorepos perfect match.

Okay, yeah. So a question that I'm seeing here, I'm gonna rephrase it a little bit so that it's not calling anybody out, but if you've got a team where the pattern has been to create a new repo for each small thing, what is your recommendation for like helping teams work within the NX Monorepo framework when that's been the pattern before is to break everything into small code bases? Yeah, and I'm guessing that as you break code into small code bases, you're also publishing those to like a registry somewhere so that people can pull them down. I think the first thing that I would do is that I would move the publishable parts into NX and then have the different projects within the NX and you can see the relationships between them, but then you can publish those back up to, you know, artifactory, whatever, registry, and then you can start bringing it in from like higher and higher nodes of your dependency graph.

Mm-hmm. So, a question that I have is what's the difference between something like NX and other monorepo management tools like Lerna? Are they the same or are they solving different problems? Yeah, Lerna's really popular and it's really, really good for, I think, package management. So, like, NX has a lot of different packages that we manage and we don't use Lerna, but it would be nice to have something that just kind of runs everything, and that's what Lerna does. It allows you to have separate projects, but it allows you to run builds across all of them, test against all of them. But at the end of my talk I was going through, you know, running everything is going to take a really long time once you get in the scale of five, six different teams. So, when you're talking about organizations like Facebook, running all the tests takes a huge amount of time. So, NX has the intelligence, along with that, to be able to run only a portion of your projects when necessary to verify that the change is safe for production.

Got it. So, that kind of dovetails into another question here, which is how do you support big teams that are working on one repo if you have the need of something like a merge queue? I might not be as familiar with the term of a merge queue, but maybe it's like, you know, a lot of people working in the same monorepo, you might imagine a lot of merge conflicts, right? I think it's also like a misconception because merge conflicts only happen when two people work on the same thing. And it's not exactly like, you know, a thousand people working on the same piece of code, right? Everyone's working on their little slice of the monorepo. So, many times you won't get to merge conflicts, right, because you're working on something completely different from other people. The only thing is when you're working on a change that touches like, everything in the monorepo, say, like you like, change this really core thing, then yeah, there's gonna be merge conflicts when people merge their code in. But hey, you're gonna have to do it once rather than like, 50 different times across all those different teams. So, at the end of the day, that's still more efficient from a workflow standpoint, right, and yeah, the only other recommendation I have is that maybe you need this like, you know, I need this change in, let me just force push it in without, you know, getting all my approvals or like, there's a separate team that handles that kind of change. So, that's how I'd recommend going about it. Not sure if I understood the merge queue correctly. So, the question has been kind of rephrased to talk about like, a deployment queue. And so, I'm gonna talk about my own experience because I know for sure what I'm asking, just to make sure. And what I've seen is that in a lot of companies, when you get ready to do a deployment of a certain thing, so let's say that the apps front-end is about to do a deployment. There might be multiple branches going, but they will lock deployment for a window of time to make sure that the code gets merged and it goes live and everything is okay. The workflow that we use now wouldn't work in a monorepo because we'd be locking the entire company. Most of which that code is unaffected by the front-end deploying. So how is a workflow like that where I need to say, no one can merge to the UI for this window of time, how would that work? Yeah, so development workflow that works really well with monorepos is a trunk-based development. So that means everyone develops based off of master or develop branch, but all the commits go into there.

Releasing Apps from Monorepo

Short description:

You can release a separate app without releasing the whole monorepo at once. Cut a release branch from master, deploy it to a QA or staging environment, run tests, and deploy based on that branch. Meanwhile, master continues, and other teams can cut their own branches for deployment. Trunk-based development works hand in hand with monorepos.

When it comes time to do releases, and as I talked about, you can release a separate app by itself. You don't have to release the whole monorepo at once. So what you can do, is you can cut a release branch based off of master, right? And say release for April 17th. Don't release on a Friday, but let's just say that you've cut this release branch, you deploy this to a QA environment, a staging environment, whatever, right? You do those tests, and then you deploy based off of that branch, right? Meanwhile, master keeps going, but you don't have to worry, right? Everyone's still breaking it good, right? And stuff like that.

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 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
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 Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

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 Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
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 Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
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