This is the third post in my "My Open-Source Projects" series, where I go through some of the OSS projects I started or maintain and tell you the story behind them. First up was AngleSharp, then MAGES. This time: Piral, a framework for micro frontends - and the first project in this series that came out of a client engagement rather than a plane ride or a game studio's grant.
Piral lets you build a frontend application as a stable app shell that gets extended at runtime by independently developed, independently deployed modules called pilets. A pilet ships its own code and assets, can register pages, extend other pilets' extension points, and can be built, tested, and released completely on its own team's schedule - without anyone needing to touch or even redeploy the shell.
If that sounds like "micro frontends," that's because it is. Piral was one of the earlier dedicated frameworks in that space, built specifically around the idea that a single main framework (usually React) drives the shell, while individual pilets are free to bring something else entirely if they need to - Vue, Angular, even something short-lived and purpose-built. The shell doesn't care. It only cares about the contract.
I've written a more detailed technical introduction to the concepts before, if you want the deep dive: Introduction to Microfrontends with Piral. This post is more about where it came from and how it's grown.
Piral wasn't born as "let's make a framework." It was born as "let's actually ship this customer portal, for real this time."
I'd just come off a large rewrite of the smart-home portal for a large German energy company, where a micro-service-backed, loosely-coupled-frontend approach worked far better than anyone expected. The backend teams had already gone the micro-services route for their own reasons - scaling, ownership, independent release cycles - and it seemed almost wasteful to let all of that independence evaporate the moment it hit the frontend, where everything got welded back together into one shared codebase anyway. So we didn't. Multiple teams could ship independently without stepping on each other - which, if you've ever worked on a large frontend monolith with a dozen teams committing to the same App.tsx, is not a sentence you get to say often.
Then I became the main architect for a new digital customer portal at ZEISS - a large German company that had, by that point, tried and failed to pull off exactly this kind of portal for years. Not for lack of trying, and not for lack of good engineers - it's the kind of project that accumulates false starts simply because "let many teams contribute to one coherent customer-facing app" is a genuinely hard organizational and technical problem, and prior attempts had all run into the same wall: a single frontend codebase that every team had to touch, coordinate around, and eventually avoid touching at all costs.
I noticed the parallels to what had just worked at the RWE SmartHome project and leaned into the same approach: micro-service backends paired with what we'd now call micro frontends, even though nobody was calling it that yet - the term hadn't really entered common usage. It worked. Multiple teams contributing at what genuinely felt like the speed of thought, instead of the speed of "please rebase your branch against the shared frontend repo again, and also here's a merge conflict in a file six people touched this week."
At that point the obvious question was: why keep reinventing this per client? Why not generalize the approach into an actual framework?
I joined smapiot in February 2019, and the direction was clear from day one: alongside the regular consulting work, there'd be dedicated time to build a framework for micro frontends. By March 2019 we'd settled on a name: Piral, short for "Portals that can go viral." A year later, the "viral" part of that name aged in a way absolutely nobody could have planned for. We still bring it up.
We officially revealed Piral at the O'Reilly Software Architecture Conference Berlin in November 2019. In hindsight, that conference turned out to be the last one O'Reilly ran in that series - it never picked back up after COVID hit, at least as far as I know. So Piral's public debut happened at what turned out to be the end of an era for that particular conference. The response at the time, though, was genuinely great - people wanted to try it immediately, which is not always guaranteed when you show up with "yet another frontend framework" at a software architecture conference. We'd braced ourselves for the usual round of "how is this different from an iframe" questions, and got a refreshing number of "can we pilot this next quarter" ones instead.
Here's the whole arc at a glance, from that first month at smapiot to where things stand now:
Seven years is a long time for a framework built around one client project's success to still be actively developed, still picking up new adopters, and still running its own annual conference. None of that was guaranteed back in that Berlin conference room in 2019. A couple of things worth calling out about the timeline itself: the gaps are real - not every quarter had a headline-worthy event, and I'd rather show honest quiet stretches than pad the axis with filler. And two of the dates lined up in a way I didn't plan: Piral's v1.0 release and the very first Micro Frontends Conference both landed in June 2023, on the same day, which made for a genuinely good excuse for a celebration.
A few of those milestones are worth a beat of their own. The Feed Service has its own steady release cadence running quietly alongside the framework - 1.0.0 in October 2021, 1.17.0 four years later. Piral.Blazor turned into a small ecosystem of its own, from v3 in September 2022 to a dedicated server-side variant targeting .NET 8 in February 2024. And native Module Federation support landing in Piral 1.4.0 (December 2023) was a quiet but important one - it meant Piral could sit alongside, rather than only compete with, one of the other major approaches to shipping micro frontends.
Worth calling out explicitly: the "hundreds of pilets in one app" scaling story isn't something Piral grew into over these seven years - it was a design goal from the very first version, informed directly by watching what broke at scale in that original ZEISS-style setup. What's changed since 2019 isn't the ceiling; it's how many production systems are actually pushing against it.
The consulting projects that followed proved the concept held up outside of ZEISS's specific context, which is always the real test for something that started as "a good idea from one project." It's one thing to make an architecture work when you're the one who designed it and you're in the room for every decision. It's another to hand it to a different team, on a different project, with different constraints, and watch it hold up anyway. Piral did.
What surprised me more, though, was interest from teams that weren't using Piral at all. Larger projects already built on Single-SPA started reaching out for help getting Piral's loosely-coupled integration patterns into their existing workflows. They didn't want to migrate away from code that already worked - nobody sane wants a rewrite of a production system that's doing its job - but they wanted the ideas behind Piral (the decoupling model, the independent deployability, the way pilets could be updated and rolled out without a full redeploy) layered onto the micro frontend setup they already had. In practice, that meant bringing over specific mechanisms - things like our approach to shared dependencies, or the update/rollout model - without asking anyone to throw away months or years of Single-SPA work.
That's a good sign for any architecture: when people want to borrow your patterns even while keeping their own stack. It's a much stronger signal than stars or downloads, because it means the ideas are portable even when the code isn't.