Welcoming Nimbus: Event-Driven Development for TypeScript

Today we're thrilled to celebrate the launch of Nimbus, a new event-driven application framework for TypeScript built by our friends at Overlap in Vienna, Austria. Nimbus integrates natively with EventSourcingDB and brings clear, explicit support for commands, events, and queries to the JavaScript and TypeScript world. We're genuinely grateful to be celebrating this with them. Overlap has built something thoughtful and substantial, and the JavaScript and TypeScript world is better for it.

We won't pretend Nimbus is the first attempt to bring CQRS and Event Sourcing into JavaScript. There have been several over the years, including our own historical effort, wolkenkit. What makes Nimbus stand out is not novelty, but approach: a deliberately minimalist, explicit design built from day one around a dedicated event store. It's also a sign of something larger, a quiet but unmistakable shift in how serious teams are choosing to build software.

Why TypeScript Deserves a Fresh Take

TypeScript and JavaScript form the most widely used language ecosystem in software today. There is no shortage of frameworks. There is, however, a shortage of frameworks that take Event Sourcing seriously, that don't shoehorn it into a CRUD-shaped runtime, and that respect TypeScript's strengths instead of fighting against them.

We've watched this space for a long time. We've also contributed to it. Nearly a decade ago we built wolkenkit, our own framework for CQRS and Event Sourcing in Node.js, and we learned a lot in the process about what works and what doesn't. We've written about that journey in Ten Years, One Goal, including the parts that worked and the parts that taught us hard lessons. Other teams have built their own frameworks, too, with their own trade-offs and lessons. None of those efforts are wasted, every one of them moved the conversation forward.

But the recurring pattern was always the same. Many of these frameworks lean on heavy object-oriented machinery, decorator metaprogramming, or layers of clever abstractions that obscure what the code is actually doing. Others were never built around a dedicated event store at all, they bolted Event Sourcing onto general-purpose databases, with all the consistency and replay headaches that creates. The result was that adopting Event Sourcing in TypeScript felt heavier than it needed to.

Nimbus takes a deliberately different stance. It is minimalist, explicit, TypeScript-first, and designed from day one around a purpose-built event store. That combination is what makes it noteworthy. It isn't trying to reinvent the discipline, it's trying to make it approachable, and it does so by getting out of your way.

Friends in Vienna

The team behind Nimbus is Overlap GmbH & Co KG, a digital agency from Vienna that combines deep web development experience with day-to-day product work for real customers. They build software that has to ship, run, and stay maintainable, often in environments where the cost of getting it wrong is high.

The primary architect and lead developer behind Nimbus is Daniel Gördes, Overlap's CTO, with the wider team at Overlap contributing alongside him. Working with Daniel has been one of those collaborations where the conversation moves quickly because the underlying assumptions are already shared. From the first calls, it was clear we agreed on the basics: that events are how the real world actually works, that snapshots are a convenience the domain pays for later, and that frameworks earn their keep by reducing accidental complexity rather than adding new layers of it.

Nimbus came out of building real software for real customers and discovering, again and again, that the existing options didn't quite fit. That kind of pressure produces honest design decisions. You can see them throughout Nimbus, in what's there and in the restraint with which the team chose what to leave out.

The collaboration involved many conversations about consistency boundaries, about how Subjects should map onto TypeScript domains, about what "good" looks like for ergonomics in a JS-native API, and about where to draw the line between flexibility and opinionated guidance. Those conversations were rigorous and sometimes uncomfortable, in the best possible way. Working with a team that sweats the same details we do is a privilege, and we're grateful for it.

Explicit Over Magic

Nimbus's design philosophy can be summed up in three words: just explicit code. There are no hidden lifecycles, no decorators wiring things up behind your back, no runtime metaprogramming you have to mentally simulate to understand what your application is doing. If you want to know what happens when a command is dispatched, you can read it.

This matters more in JavaScript and TypeScript than it might in some other ecosystems. The JS world has a long tradition of clever framework magic, dependency injection containers built on reflection, decorators that rewrite class semantics, runtime proxies that alter object behavior, transpilation steps that quietly transform your code. Sometimes that cleverness is justified. Often it isn't. Cleverness has a cost, and the cost is paid by every developer who joins the project later.

Explicit code is easier to read, easier to test, easier to refactor, and easier to onboard new team members onto. It also ages better. Six months from now, when you're back in the codebase chasing down a subtle bug, explicit code is the difference between a productive afternoon and a frustrating week.

Nimbus organizes applications around three core building blocks: commands are the actions a user or system wants to perform, events are the immutable facts that capture what actually happened, and queries are the questions your system answers from its read models. That's the entire vocabulary you need to start, and it's enough vocabulary to model surprisingly complex domains.

You'll notice this is essentially the CQRS triad, and that's not a coincidence. Nimbus doesn't force you into CQRS in any dogmatic way, but it leans into the pattern naturally because the pattern itself reflects how event-driven systems actually behave. If you'd like a deeper take on why CQRS is simpler than its reputation suggests, we wrote about it in CQRS Without the Complexity.

Standing on a Solid Foundation

A framework is only as good as the substrate it runs on. Nimbus is built directly on top of EventSourcingDB, and that choice shows up in the shape of the framework itself. The two were designed to work together, not glued together after the fact.

Concretely, that means Nimbus gets to treat subjects as a first-class organizing principle for events, a natural fit for domain hierarchies and bounded contexts. It can lean on EventSourcingDB's dynamic consistency boundaries to give your code fine-grained transactional guarantees without forcing you into coarse, locking-heavy aggregate models. And it can take advantage of tamper-evident, cryptographically signed events when your domain calls for compliance and auditability, increasingly the norm rather than the exception in regulated industries.

That same care for the substrate shows up at the application layer. Nimbus treats zod schemas as the single source of truth for every command, event, and query, with the matching TypeScript type derived from each schema via z.infer. Schema and type can never drift, because there is only one definition. The router validates incoming payloads against the registered schema before a handler ever runs, so handlers always operate on data that has already been parsed into the exact shape they expect, no defensive null-checks, no manual casts, no runtime surprises. The type system flows cleanly from the network boundary all the way to your domain logic, and it does so with code you can actually read top to bottom. This is what "explicit over magic" looks like in practice: a single, transparent mechanism doing the work that more elaborate frameworks tend to spread across decorators, metadata, and runtime reflection.

Nimbus also takes operational concerns seriously. OpenTelemetry is built in from the start, with logging, tracing, and metrics available out of the box. That sounds mundane, but it's the kind of thing that quietly determines whether a system survives its first encounter with production.

The framework is built to run on both Node.js and Deno, so you can pick the runtime that fits your team rather than the one your framework dictates. The packages are published on both JSR and npm, which keeps the install path familiar regardless of where you live in the modern JavaScript world. And because Nimbus is released under the Apache License 2.0, it's friendly and permissive to adopt, including in commercial settings where licensing questions can otherwise stall a project before it begins.

What's interesting about this combination is how the pieces reinforce each other. Because the event store handles consistency, replay, and integrity at the database level, Nimbus doesn't have to reinvent any of that in the application layer. Because the type system carries validated, fully-shaped data from the network boundary all the way down to your handlers, malformed messages never reach your domain logic in the first place. Because Nimbus stays small and explicit, your application code stays close to the domain rather than drowning in framework scaffolding. And because observability is built in, you don't discover three months into production that you have no idea what your system is actually doing. Each layer does what it's good at, and stays out of the way of the others. That kind of separation is rarer than it should be, and it's part of what makes Nimbus pleasant to work with.

An Ecosystem Coming of Age

Step back for a moment and look at what teams in the Event Sourcing community are actually building. Two of the most important runtime worlds in modern software development now have purpose-built, production-grade frameworks for event-driven applications: the JVM through OpenCQRS, built by Digital Frontiers, and TypeScript and JavaScript through Nimbus, built by Overlap. The depth and maturity of the work itself is the story worth dwelling on.

That work belongs entirely to Overlap. They saw a real need in the TypeScript community, formed real opinions about how to address it, and put in the patience and craft it takes to ship something thoughtful. Building a framework of this caliber takes years of careful engineering, of weighing trade-offs nobody else will ever see, and of resisting the temptation to add one more abstraction. Daniel and his team did all of that, and the result speaks for itself. We've written before about how good ideas grow stronger through collaboration in Great Minds Should Not Think Alike, They Should Think Together, and Nimbus is a clear example of that principle in action.

It also says something larger about Event Sourcing as a discipline. What used to feel like a niche pattern reserved for systems that absolutely needed it is becoming a normal way to build serious software. When independent teams like Overlap and Digital Frontiers are willing to invest at this level, the conversation has moved on. This is the quiet, unmistakable shift we mentioned at the start: Event Sourcing is becoming the default choice for teams who take their domain seriously, and Nimbus is one more reason that shift is hard to miss.

What This Means for Your Next Project

If you build TypeScript or Node.js applications, and you've been curious about Event Sourcing or CQRS but uncertain about the tooling, Nimbus is now a serious option you can pick up today. It lowers the cost of starting, the cost of testing, and the cost of reasoning about consistency, three of the biggest barriers we've seen teams run into when they try Event Sourcing for the first time.

Nimbus is a focused tool for teams that already see value in modeling their domain as events, or who are ready to start. That focus is a feature. Frameworks that try to be everything to everyone usually end up being not quite enough for anyone.

Our suggestion, if you're curious, is the same one we'd give for any new architectural style: try it on a small bounded context first, ideally one where the domain is genuinely event-shaped. The Nimbus team has put visible care into onboarding material, and it shows. The Quick Start gets you to a running example quickly, and the In-Depth Example is genuinely excellent, one of the clearest end-to-end walkthroughs of an event-driven application we've seen anywhere in the TypeScript world. It's worth your time even if you haven't yet decided whether Nimbus is the right fit for your project. If you'd like a refresher on the modeling discipline that makes Event Sourcing pay off, our post on Domain-Driven Design Back to Basics is a good companion piece.

Where Nimbus Goes from Here

Nimbus reaching this milestone is not the end of a journey, it's the beginning of one. The framework will evolve, shaped by feedback from real users and by the realities of production deployments. We're excited to watch it grow, and we're deeply grateful to Daniel Gördes and everyone at Overlap for the care, taste, and persistence they've poured into this work. Frameworks of this quality don't appear by accident.

If you'd like to explore Nimbus for yourself, the framework's home is at nimbus.overlap.at, with the source code on GitHub. Have a look, try it on a real problem, and if you find it useful, consider giving the project a star and sharing your feedback with the team. Open source thrives on visibility, and frameworks like Nimbus grow stronger when the people who use them help shape what comes next.

We'd also love to hear from you. If you're thinking about Event Sourcing for your next project, weighing whether Nimbus is the right fit for your stack, or simply curious about how all of this hangs together, write to us at hello@thenativeweb.io. Congratulations once again to Daniel and the entire team at Overlap on the launch of Nimbus. The credit here is theirs, and we're proud to walk alongside them.