github.com/event-driven-io/emmett @0.42.3
Chat with this repoWhat it actually does AI analysis from the code graph — generated when you open this
README
Emmett - Event Sourcing development made simple
Emmett is an opinionated yet flexible framework that implements Event Sourcing for Node.js applications. It focuses on composition rather than magic, providing lightweight abstractions and clear patterns that make Event Sourcing accessible and maintainable.
Why Use Emmett?
Nowadays, storage is cheap, but the information is priceless.
Event Sourcing, keeps all the facts that happened in our system as events. That provides an observability of the business process and enabling event-driven capabilities like building read models, easier integration between components.
However, implementing Event Sourcing can be challenging due to:
- additional learning curves for new developers,
- knowing how to structure your code,
- implementing event storage,
- difficulty in setting up proper testing strategies,
- integrating with existing frameworks and infrastructure.
Emmett solves these problems by:
- Reducing boilerplate with pragmatic abstractions,
- Providing clear patterns for common operations,
- Supporting multiple testing approaches with built-in utilities,
- Including ready-to-use event store implementations,
- Offering simple integration with Express.js.
Check Emmett and take your event-driven applications back to the future!
Features
| Feature | Description |
|---|---|
| Event-Centric Modeling | Structured approach to modeling business processes through events |
| Multiple Event Stores | Built-in support for PostgreSQL, EventStoreDB, MongoDB, SQLite, and In-Memory storage |
| Command Handling Patterns | Standardized approach to command processing and event handling |
| Building read models | Built-in projections to build read models from recorded events. |
| Type Safety | First-class TypeScript support with structural typing |
| Express.js Integration | Seamless integration with Express.js, including conventional error handling etc. |
| Comprehensive Testing Support | Tools for unit, integration, and E2E testing with BDD-style syntax |
| Lightweight Design | Focused on composition over replacement, allowing integration with existing systems |
| Docker Testing Integration | Support for TestContainers to simplify database setup in tests |
Documentation and Resources
Read more in documentation, join our Discord Channel and ask any question.
See the video tutorial to learn how to build a full application with it:
Check also my blog articles on Emmett:
- Announcing Emmett! Take your event-driven applications back to the future!
- Testing Event Sourcing, Emmett edition
- Event Sourcing on PostgreSQL in Node.js just became possible with Emmett
- Writing and testing event-driven projections with Emmett, Pongo and PostgreSQL
- Using event metadata in event-driven projections
FAQ
Is it production-ready?
What's there is safe to use. I'd like to add more stuff to enhance the production experience, like OpenTelemetry, but users are already using Emmett in their systems.
Why Node.js?
I like its minimalistic approach and flexibility, plus TypeScript is an excellent language with its shapeshifter capabilities. Plus, I've been asked if I could deliver such a store for Node.js.
Why is it named Emmett?
What features will it have?
We'll see, but for sure, I'd like to have the following:
- implementation of event store using other storage engines like DynamoDB, CosmosDB etc.
- building blocks for integration and running distributed processes,
- GraphQL API for event stores,
- Full stack development helpers with Next.js or HTMX,
- built-in open telemetry,
- streaming data through HTTP API (and enabling integration scenarios through it).
- defining event transformations and projections with WebAssembly,
- etc.
Would it be a competitor to other stores?
It is hard to say; my intention is not to compete but to give more options to the community.
Why there's no license?
There's an open RFC explaining the reasoning and what are the next steps, but TLDR: it'll be (probably)AGPLv3 and/or SSPL and open/core model with paid tools around Emmett. I don't want to do a rug pull later, and I know MIT is too permissive. I want to build Emmett as a community project, but I also don't want my work to be unsustainable and for others to take advantage of it. It'd benefit all if I had a sustainable way to focus on delivering more value in Emmett. I'd be grateful for your comments on the RFC. If you have more detailed questions or concerns, please join our Discord, and I'm happy to clarify them!
Support
💖 If you'd like this project and want us to deliver more and faster, feel invited to join the group of our 👉 Github Sponsors.
By doing so, you're helping to make our work on it sustainable and continuing our efforts so we can support your products.
Contributing
Emmett is a community project, so once you find something missing or not working, we encourage you to send us a GH issue or Pull Request extending the support or test coverage! Check also Contributing guide
If you think something is missing or want to get some features faster, I'm happy to take sponsoring to prioritise it. Feel free to contact me - we'll find a way to help you!
Code of Conduct
This project has adopted the code of conduct defined by the Contributor Covenant to clarify expected behavior in our community.
Extension points exported contracts — how you extend this code
Decoder (Interface)Core symbols most depended-on inside this repo
assertEqualShape
Languages
Modules by API surface
Used by 1 indexed graphs manifest dependencies, hub-wide
Datastores touched
For agents
$ claude mcp add emmett \
-- python -m otcore.mcp_server <graph>