@nibbio/eddk
v0.4.0
Published
Nibbio Event-Driven Development Kit - a library to help you build event-driven applications
Downloads
86
Maintainers
Keywords
Readme
🤖 Nibbio Event-Driven Development Kit (eddk)
A lightweight library to help you build event-driven applications
The nibbio event-driven development kit (@nibbio/eddk) is a lightweight application library designed to help you build scalable event-driven applications. We provide a set of tools to help you build your application, and a set of best practices to help you build it right.
📚 Getting Started
Installation
With NPM:
npm install @nibbio/eddk
With PNPM:
pnpm add @nibbio/eddk
With Yarn:
yarn add @nibbio/eddk
Usage Example
import { Event, Command, Decider, EventStore, MessageBus } from '@nibbio/eddk';
💯 Core Concepts
Functional Event Sourcing: We use functional programming to model our domain, and event sourcing to persist it. This allows us to build applications that are easy to reason about, and that are resilient to change. Events are the only source of truth in our system, and we can always rebuild our application state from them. Functional programming allows us to model our domain as a set of pure functions, which are easy to test and reason about.
Command-Query Responsibility Segregation (CQRS): By splitting our application into a command side and a query side, we can build applications that are easy to scale. The command side is responsible for handling commands, and for emitting events. The query side is responsible for handling events, and for building the application state. This allows us to scale the command side independently from the query side, and vice versa.
Event-Driven Architecture: We use events to communicate between different parts of our application. This allows us to build applications that are loosely coupled, and that are easy to extend. We use a message broker to publish and subscribe to events. This allows us to build applications that are easy to scale.
📦 Components
The library is published as a series of helper types and functions that are designed to be used together. The main components are:
Event - The event type is a simple data structure that represents an event in our system. It contains the event name, the event payload, and the event metadata. The event name is a string that uniquely identifies the event type. The event payload is a JSON object that contains the event data. The event metadata is a JSON object that contains additional information about the event. The event metadata is used to store information such as the event timestamp, the event source, and the event version.
Command - The command type is a simple data structure that represents a command in our system. It contains the command name, the command payload, and the command metadata. The command name is a string that uniquely identifies the command type. The command payload is a JSON object that contains the command data. The command metadata is a JSON object that contains additional information about the command. The command metadata is used to store information such as the command timestamp, the command source, and the command version.
Decider - The decider type is a function that takes a command and returns a list of events. The decider is responsible for handling the command, and for emitting events. The decider is a pure function that does not have any side effects. This allows us to test the decider in isolation, and to reason about it easily. It is usually the core of our application.
Event Store - We expose a simple event store interface that can be implemented using any database. The event store is responsible for persisting events. Currently we also offer two concrete implementations:
- In-memory event store (for testing)
- Azure Cosmos DB event store
Message Bus - We expose a simple message bus interface that can be implemented using any message broker. The message bus is responsible for publishing and subscribing to events. Currently we also offer two concrete implementations:
- In-memory message bus (for testing)
- Azure Service Bus message bus (coming soon)
Streams - A set of helper functions that allow you to work with streams of events.
Primitives - A set of helper types and functions that allow you to handle results, success and failure cases.
ETags - Used for optimistic concurrency control.