In this episode of Micro-Frontends in the Trenches, Luca sits down with Noel Madali, Consumer Product Principal Architect at The Weather Company, to unpack a decade-long architectural evolution that took weather.com from an Angular and Drupal stack all the way to Next.js on Vercel.Noel has spent around ten years at The Weather Company, starting as a senior engineer and helping modernise the platform through several cloud migrations along the way, from Akamai and Drupal to Kubernetes on AWS, then IBM Cloud, and finally back to AWS with parts of the estate now running on Vercel. He walks through why the micro-frontend model resonated so naturally with their existing backend-for-frontend pattern, how they split weather.com by path across web, CMS, and API projects, and how labs.weather.com hosts over twenty experimental micro-frontends under a single group.The conversation gets into the real trade-offs of operating at this scale. Noel explains their "split brain" migration approach using Akamai in front of Vercel, the many flavours of caching they have wrestled with, and how they lean on React Server Components, ISR, and the newer cache components to serve millions of high-cardinality pages without triggering millions of revalidations. He and Luca also dig into the developer experience wins from Vercel's micro-frontend tooling, the chicken-and-egg gotchas of adding new projects into a git-flow process, how they layer Caddy on top of the built-in proxy for local development, and where remote micro-frontends fit into their roadmap with a shared footer as the likely first candidate.If you care about micro-frontends, Next.js at scale, caching strategy, or the messy reality of a multi-year platform migration, this one is packed with hard-won lessons from the trenches.This season of Micro-Frontends in the Trenches is brought to you by Vercel. To learn how Vercel can cut build times, boost developer velocity, and improve user experience with micro-frontends, visit vercel.com/microfrontends
00:00 Welcome and today's weather-themed episode02:32 Meet Noel and his 10 years at The Weather Company03:45 The migration path from Angular to Next.js05:05 Why micro-frontends fit their backend-for-frontend pattern06:18 Two flavours of micro-frontend: full pages and reusable components06:40 Splitting weather.com by path: web, CMS, and API projects07:36 labs.weather.com and 20+ experimental micro-frontends08:22 Web micro-frontends vs native mobile apps09:07 Backend-for-frontend per domain and monorepo decisions11:49 What drove the move away from Angular14:19 How AI tooling accelerated Next.js adoption15:02 The apex domain challenge and the "split brain" setup16:05 Sponsor: micro-frontends and team focus on Vercel17:13 The split brain pattern explained with Akamai19:49 Caching strategies and where the logic lives21:27 Cache components and React Server Components23:04 Serving millions of high-cardinality pages25:15 Core Web Vitals and measuring the migration27:12 What's next: cache components and stabilisation28:32 Multi-zone approach and team structure29:44 Monorepo and polyrepo micro-frontends30:27 The weather.com/retro Nuxt project32:19 Running multiple frameworks side by side33:20 Developer experience: Caddy, proxies, and fallbacks35:05 Gotchas: the chicken-and-egg of adding new micro-frontends37:19 Observability across independent micro-frontends39:29 The future: remote micro-frontends and a shared footer41:23 If you could start from scratch, what would change?43:37 The one thing Noel would do differently45:04 Wrap-up and closing thoughts

In this episode of Micro-Frontends in the Trenches, Luca Mezzalira sits down with Peter Eijgermans to unpack a five-year journey building Spoorviewer, the real-time dashboard powering operations at the Dutch Railways (NS / ProRail).

Peter walks through how four teams modernized a slowing Angular monolith into a dashboard-style shell hosting five remote applications, loaded dynamically at runtime via Module Federation. You'll hear what worked, what didn't, and why the first attempt with Web Components (Custom Elements) failed to deliver on performance.

CHAPTERS

00:00 Cold open: shipping without fear

01:26 Welcome and introductions

03:02 Meet Peter: full-stack, real-time data, and OIDC

05:16 Spoorviewer: a dashboard, not a page-based app

07:22 The five remote apps: Spoorzicht, Plan, Baanvak, Track Occupancy, Maintenance

10:34 Why micro-frontends? The organizational and technical breaking point

12:47 The performance trap of Custom Elements

14:54 Switching to Module Federation: Lighthouse 30 → 75

16:50 Domain-Driven Design and identifying overlapping boundaries

20:11 Recap: shell, lazy loading, DDD, and team independence

23:30 WebSockets aligned to bounded contexts

26:46 How developers felt about the move to micro-frontends

28:11 Guardrails: framework alignment, versioning, shared libraries

31:14 From client-side OIDC to a Backend-for-Frontend "Lego brick"

34:27 Drawbacks and lessons learned along the way

36:41 Architecture surfaces friction, it doesn't create it

39:17 AI on the horizon: predicting train delays

40:39 AI in the developer workflow

42:31 Closing reflections: start with good design

43:21 Wrap-up and outro

Modern Angular ebook by Manfred Steyer: https://payhip.com/AngularArchitectssubscribe to the MFEs newsletter: https://www.buildingmicrofrontends.comIn this episode, host Luca sits down with Manfred Steyer — Angular GDE, trainer, consultant, and creator of Native Federation — to explore the world of micro frontends in the Angular ecosystem.They cover:How popular micro frontends are in the Angular community and when they actually make senseThe different approaches to implementing micro frontends in Angular (hyperlinks, hydration, Module Federation)State management and communication between micro frontends using signals and subjectsHandling multiple Angular versions across a distributed systemHow and why Manfred created Native Federation as a build-tool-agnostic alternative to Webpack Module FederationHow import maps and ES modules power Native Federation under the hoodMigrating from a monolith to micro frontends — key questions to ask before you startThe relationship between the Angular team and Native FederationTop 3 recommendations for developers getting started with micro frontends

“We adopted micro-frontends… and suddenly authentication became everyone’s problem.”

That sentence alone has probably cost teams months of rework, endless Slack threads, and architecture diagrams that aged badly after the first production incident.

In the latest episode of Micro-Frontends in the Trenches, I sit down with Chris Fryer to unpack the realities behind his #microfrontends Framework, the evolving Module Federation ecosystem, and much more

☢️ WARNING: This is not a theoretical conversation.

Listen to the episode and let me know what challenged your perspective the most.

In this episode, I’m joined by Boris Besemer from Vercel to unpack what it really takes to start a migration to micro-frontends without turning it into a never-ending transformation.

We focus on the very first steps teams should take: how to identify the right starting point and how to avoid the most common early mistakes that slow teams down or create unnecessary complexity.

A big part of the conversation explores how the Vercel platform can simplify platform engineering during a migration.

We discuss how tooling, deployment workflows, preview environments, and developer experience can reduce cognitive load while multiple teams progressively move toward a micro-frontend architecture.

I don't think you need to know more than the name of the guest to love this episode: Sam Newman, author of Building Microservices and other best sellers on distributed systems.

This is an episode you don't want to miss where I talk about micro-frontends with Sam drawing parallelisms between the 2 layers of a distributed system.

Enjoy this fantastic episode

===================================

My gear: https://www.amazon.co.uk/shop/my50cents?ref_=cm_sw_r_cp_ud_aipsfshop_W744H9NEJG7C9T3JMFC2Spotify: https://open.spotify.com/show/0W5YEY5T3ApuYS8H9I3DzL?si=c279c2df086b4d8fTwitter: https://twitter.com/lucamezzaliraLinkedIn: https://www.linkedin.com/in/lucamezzaliraInstagram: https://instagram.com/mezzalabTikTok: https://www.tiktok.com/@lucamezzalira

In this episode of Micro-Frontends in the Trenches, I talk with Jeremy Colin (ex-Zalando) about the journey that led to Tailor.js and later Mosaic, two pioneering frameworks that shaped how micro-frontends are built at scale.Jeremy shares the technical challenges, trade-offs, and lessons learned while building these platforms, and why platform engineering is essential for making micro-frontends practical in real-world organizations.We dive into:- The story behind Tailor.js and its role in Zalando’s architecture.- How Mosaic evolved and why it mattered.- The hidden complexities of adopting micro-frontends.- Why platform engineering is key to simplifying and sustaining the practice.I highly encourage all of you to listen to this episode that is part of the micro-frontend history!

We’ve been cooking something new—Remote Components.Imagine pushing a tiny change to your e-commerce site like updating a free shipping banner and having to wait hours for the entire site to build and test. That’s the reality of traditional monolithic frontends, where even the smallest updates can ripple across the codebase, slowing teams down and widening the blast radius for potential problems.Vercel is changing the game with micro-frontends providing an unmatched developer experience so farIn this episode you’ll learn how Vercel micro-frontends implementation can:- Speed up build and deploy times- Reduce risks when releasing features- Empower teams to ship independently without stepping on each other’s toes

More information at: https://vercel.com/microfrontends