MicroFrontends at Scale with Florian Rappl

🎧 New Señors @ Scale Episode

This week, I spoke with Florian Rappl, author of "The Art of Micro Frontends", creator of the Piral framework, and Microsoft MVP.

Florian has spent more than a decade building distributed web systems that actually scale in the real world. Before becoming a solutions architect, he built everything from enterprise portals for Germany's largest companies to smart home platforms — and along the way became one of the most active voices in the micro frontend community.

In this episode, we dive deep into the philosophy behind Piral, why loose coupling is more important than multi-framework support, how micro frontends might be the key to unlocking AI-powered development workflows, and the "inverse dependency" pattern that makes micro frontends truly resilient.

⚙️ Main Takeaways

1. Piral was born from building the same architecture three times

After implementing similar distributed frontend architectures in multiple projects, Florian decided to open source the lessons learned.

• The origin: After a smart home project, a customer portal for a major German optics company, and other distributed systems, Florian saw patterns emerging.
• The challenge: Making the solution generic enough to be a framework while still allowing customization.
• The timing: Piral development started in early 2019, with the first release towards the end of 2019 — before Module Federation existed.

2. Piral is to Module Federation what Kubernetes is to Docker

Module Federation is a tool for packaging and loading code, but it doesn't solve architecture — that's where Piral comes in.

• The analogy: Module Federation is like Docker — it solves packaging and delivery. Piral is like Kubernetes — it's the orchestrator.
• What Module Federation lacks: Cross-framework components, architectural boundaries, loose coupling, connection to discovery services.
• The relationship: Piral can use Module Federation under the hood for distributed sharing, but provides the full orchestration layer.

3. The inverse dependency pattern changes everything

Instead of micro frontends depending on each other, they offer functionality — and this reversal makes the architecture resilient.

• The old way: "I have a micro frontend and I depend on a component from another micro frontend, so I need to grab this thing."
• The problem: What if the other micro frontend doesn't exist? What if they renamed something? It can break at any time.
• The new way: "I offer something." Register a page (offer to the router), register an extension component (offer a named component that others can use).
• The result: Micro frontends become truly independent and loosely coupled.

4. Extension slots enable composition without coordination

The extension slot pattern allows micro frontends to contribute components without knowing about each other.

• The concept: Define a slot (like "customer-actions" in a table row) and any micro frontend can register components for that slot.
• The power: Fine-grained permissions become automatic — if a user doesn't have edit rights, simply don't ship that micro frontend. No if-conditions needed.
• The consistency: Everything in a micro frontend is either all there or all not there, ensuring consistent UI.
• The uniqueness: Other frameworks don't have this notion of extension slots, which is why people "think too complicated" when coming to Piral.

5. Micro frontends with Piral are faster than you'd expect

Loading 50-60 micro frontends can happen so fast that users don't even notice something different is happening.

• The entry files: Each micro frontend has a tiny entry JavaScript file (500 bytes to a few KB) that contains the setup function.
• The lazy loading: Everything else (components, pages) is lazy loaded on demand.
• The caching advantage: Unlike monolithic apps where one change busts all hashes, micro frontend caching is granular — only changed micro frontends need to be re-downloaded.
• The cache strategy: The discovery service sets indefinite caching because the same version URL always returns the same content.

6. Distributed sharing solves the "dependency hell" problem

Sharing dependencies in micro frontends is notoriously difficult, but Piral supports multiple approaches.

• Central sharing: The old approach — rely on dependencies the app shell provides. Works but creates bottlenecks when updating.
• Distributed sharing: Each micro frontend brings its dependencies but checks if a compatible version already exists before loading.
• The mechanism: "I bring React with me. I will first check if React is already there. If it's compatible, I'll use it. If not, I'll load mine."
• The future: Module Federation is becoming the primary system as more bundlers support it, with System.js remaining as a secondary option.

7. Start in a monorepo, split when needed

Piral was designed for polyrepos (the hard case), but starting in a monorepo is often simpler.

• The philosophy: Design for polyrepo, which automatically works for monorepo — the reverse isn't true.
• The progression: Start with all micro frontends in one place, then move them out when you see the need (a team owns it, it changes more frequently, etc.).
• The flexibility: Piral lets you combine sources from online, local builds, and unpublished outputs all at once.

8. Don't create header and footer micro frontends

Thinking in horizontal slices (header, sidebar, footer) is a common anti-pattern.

• The problem: If the header team owns the menu, every other team will constantly ask them to add links. Not scalable.
• The solution: Put the header in your design system/app shell and add extension slots where other teams can register their menu items.
• The principle: Cut by functional domains and teams, not by visual areas of the screen.
• The composition: Piral's extension slots let you compose contributions from multiple domains into a single visual area.

9. Enable micro frontends first, then extract progressively

Don't start by cutting your application into 200 micro frontends.

• Step 1: Give your application the ability to use micro frontends (install Piral) — you don't even need a micro frontend yet.
• Step 2: Create your first micro frontend for a new feature.
• Step 3: Extract an existing feature into a micro frontend.
• The evolution: Scale up progressively based on team needs, not a big-bang rewrite.
• The escape hatch: You can stop at any time if it's not working for your organization.

10. Nano services: Full-stack micro frontends are coming

Piral is expanding to include backend composition alongside frontend composition.

• The concept: Deploy a frontend micro frontend and its backend "nano service" together as a unit.
• The benefit: They never break because they're not fitting together — they're always deployed in sync.
• The architecture: The backend part runs in your gateway, the frontend part in the app shell, but they're developed and deployed together.
• The future: This brings microservice lessons to micro frontends and could be "a game changer" for reliability.

🧠 What I Learned

• Module Federation is a tool; Piral is the orchestrator — they solve different problems at different levels.
• The inverse dependency pattern ("I offer" vs "I depend") makes micro frontends truly loosely coupled.
• Extension slots are Piral's killer feature — they enable composition without coordination between teams.
• Loading 50-60 micro frontends can be imperceptible because entry files are tiny and everything else is lazy loaded.
• Distributed dependency sharing is superior to central sharing because it removes update bottlenecks.
• Start in a monorepo and extract to polyrepo when you see natural boundaries forming.
• Never create horizontal slice micro frontends (header, footer) — cut by functional domains instead.
• Enable micro frontends first with zero micro frontends, then grow progressively.
• Cache busting is granular with micro frontends — only changed modules need re-downloading.
• Nano services (backend + frontend as a unit) are coming to Piral for guaranteed deployment consistency.
• AI-assisted development works better with smaller, modular codebases.

💬 Favorite Quotes

"You no longer think in the way that I have a micro frontend and I depend on a component of another micro frontend. Because this approach is really fragile. What you would rather want is to reverse that flow. Instead of saying 'I want something,' you say 'I offer something.'"

"Piral is a little bit like Kubernetes. You can run it with Module Federation, but it is the orchestrator."

"The beauty of this architecture is that if a user doesn't have the right to edit a customer, you don't ship this micro frontend. The button isn't shown, the dialog is also not loaded, nothing is shown there."

"We show people solutions built on Piral that have 50 to 60 micro frontends loaded. The thing is just there and they're like, 'okay, what's the catch?' It's so fast that they don't even realize what just happened."

"Only the thing where you changed it, that will actually change. You can cache micro frontends indefinitely because the same version URL always returns the same content."

"Thinking in smaller boxes is essentially what makes the AI tools already work today."

🎯 Also in this Episode

• How smart home systems influenced Piral's modular architecture
• Why Single SPA wasn't checking the boxes in 2019
• The setup function and teardown lifecycle in Piral micro frontends
• How the API object enables plugin-like registrations
• Why runtime integration is essential for dynamic user permissions
• The trade-offs of runtime micro frontend loading
• How Piral's discovery service works with the orchestrator
• System.js vs Module Federation for dependency sharing
• The React hooks singleton problem and why sharing React is mandatory
• How Piral CLI handles different bundlers (Webpack, RSPack, Vite, ESBuild)
• Emulator packages for polyrepo development
• Change detection and hot module reloading in development
• The Piral Cloud feed service and its commercial features
• Rule engines for A/B testing and feature flags
• CSS collision detection between micro frontends
• Why Piral's feature flags might replace LaunchDarkly
• Server-side rendering and island architecture with micro frontends
• What's coming in Piral v2 and v3

Resources

More from Florian:

• Piral Framework
• Piral GitHub
• The Art of Micro Frontends (2nd Edition) by Florian Rappl
• Piral Cloud — Discovery service and feed management

Book Recommendations:

• Physics of the Future by Michio Kaku — Popular science extrapolating technology through the 21st century
• Building Micro-Frontends (2nd Edition) by Luca Mezzalira
• Release It! by Michael T. Nygard — Essential reading on building resilient systems
• Continuous Delivery by Jez Humble & David Farley

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 69 minutes on micro frontend architecture, the inverse dependency pattern, extension slots, and building truly modular web applications that scale across teams.

Whether you're an architect evaluating micro frontends for your organization or a developer curious about modular patterns that actually work in production, this conversation offers battle-tested insights you won't find in the documentation.

Happy building,
Dan