Event-Driven TypeScript: An Interview on Nimbus - EventSourcingDB

Skip to content

Initializing search

Getting Started

Fundamentals

Deployment and Operations

Reference

Client SDKs

Extensions

MCP Server

Best Practices

Implementation and Development

Data Management and Performance

Operations, Compliance and Infrastructure

Common Issues

Blog

Categories

Privacy Policy

Legal Notice

Event-Driven TypeScript: An Interview on Nimbus¶

Golo: Daniel, you're the CTO of Overlap in Vienna, Austria, and the lead architect behind Nimbus . Overlap isn't a framework shop, you build and ship real products for real customers, which makes the decision to build a framework all the more interesting. Before we get into the design, take us back to the beginning: what were you running into, again and again, in actual projects that made you decide to build Nimbus rather than reach for something that already existed?

Daniel: Where do I start here? It wasn't one big moment that led to the decision to build our own framework. It grew gradually, and a few things added up. One thing that always felt like a paradox to me was the fact that you need to invest a lot of time into learning most of the complex frameworks out there, and even after learning it, you often have to spend time "fighting" it . And every new developer who joins the project has to do the same. So the time spent using the framework instead of just focusing on the business logic, the clients pay us for, adds up.

Another event that showed us we need to think things differently was the AI hype of the last years. Apart from all the hype, it was a catalyst for most companies realizing the data they store within all the applications mostly shows a snapshot of the current state but do not deliver enough context and quality to fuel AI systems for proper reasoning and analytics. This led us to Event Sourcing and CQRS to build a better data foundation. The second part AI shows us is that the comfort of writing code gets less important. AI will write it for you anyway. On the other hand, the comfort of reading and understanding the code becomes even more important .

So we claimed that the framework we would like to use needs to have a focus on Event Sourcing and CQRS. It has to emphasize explicit code without a lot of framework magic in the background so you can simply read the code top to bottom like a book and instantly reason about it. And finally, you should be able to learn the concept of the framework and how to use it within less than a day.

After testing multiple frameworks in different projects we found the tool we wished for did not exist in the shape we wanted, so we built it. Not to ship a framework as a product, but because we needed it for our own work .

Golo: The JavaScript and TypeScript world has seen several attempts to bring CQRS and Event Sourcing to life, including our own wolkenkit nearly a decade ago. You've clearly studied that history. What did those earlier efforts get right, what did they get wrong, and what did you consciously decide to do differently with Nimbus?

Daniel: First, real credit where it's due. I think wolkenkit was ahead of its time. It brought CQRS and Event Sourcing to JavaScript when almost nobody in this ecosystem was talking about them, and it showed that these patterns are not just some enterprise Java thing. I have to be honest, I knew of wolkenkit, but never studied it in real depth. So I would rather not pretend to judge its internals. But the direction it pointed in was clearly right. The core idea with events as the source of truth, a clear split between writing and reading, and modeling the business properly has aged really well. It is more relevant today than ever .

What was harder back then was the foundation underneath. Frameworks had to build everything themselves, including the event store, on top of databases that were never really made for it. That is a huge amount of work, and it pulls the framework into territory that is challenging to get right. They also tended to grow big because they had to solve every part of the problem at once. TypeScript was not where it is now. Tools like Zod for schema validation did not exist. Standards like CloudEvents and OpenTelemetry were not around to build on. So those frameworks had to invent a lot that we can now just take off the shelf .

So what did we do differently? Three things, mainly. We stand on a real event store, EventSourcingDB . We keep the framework small, explicit and unopinionated instead of trying to solve everything for the user. And we lean hard on modern standards, Zod, CloudEvents, OpenTelemetry, so Nimbus can stay focused on the patterns themselves and let proven tools handle the rest.

Explicit Over Magic¶

Golo: Your tagline is almost a provocation: "No framework magic, just explicit code." In an ecosystem that loves decorators, dependency injection containers, and runtime metaprogramming, that's a bold stance. Where have you...