Walking the Netflix Paved Road (Bumps Included): Web Framework, Hawkins Design System

Hi, all. So I'm Misha. I'm a UI engineer at Netflix. So at Netflix, my team builds tools for content analysis. So to put it simply, we help detect some scary and grownup stuff in the titles. So that shows like Squid Game or Stranger Things are recommended to you, but not to your little kids. And also these days, I spend a lot of time on developer productivity, in particular trying to help increase AI adoption, of course, across Netflix teams. But I'm not going to talk a lot about AI today. Well, a bit. Instead, I want to show you what it took for our product team to adopt UI platform tooling, which Netflix provides, or as we also call it, the paved road tooling. There will be two real life examples, so two real life challenges. And hopefully you can use the learnings that we got from the process at your own company.

So to set some context, let me tell you a bit about what Netflix UI platform is. So what's that and why do we need it? Let's imagine you'd like to watch something on Netflix. Let's say Squid Game. So please raise your hand if you have watched Squid Game. Nice. Yeah, because I have a lot of references to this show. So it's very good that almost all of you have watched it. So you go to netflix.com, you search for the show, there it is. But before a movie is ready to play, it actually goes through a long journey. First you need a screenplay, then you need to sign deals with actors, writers, directors, producers, et cetera. Then financials are handled, because you need to pay money for those stuff. Then finally the movie is filmed and produced. It's promoted, it's localized, it's age rated. By the way, that's my team, we help age-rate movies. And that's just the surface. So there are hundreds of internal apps that help to power all this process behind the scenes. Like hundreds of them. And you've also probably heard a bit about Netflix culture.

It's built kind of on top of speed. You need to iterate fast, you need to pivot, adapt fast. You need to run experiments, innovate. And also the processes or bureaucracy should not stop you. So there is a minimum of those. But also for the business to be successful, it needs to balance those things with quality, consistency, predictability, and multiplatform support. So that every device supports it, so that you don't find bugs. I know there are some, but hopefully there is a minimum amount of those.

And these two groups, they don't always match. So Netflix has come up with a solution to this mismatch, and this solution is platform tooling. So by saying platform, I mean the shared tools and libraries, like the common ones, that help you ship applications fast, without sacrificing quality. And on the web UI side, we call those tools UI-paved road. Like a road which you can drive or walk, so it's easier for you. But the spoiler alert is that there are some bumps on this road, and I will walk you through some of them.

So why would you actually migrate to platform at all? Because every codebase grows in complexity over time, right? But when you migrate to platform tooling, a big chunk of that complexity goes away, because you no longer need to support all those custom solutions that you would otherwise support, if they were not provided. So after adopting platform, the complexity, maintenance effort, and onboarding drop, and at the same time, those things that I mentioned before, like reliability, also productivity, consistency, and security, all they go up, because the platform team now handles it all for you. And just to reiterate, by saying platform, I don't mean stuff like Android, iOS, or web. I just mean this combination of tools, specifically on the web UI side, that are shipped for product teams to be faster and more productive.

So this is what we had before platform tooling, or before UI PR, as we call it. So every team picked tools that worked best for them. So as you can see here, the JavaScript bundlers that were used across the apps include React Scripts, Vite, Webpack, Gulp. Has anyone here heard of Cracko Cracko? Yeah, but we are using it. Yeah, I see one person. Cool. And it wasn't just about the bundlers. The same story, the same distribution of tools was also for styles, for forms, for tables, for localization, and for any other tooling that you can come up with.

So how did the platform team go from eight different bundlers to one paved road recommendation? This process had three phases for them. Stage, phase one, analyze. Look at the hundreds of applications, at what they're using, what they're sharing, where they disagree, what is app specific, what is monorepo specific, and what you actually need to ship as a common tool. Then second phase is select. When you know all of the tools that are used, you can go through them, you can analyze them, you can decide whatever is best for the entire Netflix applications ecosystem. And start supporting it as a platform. And third stage is that you need to bundle those tools together so that teams can just adopt them in one click, like one-click installation. Of course, it's never always one click, but that's the goal.

So these days, UiPaved Road, or UiPr, stands on two pillars. Web framework and Hawkins design system. So the framework is that first, yeah, it's very bright, the framework is that first pillar, and that's actually that bundler of all of the different tools that are provided to the teams. That's why we call it a framework. Let me show you what adoption of this web framework looked for our team. So this is a very simplified version of one of our applications that we support. So you need a movie search component, and you need this user menu, for example. From the architectural standpoint, it's just a monorepo app that depends on two reusable packages, movie search and user menu. Looks simple, right? But it's actually not that simple, because it's pre-UIPR. So it's before we adopted platform. Instead, this app and the packages depend on another package called application provider. Application provider is like a provider of all of those custom tools, also another custom package that we had in our monorepo. It handled the integration with internal systems like the authentication into Netflix system, and provided some common shared tools like configure GraphQL client, feature flags, telemetry, and many more. Application provider pulled all those things from other custom packages that live inside our monorepo.

Monorepo of 50 packages and 10 apps. All that we own, like our team owns. On top of that, there is also this community layer of some libraries for authorization, login, and more, maintained by the entire Netflix enterprise community. Each application also has its own configs and code generation logic, like typescript with config, test utils like test configs, and stuff. So this is the legacy setup that we inherited. If you look closer to this scheme, you can see that many of those things can actually be reused across multiple applications. Most applications need things like authorization, error handling, feature flags, telemetry, all of that on the left of the screen. Other configs can also share some defaults. So this must be provided by the platform, by the UIPR team. And it actually is. Our platform team worked hard, and now we have the equivalence of all those things provided by them. We no longer need to maintain all those custom alternatives in our monorepo, and you can see that the monorepo is much leaner now.

We still have that application provider. Its role is to pull over those things and provide them to apps and packages. The application provider is just an orchestrator of all those platform loops, so it should be supported by the platform as well. Every app does not need to have its own application provider. That's exactly how the framework was born. Now our apps just need to plug into the framework entry point, and the same for our packages. We get all those platform tools out of the box. No more custom infrastructure packages living in our monorepo. The application just needs to handle the business logic and nothing else. The framework gives you this enterprise-ready, pre-configured application setup out of the box, managed by the platform team. The platform team keeps your dependencies up to date and provides a plugin system in case you still need something custom.

The framework became the migration goal for our internal applications. We were one of the first teams to migrate, so we had to figure out the process first. Our first approach, BigBank Migration, aimed to replace the application provider, orchestrator, and all custom packages in our monorepo with a framework across all apps and packages at once. The goal was to simplify and standardize the tooling across the board. This approach streamlines the development process, reduces maintenance overhead, and ensures a more consistent and efficient workflow for all teams involved. The framework not only centralizes tools and configurations but also ensures that teams can focus solely on their business logic without dealing with custom infrastructure packages. This approach marks a significant shift towards a more efficient and scalable development environment within our organization.

Who has tried a BigBank Migration like that? And succeeded. Yes. So you probably now understand where it's all going. So once again, the scheme of our monorepo, the app and packages all depend on application provider. Then you just need to swap those dependencies to web framework, right? But then there is another app, and it also pulls the same stuff. And you can't have both application provider and web framework inside one monorepo, because under the hood they configure the same tools. So we have dependency conflicts. It's not that easy to resolve those. So you would need to migrate that second app as well. But then we have more of those, right? We have 50 packages and 10 applications. So you can't migrate one of those things without migrating all of them. It's like a snowball effect. And that's the actual dependency graph of our monorepo before we adopted Platform. Like, this thing in the center is application provider, and many of those blocks are those custom packages.

During this approach, the problems kept compounding. So the first problem is this tight coupling, because all apps and packages depend on the same things, and you can't migrate one without migrating them all. And you also can't verify that the migration works until you complete the entire process. So that's like hell. Then bugs are everywhere. It's impossible to reliably catch all regressions until you complete the entire process, and it never happens. Incompatible features, because our monorepo wasn't a bit of a legacy state, so some libraries were outdated, so we needed to upgrade them, and once again you need to do it for the entire repo first. Some missing features that the framework didn't cover at all, well, because it's a new product in our company, so we had to come up with the feedback on what needs to be added.

Cross-team coordination is, like I said, because all of the teams need to deliver the migration, and until they do, the process cannot be complete, and obviously each team also has its own roadmap. Frequent rebases to stay up to date with the development, and the cherry on top, a million line diff. Well, it wasn't like a million line, but still a lot. So this approach failed. Obviously it had some wins. Not the wins, but the pros. For example, you only need to do it just once for the entire monorepo, and it's done. Everyone benefits from what the platform provides.

It's also a focused effort that you can track and put on your roadmap, into your sprint, or however you manage projects. Also it exposed all of the problems that we have. But the bottom line here is that there is no room for error with this approach. One blocker stops the entire process, and teams also have to wait for each other, and regressions are also very hard to catch and verify, and after every change, you also need to go through that entire verification process from the beginning for all of the applications. So it's not sustainable.

So instead we went with this phased approach, the second approach. We split this one migration effort into three phases. Preparation phase, the migration itself, and the follow-ups, and we also pinned the dependencies per app, so that the framework and application provider and all of those custom things can co-exist together. This solved this dependency conflict's hell and unblocked us to migrate apps one by one, like app by app. So we start with one pioneer app to figure out the process and estimate the effort. Then we replicate it to the second app, then the next, and even if one application migration fails, it doesn't block the entire process.

So with this approach there is much more green. Obviously you get flexibility because you can control the timing on when to migrate each application. You get also white-gloves supported from the platform, because it's easier for them to help you with migrating one application instead of your entire monorepo. And also the pioneer application becomes the blueprint for every other app to follow. As for the trade-offs, some apps still lag behind because some teams start migration later, and the monorepo is also a bit messy temporarily, because since we pinned the dependencies, some apps pulled different versions of the same third-party libraries. So for example, NPM install took like 20 minutes until we completed this entire process.

But still, compared to the previous approach, that's much better. And here is this approach in practice. Probably you don't see everything that's written there, but that's exactly the point. Because now, instead of one massive effort for the migration, you have this list of small independent tasks. Like the same set of steps that each team can follow. And each phase can also be done separately, and those items can be parallelized and verified on their own. And once you've documented this process, like this high-level plan, the step-by-step guides, the pull requests, you can hand that runbook to your most hard-working teammate. This one. The one that never complains about rebasing.

So outcomes of this phased approach is that we went from 2 months for pioneer app migration to under 1 week for every subsequent app. The reason is how well the process was documented and how easy it was to follow. After that, after the pioneer migration, we turned the documentation and the artifacts like pull requests and stuff into an agent skill, so that AI can run migration end-to-end for you. And the documentation and the skill also turned out useful not just for our monorepo, but across the entire company. So what we learned from that is first, divide and conquer, right? Because Big Bang failed because it was so big and monstrous, so it's better to ship one small item at a time. Fail fast, but adapt faster. Big Bang failed, but it also exposed every blocker that we had and helped shape the phased approach migration. Collaborate with the platform. We gave early feedback on those missing features, some bugs got fixed, and the framework became much better than it was at the beginning. And finally, leave a runbook, like step-by-step guides, decision logs, pull requests, something that every other team can follow, like every human can follow, and not just humans, like we did.

Now the second pillar, the one I mentioned. Hawkins design system. Yeah, it's our Netflix in-house build, in-house system, like built on top of material UI. Basically, that's the building blocks of your application. So this is components, forms, tables, guidelines, usage metrics, all built with performance, stability, and consistency in mind by our platform team. So one of the case studies or challenges that we faced with this design system is this new table component adoption. So here is one of our tables in the application. It's implemented using Hawkins table component, which is built on top of a third-party library React data grid. Have you heard of that library? Okay. Now, have you heard of this one? Agigrid React? Yeah, I know, they are sponsors of this conference. By the way, they're not affiliated.

So our Hawkins team decided to use Agigrid to build the next version of the table component because it has more features and it's also faster, performance is better, so overall it's better. So they are calling that component Hawkins table next. And since the APIs are different for those third-party libraries, they want to deprecate the old one so that in the future we only use this Hawkins table next. But that's just an announcement because this component is still under development. So how do we go with it now? Because as a product team, we need to keep shipping new features, right? And they have tables. So do we use old table and ship new features now? Or do we wait for the new component and ship features later? So for old table, we have these pros and cons. No delay in product work, the APIs are familiar, and the main con here is that you're creating technical debt in advance because in future you would need to deprecate that component. For the new table you're not creating the technical debt, but there is a delay in product work and there is also a learning curve because you need to learn the new APIs before you start using it. So team old table, use your hands. Who would wait for the new table to be released? Okay, that's more of you. So we decided that neither option is great and found a new way.

So here's how we approached it. Step one, use HGGrid React APIs directly. Because since we know that it will be built on top of that third-party library, we can just start using it directly without waiting for Hawkins to release this component. Step two, once it's finally released, you just need to swap one component for each other. And since the APIs are similar, it will be easier than migrating to this component from scratch. And finally, step three, just do the cleanup and gradually migrate all the other tables until you have no references to the old table. So we called this approach forward adopt because I haven't found any other similar architectural pattern. And the wins here is that there is no delay in product work, you have less technical debt to address later, and you also get to give early feedback on the features. The trade-off is that it still has the learning curve. You also need some initial styling and licensing workarounds, since you're using the third-party library directly. And there is a small cleanup after the final swap. But compared to the alternatives, we found that a better approach.

So what we learned from it is, first, align direction and not timing. Because you can't always wait for the platform, because some product work can't wait. So instead, if you align the direction where you're moving, you'll meet at one point. Second, is that product work is non-negotiable. Your stakeholders should never know or never care about the migration that you're doing. And this is what keeps you trusted and accountable to make such decisions in the future.

And this is what keeps you trusted and accountable to make such decisions in the future. And finally, give early feedback. Like I said, our feedback helped to shape the final release. So next time you're waiting for the perfect tool to drop, start with what you already have. Align early and pave the road yourself. And by the way, we're hiring at Netflix. So if anything you saw was familiar or caused flashbacks, or if you want to work on similar challenges yourself, feel free to scan the code or find me on LinkedIn any time. Thank you. You're a great crowd.

How did you convey to leadership that this project was worth pursuing? It can be challenging to justify re-architecture and migration. Yeah, I agree that the buyout is probably the most challenging part. But I would say that it wasn't just our move to convince leadership, but it was also the decision that platform team had to pursue because initially it's their team who are responsible to introduce all of those shared common tools. And it's their role to convince the leadership, basically. Fantastic. Thank you.

How did you prevent the product teams from isolating themselves into their own little island? So I love that you mentioned at the end about making sure that they never know about the implementation details of packages and migrations, but how do you try to get them to contribute to the migrating or the building of the tool? Yes. So it's important here not to isolate your work. So since we are working in monorepo, it's actually easier because all of the contributors to the monorepo, they see the pull requests that you are creating, right? And it's also easier for them to start doing this stuff on your own after they have an example, right? And especially after we created the migration skill, it became even easier because now they just need to run the skill and verify that it works after the skill is done. Awesome. Thank you. I think we've got time for a couple more.

Thank you. I think we've got time for a couple more. When did you guys create and adopt the platform UI framework? Is this something that is fresh and has it matured already? If you are talking about the web framework, it's pretty fresh. I would say it's one year old, but Hawkins Design System existed for years. It just keeps evolving and upgrading and some new components appear there.

Okay. Do you have any regrets? Is the second part to that question. I only regret that AI didn't appear earlier in this process, but overall we learned a lot from it. Yeah. Can I ask you to come and sit in this chair for the final question? Sorry, guys. Sorry for people online. So another question is, is the framework mandated or do you still have teams that are able to use their own implementations? It's not mandated right now because it's still in the development stage. I would say it's still in the alpha stage. But once it has zero bugs, once the teams are happy with it, then it will start to be mandated, I think.

Fantastic. I did have one more question, but I think it's gone and time is up. So everybody, a massive thank you again to Misha for the incredible talk. Thank you so much. Thank you. Thank you.