Routing at Scale with TanStack Router's Nicolas Beaussart | React Router Migration, Monorepos, PayFit

Routing at Scale with TanStack Router's Nicolas Beaussart | React Router Migration, Monorepos, PayFit

What do you do when React Router v5 is blocking your React 18 upgrade, your frontend spans 25 repos, and you have 5 different micro frontend strategies running in the same app? In this episode of Señors at Scale, Dan Neciu sits down with Nicolas Beaussart-Hatchuel, Staff Engineer at PayFit and maintainer of TanStack Router. Nicolas shares the full story of migrating a 1.5 million-line codebase from React Router v5 to TanStack Router using the strangler pattern, without big-bang migrations and without stopping 18 engineers from shipping 15-20 PRs a day. We also dive into the origin story of TanStack Router, why PayFit killed micro frontends entirely and moved back to a single monorepo, how building the whole app at once saved 25MB of JavaScript, and why his MCP experiments performed worse than simply letting AI agents read the code. Plus: what it really takes to go from senior to staff engineer. Key Topics: - How Nicolas got into coding and his first iframe-based micro frontend migration - The origin story of TanStack Router and URL-as-state - Migrating 1.5M lines from React Router v5 to TanStack Router - The strangler pattern applied to frontend migrations - Faking React Router providers to sync two routers on one URL - Consolidating 25 repos into one monorepo - Secret dependencies, Yarn v1 pain, and standardizing on Vite - Why dropping per-library builds saved 25MB of JavaScript - TypeScript Go in editors and its RAM cost - MCP servers vs agents reading code directly - Internal DevRel: winning engineers over with social proof - Going from senior to staff: system design and finding problems worth solving - What's next: TanStack Start v1 and parallel routes Connect with Nicolas: 💼 LinkedIn: https://www.linkedin.com/in/beaussan/ 🐦 X: https://x.com/beaussan 🐙 GitHub: https://github.com/beaussan 🌐 Website: https://beaussan.io FOLLOW & SUBSCRIBE: 🎙️ Podcast: https://neciudan.dev/senors-at-scale 📬 Newsletter: https://neciudan.dev/subscribe 💼 Dan's LinkedIn: https://www.linkedin.com/in/neciudan 💼 Show LinkedIn: https://www.linkedin.com/company/senors-scale/ 📸 Instagram: https://www.instagram.com/senorsatscale/ 📸 Dan's Instagram: https://www.instagram.com/neciudev ADDITIONAL RESOURCES: - TanStack Router: https://tanstack.com/router - Engineering Management for the Rest of Us by Sarah Drasner - Scaling Fast by Swizec Teller - Swizec's newsletter: https://swizec.com #TanStackRouter #React #Monorepo #MicroFrontends #FrontendArchitecture #TypeScript #StaffEngineer #SenorsAtScale 💬 Have you ever had to migrate a router in a live codebase? What pattern did you use? Drop it in the comments.

Redux at Scale with Mark Erikson | State Management, RTK Query, Time Travel Debugging

What happens when the person maintaining one of the most widely used libraries on the internet tells you AI is coming for debugging, too? Mark Erikson is the maintainer of Redux, creator of Redux Toolkit, and a senior front-end engineer at Replay.io, where he works on a time-traveling debugger. He's been shipping software since 2008, from emulating legacy CPUs in old aircraft at Northrop Grumman to modernizing a Redux codebase used by millions of developers. And remarkably, Redux has always been a free-time project for him. In this episode, Dan sits down with Mark to trace the full arc of Redux: how it started as a 2015 conference demo on time travel, how it conquered (and then over-saturated) the React ecosystem, and how Redux Toolkit and RTK Query reshaped the way people actually use it today. We also get into one of the most fascinating technical stories in the episode, how Mark got source maps into React's build pipeline and what happened next. Then we look forward. Mark walks through how Replay records the entire browser, how Replay MCP gives AI agents the same time travel debugging tools a human would have, and a real example where an agent went from fumbling for 15 minutes to finding a root cause in under two. Key Topics: - The origin of Redux and how it killed off the other Flux libraries - What Redux Toolkit solves and the persistent "boilerplate" myth - RTK Query vs React Query design tradeoffs - The listener middleware and a two-year API design journey - Getting source maps into React's build pipeline - How Replay records and replays the entire browser - Replay MCP and AI agents that auto-investigate failing tests GUEST LINKS 💼 https://www.linkedin.com/in/markerikson 🐦 https://twitter.com/acemarke 🐙 https://github.com/markerikson 🌐 https://blog.isquaredsoftware.com 🦋 https://bsky.app/profile/acemarke.dev FOLLOW & SUBSCRIBE Instagram: https://www.instagram.com/senorsatscale/ Dan's Instagram: https://www.instagram.com/neciudev Podcast: https://neciudan.dev/senors-at-scale Newsletter: https://neciudan.dev/subscribe Dan's LinkedIn: https://www.linkedin.com/in/neciudan Show LinkedIn: https://www.linkedin.com/company/senors-scale/ ADDITIONAL RESOURCES Redux: https://redux.js.org Redux Toolkit: https://redux-toolkit.js.org Replay: https://replay.io Mark's blog post on the listener middleware and source maps work: https://blog.isquaredsoftware.com #Redux #ReactJS #JavaScript #StateManagement #WebDevelopment #FrontEnd #SoftwareEngineering #OpenSource #Debugging #ReduxToolkit 💬 What's the one thing you used to think AI would never be able to do for you as an engineer?

TanStack Query at Scale with Dominik Dorfmeister (TkDodo) | Open Source, Knip, Sentry Design System

What does it actually feel like to maintain a library used by millions of developers every day? In this episode of Seniors at Scale, Dan sits down with Dominik Dorfmeister, better known as TkDodo, the creator and maintainer of TanStack Query and a software engineer at Sentry. Dominik has spent over a decade building frontend tooling and has become one of the most trusted voices in the React and TypeScript ecosystem. Dominik shares how he got into open source during the pandemic lockdowns, simply by answering questions in Discord, and how that habit grew into maintaining one of React's most widely adopted libraries. He talks candidly about the breaking change that went wrong, why major versions are "the pain of his existence," and what he has learned about shipping changes to a community that only shows up with feedback after release. The conversation also digs into his work at Sentry, where he used Knip to remove 28,000 lines of dead code, and his team's work building a new design system within a 10-year-old, million-line codebase. Key Topics: - Getting into open source by answering community questions - Becoming the maintainer of TanStack Query - Tracked queries and the first big performance feature - Why major version releases are so painful - The version 4 to 5 breaking change that went wrong - Epoch versioning as an alternative to semver - Using Knip to find and remove dead code - Building a design system in a large, legacy codebase - What is planned for TanStack Query version 6 Guest: Dominik Dorfmeister (TkDodo) 🌐 Blog: https://tkdodo.eu/blog 🦋 BluSky: https://bsky.app/profile/tkdodo.eu 🐙 GitHub: https://github.com/TkDodo FOLLOW & SUBSCRIBE 💼 LinkedIn: https://www.linkedin.com/company/senors-scale/ 🌐 Podcast: https://neciudan.dev/senors-at-scale 📨 Newsletter: https://neciudan.dev/subscribe 📸 Instagram: https://www.instagram.com/senorsatscale/ Connect with Dan: 💼 LinkedIn: https://www.linkedin.com/in/neciudan 📸 Instagram: https://www.instagram.com/neciudev ADDITIONAL RESOURCES TanStack Query: https://tanstack.com/query Knip: https://knip.dev Sentry: https://sentry.io TkDodo's blog: https://tkdodo.eu/blog #ReactJS #TanStackQuery #OpenSource #FrontendDevelopment #SoftwareEngineering #WebDevelopment #TypeScript #Sentry 💬 What is your take: should libraries do fewer, bigger major versions, or more frequent, smaller ones? Let us know in the comments.

Performance Engineering at Canva with Den Odell (Staff Engineer & Manning Author)

What happens to "edge cases" when your product serves 250 million people every month? In this episode of Señors at Scale, I'm joined by Den Odell, Staff Software Engineer at Canva and author of "Performance Engineering in Practice" (Manning, 2026). Den works on Canva's Pro Design group, building inside one of the largest React/TypeScript codebases on the planet, serving 250M+ monthly users across 190+ countries. Before Canva, Den spent 9 years at Volvo Cars architecting their Offer Selector and Car Configurator (powering vehicle purchases across 70+ markets), and 13 years at AKQA leading global frontend engineering for Nike, MINI, and Nokia. He's authored three books, the latest of which introduces the Fast by Default framework, a methodology for treating performance as a design decision from day one rather than a panic fix at the end. We get into how Canva ships safely at a planetary scale (feature flags, dogfooding, geofenced rollouts, test parties), the protobuf-based RPC layer powering their frontend/backend communication, async-first culture across global timezones, and why most teams are stuck in what Den calls the Performance Decay Cycle. Key Topics: * Why bugs scale with your user base (and what to do about it) * Canva's release pipeline: staff → beta → geofenced regions → world * Test parties, dogfooding, and catching weirdness before users do * Protogen, CDF, and how Canva moves data between frontend and backend * Operational transforms for real-time collaboration * The Performance Decay Cycle and why "performance sprints" are broken * Fast by Default: making speed everyone's responsibility, not just engineering * Perceived performance, AI loading states, and the Pac-Man tape loader lesson * Async work culture when "the sun never sets on the Canva Empire" * Building for crazy big goals (what does Canva look like at 1 billion users?) GUEST SOCIALS💼 LinkedIn: https://www.linkedin.com/in/denodell🐦 X/Twitter: https://x.com/denodell🐙 GitHub: https://github.com/denodell🌐 Website: https://denodell.com FOLLOW & SUBSCRIBE🌐 Podcast: https://neciudan.dev/senors-at-scale📧 Newsletter: https://neciudan.dev/subscribe💼 Show LinkedIn: https://www.linkedin.com/company/senors-scale/📸 Instagram: https://www.instagram.com/senorsatscale/💼 Dan's LinkedIn: https://www.linkedin.com/in/neciudan📸 Dan's Instagram: https://www.instagram.com/neciudev ADDITIONAL RESOURCES📘 Performance Engineering in Practice (Manning, 2026): https://www.manning.com/books/performance-engineering-in-practice🔧 Code listings on GitHub: https://github.com/denodell/performance-engineering-in-practice✍️ Den's blog: https://denodell.com/blog📕 The Product-Minded Engineer (Drew Hoskins, O'Reilly): mentioned in episode #Frontend #Canva #FeatureFlags #Dogfooding #PerformanceEngineering #SoftwareEngineering #WebDevelopment #StaffEngineer #ReactJS #TypeScript #Podcast #SenorsAtScale 💬 What's the worst "edge case turned major incident" you've shipped to production? Drop it in the comments.

Frontend at Meta with Evyatar Alush | Hack, Flow, Sapling, Open Source at Scale

What does engineering at Meta actually look like from the inside? Spoiler: almost nothing you know from outside applies. In this episode, Dan sits down with Evyatar Alush, Software Engineer at Meta in Tel Aviv and the creator of EmojiPicker React (600K+ weekly downloads) and Vest. Evyatar's journey is one of the most unusual on the show: no degree, no high school diploma, learned JavaScript on Code Academy during military night shifts in a server room, then talked his way into Fiverr, scaled to Front End Platform Lead, and got recruited into Facebook in 2019. We get into what it's actually like inside Meta's frontend infrastructure: Hack instead of PHP, Flow instead of TypeScript, Relay instead of Apollo, Sapling instead of Git, stacked diffs instead of pull requests, and a custom everything (testing frameworks, ORMs, dev servers, data centers). We also cover his open source philosophy, why he builds his own libraries instead of pulling dependencies, the supply chain risks of modern npm, and how AI-assisted code is reshaping open source maintainer work. Key Topics: - Learning to code on military night shifts with zero CS background - Joining Fiverr with one year of experience and bluffing through the interview - Building Fiverr's notification system, in-app inbox, and toast library - Creating EmojiPicker React from a Fiverr internal tool - The "Unmask" manifesto and starting Fiverr's frontend infrastructure team - Designing the Front Ants team by faking the trappings of a real team - Building micro-frontends that bridge a Ruby on Rails monolith and React - Saying no to Facebook on the first email - Interviewing at Meta in London (and the Dan Abramov interview) - The Calibra/Diem crypto wallet team during COVID - Hack vs PHP, Flow vs TypeScript, Relay vs Apollo, Sapling vs Git - Stacked diffs and why ex-Meta engineers miss them - Why "move fast and break things" is dead at Meta - Code review, dev mod servers, and end-to-end testing at scale - Open source maintenance in the AI era and Cursor-generated PRs - Why he owns the "context" package on npm GUEST: Evyatar Alush 💼 LinkedIn: https://www.linkedin.com/in/evyataralush-5b760866 🐙 GitHub: https://github.com/ealush 🌐 EmojiPicker React: https://github.com/ealush/emoji-picker-react 🌐 Vest: https://vestjs.dev FOLLOW & SUBSCRIBE 📸 Instagram: https://www.instagram.com/senorsatscale/ 📸 Instagram: https://www.instagram.com/neciudev 🎙 Podcast: https://neciudan.dev/senors-at-scale 📬 Newsletter: https://neciudan.dev/subscribe 💼 LinkedIn: https://www.linkedin.com/in/neciudan 💼 LinkedIn: https://www.linkedin.com/company/senors-scale/ ADDITIONAL RESOURCES - EmojiPicker React: https://www.npmjs.com/package/emoji-picker-react - Vest (form validation): https://vestjs.dev - Sapling (Meta's source control): https://sapling-scm.com - The Hack language: https://hacklang.org - Flow: https://flow.org - Relay: https://relay.dev - The Design of Everyday Things by Don Norman - Never Split the Difference by Chris Voss #Meta #Facebook #Frontend #ReactJS #HackLang #Flow #Relay #Sapling #StackedDiffs #OpenSource #EmojiPickerReact #Vest #SoftwareEngineering #SenorsAtScale 💬 What's your take on Meta's "everything in-house" engineering culture? Would you rather work with familiar tools or relearn engineering from scratch for better internal infrastructure?