Building Infinitely Scalable Applications with Alec Chernicki
===

[00:00:00] Hi there, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it for free at logrocket. com today. My name is Paul, and joined with us is Alec Czernicki. He's here to talk about infinitely scalable applications.

That's right. Infinitely scalable. Pretty cool. Alec is an architect supporting the teams that build Disney Plus and Hulu. Welcome to the show, Alec.

Thank you so much for having me.

So Disney Plus and Hulu, so you're not building Disney Plus and Hulu, but you are helping the team, you're helping architect the foundation of the team that build Disney Plus and Hulu.

Yeah, it was brought on to an architecture team about three years ago right after Disney plus had launched. So helping them scale up from what was essentially like a create react app all the way up to this whole ecosystem of apps and packages between Disney plus and [00:01:00] Hulu, which has been an awesome experience.

Yeah. For

maybe you're really good at React and context and data fetching and loading. Now you're, just an architect.

And I say just as it's something lightly, but I'd love to hear your, description about what you do, because it sounds like it's very encompassing of really helping teams excel and what an architect means in your role.

So I think a lot of my role has been a lot of building consensus between teams and having a holistic view of all the applications and parts of Disney Plus and Hulu and architecting solutions to those kind of overarching problems between teams. So you can imagine that Yeah.

We started as like a small lean team at first. And as we've scaled, we started to try and figure out how do we create more resilient solutions? How do we create solutions that scale not only to our user base, but also how do [00:02:00] we tackle the challenges that we face as we rapidly scale our engineering teams?

Um, That's , how I came to the conclusion of giving the talk at Next. js Conf this year.

Rapidly scaling teams. What does that look like to you? What is a rapidly scaling team where it's like, we got to plan this out or it's going to get messy because humans are messy.

Yeah. So I think we started with just a, like a handful of teams and I think we've gone up to maybe, oh man, I don't know, maybe a hundred plus engineers now working on maybe like one huge, large monorepo. And that's in the timeframe of maybe two years. So we've gone from maybe a a small, but scrappy team of 20 to 102 years.

That's the scale that I'm talking about.

You mentioned the elephant in the room here, the mono repo. It's every, everybody loves it and everybody hates it.

Oh, 100%. Yeah.

of the stick you come from. So why is the mono repo like the nexus of your architecting success here? Do you find the mono repo is a champion of your.

organization, your [00:03:00] career, and how did it arrive there?

Yeah, so I've before I worked at Disney, I worked on quite a few teams that had anywhere 15 engineers to same sizes as Disney pluses, which is like a hundred plus engineers working on a variety of like applications and packages. And there were two issues that kind of came up no matter what the team size, but it came up as that ecosystem grew.

And one was that applications always grew into kind of big monoliths. And just. As you started to add more features and really the only option was to split into two separate apps, but at that point Yes, you get some of the benefits of breaking down that task time But then you need to coordinate deployment cadences and if you need high consistency between those applications You need to time that correctly And the second was that code reuse became more important the bigger we got so you can imagine it's really easy when you're one small team and on a small application to have that understanding of what [00:04:00] code is already there that I can reuse.

But as communication silos kind of naturally happen and as teams start to work on their own thing, I started to see that multiple teams started to reinvent the wheel multiple times. And I think platform teams are a really common solution to this, to create standard like libraries that every team uses, but I've also seen it where product teams.

Build shareable features that are used across business context that they also want to share. And so. solving those problems was hard. So the reduction of task time from splitting up applications was great, but it added that overhead of managing those multiple deployments. And the second was that I know that developers will not do something if it adds friction to their workflows.

So the workflow of creating a separate repository for a package, building it, publishing it, versioning it, pulling that new package down, validating those changes locally, all of that. Just made the time to PR too long. And so developers just shied away from sharing their code which was [00:05:00] a requirement at that scale.

if I may ask a question here, like when you mentioned packages, because if anybody's used a monorepo packages like, come on, we use packages. But here we're talking about a different type of package, right? A different type of workflow. Could you just double click on the difference between like what some people might think of goes into monorepo package sharing and what we're talking about right here?

Yeah. So I think whenever you say like a package that people think, okay, that's how I kind of share code that's what I publish out and that's how people are going to consume it. I think monorepo tooling introduced this new paradigm of working with packages. And instead of solely using them as a way to share code.

They are now a way to create a stronger boundary between subsets of logic within an application. And I think I've started to see folks use it as a way to separate a concern for their design system or data fetching utilities or even things that they do want to share within their application.

So I think that paradigm shift from. Only using them to share code to, yes, you can use them to share code, but also use them as a way [00:06:00] to segment logic and create a stronger boundary. That kind of new workflow is what monorepo tooling has enabled.

Thank you for that. So it's like more of an internal bubble package that versus a I'm pushing this up to NPM or that, whether that be private or public, there's a lot of responsibilities that come along with that. 

Totally, yeah.

So when you start moving into the monorepo space, we're talking a lot about streamlining inter team communication, it sounds especially in your experience, like we're talking about silos, developer friction, sharing those packages.

Do you feel like the monorepo, and however you organize it, is a hail to specifically streamlining, teams? Or, does a singular team with six folks have a use case for these sort of paradigms as well?

Yeah, I think it really depends on . What you're working on. So I've seen teams that are like 5 to 10 engineers built huge applications with that lean team and use the [00:07:00] package paradigm that monorepos enable to kind of segment out their task time. So if they want to break out those long builds or those long test times, they can do that.

I think the secondary thing with able to share code and kind of streamline. Developer workflows and large engineering organizations comes as a bonus as your team starts to grow. So you can start off using monorepo tooling to cut down task time. And that will naturally lead to some of these workflow improvements hopefully as your application takes off and you become successful.

Hello everyone.

the monorepo thing, or we want to try setting up for a scalable. subset, maybe not scalable from the beginning.

What does that look like for a small team?

Yeah, I think the principles are the same for small teams to big teams. And that's that whenever you segment something out into [00:08:00] its own package, that package should have a pretty narrow scope. One of the pitfalls that I've seen is that. People create packages that are like utils and it becomes like a grab bag for everything that they want to throw into it.

What ends up happening is if you need that logic in a different place, you might end up with a circular dependency between your packages. So the same principle where if you're a small team and you start to see this domain boundary within your application and you want to split that out, that's awesome.

You're probably going to use that same principle of split. Breaking things out and splitting them out by domain all throughout your kind of scaling journey Whether you're like a small team that only wants to break out your design system Or maybe it's like a checkout experience or an onboarding experience that needs a high amount of tests as you will to a huge monorepo that has 30 packages and multiple applications

Some domains that I'm sure folks are familiar with are, you know, you have a DB package. you've been mentioning your design system package. You [00:09:00] want to bolster your design system. Maybe you have a set of components in a package just to like orient ourselves. And you know, what, what do the pros do?

What are some other sorts of domain boundaries that you've seen commonly? 

I've seen the deep database one a lot. I've seen a lot of, especially as you start to grow from that smaller team up into a larger team packages that are split by business verticals. Let's say you have like an. application where your onboarding experience really needs to be locked down and seamless for your users.

You might have maybe 60 to 70 percent of your tests covering only that flow, but the majority of your development is being done on your core product. I've seen folks see that as a really great Kind of delineation in the application break that onboarding logic out into its own package and that way you can distribute The tasks between the two.

So let's say you work on the core products like 80 percent of your commits are on the core product But 60 percent of your [00:10:00] tests are run against your onboarding package or your signup package If you're only making changes to that core product, then you can reduce your like total test time by 60% 80 percent of the time, because that's not what you're changing.

So I think when you start to see business verticals, or you start to see subsets of logic with completely different requirements, that's also a really great sign to, to break things up.

Now we are on a web development centric podcast. We talk a lot about react. We talk a lot about JavaScript in general, and everybody can make componentized designs and this feels alarmingly similar whether we'd be doing it correctly with Turbo repo or incorrectly or whatever your monorepo tool is of choice, and I'd love to get into how we relate.

React and our mental models of React into building a scalable application. Right before we do that, though, I just want to remind our listeners, since we are around halftime right now, that this podcast is brought to you by LogRocket. So if you're building an application, web platform, just a simple website, big or [00:11:00] small.

You could be using monorepo like we're talking about today, you can use log rocket to find errors faster, tools to surface issues that you might not have found yourself, and just spend more time building a good app and less time in our favorite place, the console. So head over to logrocket.

com today and check it out for free supercharger development. Back to monorepos. , so we're talking to react developers here. And I guess I'm curious, how can we use these componentized composition principles that we're used to flexing our muscles within React and relate them into the monorepo world to help paint a clearer picture about why this is useful and how you can go about it.

I'm not sure if you've particularly put time and thought into that, but I want to throw that question out at you.

Yeah, sure. I think one thing that React did for the front end community was put the skill of writing composable logic, it like a front and center for the And it's like a fundamental skill for thousands [00:12:00] of developers. I think some of the principles are that when you think of React components, you want React components to be reusable within any context.

You want them to be small and easily testable. You want them when you're looking and working with a component, you want to have A low mental overhead, you don't want to be jumping around components and trying to follow data flow. So on a macro level, when you zoom out, you essentially want packages to be the same thing as React components.

So like if I have Let's take like a, an off package that has a login modal. You want to make sure that login modal can be used on any page. Any context specific logic is passed in via like inversion of control rather than like imperatively written code within that package. And so the same things really apply where you want to optimize your packages for use within any context.

And you want to make it easy to just drop in, any bit of logic into any other place in your application. I think being able to [00:13:00] reuse at that level is really becomes like a superpower. When you start to grow.

So let's say I have a piece of logic because we're talking about componentizing or logic here and I put that piece of logic in some package in my packages. workspace. And I can't necessarily use that logic in all of my consuming applications.

Like maybe it's just works for my next app and it's not working for some other product somewhere else. Is that a red flag that it should not be in a package? Why or why not?

I don't necessarily think it's a big red flag. I think when you start to go from a small application to a medium sized application and using packages as that boundary to reduce things like task time, you're probably only going to be using those packages within one application. And so you're going to have some of that tight coupling.

I think the red flags start to appear on the API layer for whatever you're exporting from those packages. So if you're tightly coupling an external data [00:14:00] flow to what the. React components or utilities within your package expects and you create that type coupling That's when that becomes a red flag rather than hey, this is only being used in one application right now but it could be used in another application in the future

I think it's really interesting too, that you say it's a small project, it's a medium project. You're still in this potential realm of one consuming application, which You know, I can find a myriad of people on the internet that say, if you have one app, why are you using Turbo Repo? And I think this is a really cool like window into the other side of the world where it's look, there's a lot of success with doing things this way.

And even if you have one app, that doesn't mean you're too small. to start organizing it in this paradigm. And I guess that's encouraging to hear because it's cool, especially as a personal developer. Heck, I want to take my code and just throw it into this giant packages folder. I can just use it willy nilly in the future, however I want.

It's not baked into certain applications. So glad I'm not doing myself a dirty [00:15:00] there.

I think two, like working in having one entry point for your application is awesome that developer experience of like hot reloading and everything just coming out of the box is like the ideal that you want to continue with no matter what scale you're at. And I think working in a single application sometimes gets a bad rep because it.

People start shouting that it's a monolith, but really the biggest problems with the monolith are those separation of concerns and lack of separation of concerns. So like when you throw everything into one application, I'm not manually importing and saying like what folder am I importing from I'm just using auto import to have like Components be imported into whatever page I'm working on When you split things into a package you get a little bit more friction with that you do still get autocomplete for your imports, but there's a little bit more of a boundary and some friction.

So if you don't have functionality included and you might need to add it as a dependency or things like that. So I [00:16:00] think sometimes working in an application, like one application gets a bad rep, but I say stick with one application for as long as humanly possible, leverage the monorepo tooling to cut down task time if you need to, and only split it, like when it's really challenging you to stay in a single application.

If you were to do that you're starting a new company and you're putting out a monorepo, what are some of the immediate pushbacks that you would expect? Devs who maybe are in that camp of hey, we have one app don't use it or devs that do use turbo repo They're accustomed to it because like you mentioned anything that is a blocker to workflow and productivity people might have trouble adopting So if people want to go do this and push it at their company their organization What's maybe one or two piece of firepower you can give them to say this is definitely a productive way for us to move right now

Yeah, I think when you're introducing any new piece of tech into an engineering organization, you always need to start with the problem. So I wouldn't like [00:17:00] willy nilly say, Hey, we're going to now introduce monorepo tooling into this like application because it's like the new hotness, I think finding a point of friction that your developers really resonate with.

So whether it be really long task times or your code base is growing and you start to see more spaghetti code and it's getting more difficult to reason about where you should add or remove or change different code, like pieces of code within your application. That's a. Point of friction that developers can really relate to.

And when you introduce monorepo tooling as a solution to that friction, it's a lot easier to get buy in and saying here's something that we want to track and measure over time and see if monorepo tooling addresses this issue. If it does, let's keep. Let's keep pushing forward. But if not, then if you're just working in a monorepo tooling, packages are just really an extension of your application.

So you can copy paste that right back into your application without an issue. So I say, I would say, start with that problem and then work backwards from there.

on the flip side of the coin because we're talking about like [00:18:00] smaller teams now and You know Getting this new paradigm of work embedded into the everyday on the flip side of it What would you say is a red flag that your monorepos getting too big? Is that a thing? Are there monorepos that are too big or it does the benefit just Continue to scale up with your decreased task time and all this.

So I think When you ask developers that have worked at huge companies, the answer would be a resounding yes. And so some of the issues that they've run into that I've seen personally too, is that when you have 80 developers working on a single monorepo, you might start to see really long merge queue times and merge queues might not even be something that folks experience in smaller projects.

But , when you enter the merge queue, your PR might not land into main for an hour. Depending on the number of developers working on it. The other thing is like a really good example is that maybe you have Two teams working within a monorepo a marketing team and a team that works on your core product Maybe a new version of react comes out or like next comes out that supports [00:19:00] rsc And the marketing team's we want to go all in on this.

We see immense value in upgrading our version of reactor or next or whatever it is. But the core product team doesn't really see that value because they're just in a completely separate business vertical. They're like, I'm not going to adopt this, the value for. Us isn't there. We're not going to resource this.

I think when you start to see competing business objectives within the same monorepo, that's also a good sign to break it up. I think sometimes folks get frustrated within large monorepos because they feel a loss of autonomy because they're tied to other monorepo. So like one of the guiding principles is that you want to keep your dependency versions in sync, and you want.

Standards within like across your packages within the same monorepo to be about the same But there's really good reasons for teams to have different like opinions on that because they just might be solving different challenges So I think the answer is yes there is a point when it gets to be too big And I think that's when you start to [00:20:00] have competing business objectives within the same monorepo, and you want to break it up to continue giving engineers that work within it the ability to do their best work and kind of make those decisions on them on their own.

Now, one thing you mentioned like hailing to the, developers that felt pain before. with this paradigm and you mentioned, maybe two or three years ago, we had a significant shift in how big repo or monorepo tooling presents itself thinking back. I want to say four years ago or five years ago, we had to learn a. aNd now we have different tools out there. So what do you think not that learn is bad or anything like it's a great tool and plenty of people use it super successfully not only to speed up their times, but like you said to successfully segment and silo their logic, it does the same thing at its core.

But what do you think changed from five years ago to now? That is making this so much more palatable for people.

Yeah, I think LeRNA was really the first tool that brought some of the monorepo tools that had only previously only existed in huge fang companies [00:21:00] down to like individual smaller apps. And I think before Lerna, folks were so used to working in single applications and then deploying them and hadn't really been exposed to this like subset of monorepo tooling, or it just wasn't optimized specifically for the JavaScript community.

Lorna really pioneered the way for some of these other tools and like right after Lona came out, like tools like NX and PNPM and Turbo repo and like many package, all of these kind of ecosystems popped up afterwards to specifically support the JavaScript ecosystem. So I think, they did an amazing job.

And I think the future is really bright for all of this. And I think we're just at the very beginning. And I'm excited to see where all of the new tools that pop up over the next few years what that looks like just based on the past three years or four years and what's come out since then.

And that's a really good point. Lerno absolutely pioneered some of the stuff. It was, it's one of the first things I ever heard about, right? When looking at monorepos and there's something to like, if people are new to [00:22:00] something, of course, it's going to be hard. And there's going to be growing pains.

It doesn't matter how good the tool is. This is new stuff. So people need to adapt and,

Yeah. Yeah. Yeah.

and you mentioned quite a few tools, many package, pnpm, yarn workspaces. If people want to get into monorepos today and start playing with them, if you had to call out some tools, Alec, that you are a huge fan of, where should people start looking?

Yeah, I think there's two parts to this that I found. One is the tools and one is just like the concepts around monorepo development One thing that I've found really helpful for my team is there's a website I think called monorepo. tools that kind of explains the concepts behind why you might even want to start with monorepo architecture in the first place.

And that really helps kind of define the categories of tooling that exist out there. So there's task runners, there's versioning, utilities, some of the things that have been really helpful. for me have been things like change sets, which , has never given me an issue. It's amazing. Just for versioning packages within a monorepo[00:23:00] task runners.

There's so many options. Now there's like NX there's turbo repo, Google created a one called wire, it, which is really similar to turbo repo. And all of those tools are pushing us forward. Like within this new paradigm, I think the other category that we're starting to see is like this new category of tooling that's centered around conformance.

So when you have 50 packages, that's 50 different ways that your tool chain can fragment and 50 different like testing libraries that you might be able to use and different dependencies. And many package and sync pack, I think there's a new one called Sheriff that's, that has come out aims to address this drift between different packages within the monorepo.

And that's been really great too. I've been working on a tool called commonality. That's also trying to solve some of this stuff. If you want to take a peek, it's at commonality. co. But yeah, I think, like I said, like, all of these have almost recently come out in the past couple of years.

And I'm really excited to see, like, how all of these tools mature and all of the challenges that they're going to solve within the [00:24:00] next few years.

Alec, it's been a pleasure talking to you about, tooling and some of the lesser fun and shiny stuff that goes into building a scalable application, but All the more important, especially like yourself, you've been architecting at these huge companies like Disney plus and Hulu, there's something to be said about, you know how to write things at scale, you know how to do it right.

So it's great to have your perspective on the pod to go over the stuff. If people wanted to learn more about your musings and thoughts, do you have a blog? Do you have a YouTube or anywhere that you'd like to post? Transcribed

Yeah, I just I think I'm posting most of my thoughts on Twitter these days. So you can follow me at Alec Trinicky I just started a personal blog too, at alectrinicky. com. I posted a longer form version of my next JSConf talk and some of the principles behind it too. So if you want to read more about some of the concepts behind monorepo tooling and using it to scale large code bases you can definitely check that out as well.

Alec, once again, it's been a pleasure having you and hope to have [00:25:00] you on again in the future.

Awesome. Thank you so much.