0.34.0

🚀 What's New

• Added the first version of SQLite projections and exposed onBeforeCommit hook by @oskardudycz in 205

Full Changelog: 0.33.0...0.34.0

0.33.0

📝 What's Changed

• Exported the missing SQLite package code. It sounds like we did all the work making the SQLite event store, besides actually exporting it and making it available for people to use. 🤦‍♂️🤦‍♀️ Now we fixed that. by @oskardudycz in 204

Full Changelog: 0.32.0...0.33.0

0.32.0

🚀 What's New

• Added message type to store events, commands, and unify message processing. It adds a Message type that's either a command or an event. I added an additional property called kind, which will inform you what the message actually is (so if it's an event or command). This is the first step in enabling message storage and workflows. Kind is not mandatory, it's just a rebranded flavour type we already had. by @oskardudycz in 183

📝 What's Changed

• BREAKING: Renamed events tables to messages in the PostgreSQL and SQLite schemas and added message kind column. This is in theory breaking change, but I added automated migration script for PostgreSQL schema that should handle it seamlessly. If you faced any issues with that, please send us an info on Discord channel and we'll help in that by @oskardudycz in 184

📚 Docs

• Added overview page to documentation See it live in documentation by @tburny in 200
• Improved samples of events with metadata by @shraddha38 in 201

New Contributors

• @shraddha38 made their first contribution in 201

💬 Discuss this release on Discord

Full Changelog: 0.31.0...0.32.0

0.31.0

🚀 What's New

• Added the first version of PostgreSQL async projections by @oskardudycz in #197

Projections are defined the same way as inline ones (see more in the article).

The easiest way to use it is to:

const eventStore = getPostgreSQLEventStore(connectionString);

const consumer = eventStore.consumer();

consumer.processor({projection: someProjection });
consumer.processor({projection: otherProjection});

await consumer.start()

You can also run it explicitly:

const consumer = postgreSQLEventStoreConsumer({
   connectionString,
});

consumer.processor({projection: someProjection });
consumer.processor({projection: otherProjection});

await consumer.start()

or

const consumer = postgreSQLEventStoreConsumer({
   connectionString,
   processors: [
     postgreSQLProcessor({ projection: someProjection}),
     postgreSQLProcessor({ projection: otherProjection }),
   ],
});

await consumer.start();

I'm also considering, in the further releases, making them automatically registered as:

const eventStore = getPostgreSQLEventStore({
  connectionString,
  projections: projections.async([someProjection, otherProjection]),
});

// consumer will get async projections registered as processors
const consumer = eventStore.consumer();

await consumer.start()

📚 Docs

• Added API reference link to documentation sidebar and update title in API docs by @tburny in #199

New Contributors

• @tburny made their first contribution in #199

Full Changelog: 0.30.0...0.31.0

0.30.0

📝 What's Changed

• Made consumer options really optional when creating it from event stores by @oskardudycz in 195

Full Changelog: 0.29.0...0.30.0

0.29.0

🚀 What's New

1.Added first EventStoreDB consumer

You can set it up as:

const consumer = eventStoreDBEventStoreConsumer({ connectionString });

consumer.processor({ 
  eachMessage: (event: YourEventType) => {
    // do your handling here
  } 
});

await consumer.start();

by @oskardudycz in 189, 190

2. BREAKING: Renamed consumer subscriptions to processors.

Initially, I came up with the following split:

• Consumers - primarily responsible for pushing messages to multiple handlers/subscribers.
• Subscribers - diverse roles: Some store data, some trigger workflows, and some forward to other systems. Checkpointing is subscriber-specific, meaning each subscriber manages its own message state independently.

Still, after discussion, it appeared that Subscription in this context may be wrong or confusing. This could work to describe the relationship between the consumer and its individual subscribers. However, "subscription" often implies pub/sub semantics, where the subscriber initiates the relationship.

Here they just process messages they get passed by consumer. Also, since Emmetts’s subscribers also checkpoint and process messages independently, I decided to name them Processors.

Processor term is also common in event-processing frameworks, especially when the focus is on message handling or transformation. Processor is an independent unit that receives messages and performs an action (e.g., running a workflow, updating projections, forwarding to another service).

I was thinking about naming Consumer a Consumer Group, and Subscription Consumer. That would also work, but could confuse when I add Kafka support, as Emmett processing works differently in Kafka (it’s more fan out, so each processor gets the same batch of messages). That could create nasty confusion.

by @oskardudycz in 191

3. Added default event type to consumers

Thanks to that, processors will be automatically typed. This can be useful if we have multiple processors for the same stream subscription.

It's optional and falls back to the event, so each processor can still have its own event type (e.g. when subscribing to all events).

Another option is to put a union of all events in consumer and then use just a subset of those types in processors.

Added a deadline for consumer tests to stop them in case of some transient issue.

by @oskardudycz in 193

4. Added possibility to create consumers from directly from event stores

This will allow the PostgreSQL pool or EventStoreDB client to be reused, simplifying the potential setup and increasing performance.

For PostgreSQL event store this will look as:

const eventStore = getPostgreSQLEventStore(connectionString);

const consumer = eventStore.consumer();

consumer.processor({ 
  eachMessage: (event: YourEventType) => {
    // do your handling here
  } 
});

await consumer.start();

and from EventStoreDB:

const eventStore = getEventStoreDBEventStore(eventStoreDBClient);

const consumer = eventStore.consumer();

consumer.processor({ 
  eachMessage: (event: YourEventType) => {
    // do your handling here
  } 
});

await consumer.start();

by @oskardudycz in 194

📝 What's Changed

• Enabled PostgreSQL consumer tests. They were not run by accidentally missing .spec in the file name 🤦‍♂️ by @oskardudycz in 192

Thanks also go to @mbirkegaard for the inspiration to make those changes.

Full Changelog: 0.28.0...0.29.0

0.28.0

🚀 What's New

• BREAKING: Add support for async decide for DeciderSpecification. This PR also fixes the typo in the type specification name. You need to change DeciderSpecfication into DeciderSpecification by @alex-laycalvert in 188

Full Changelog: 0.27.0...0.28.0

0.27.0

🚀 What's New

• Added SQLite event store the ability to create connection. Now the connection management and setup can be streamlined and outsourced to event store by @davecosec in 178
• Add the first version of InMemoryDatabase It's a first step to fully supporting in memory projections by @stepaniukm in 186
• Added optional getDocumentId selector for single stream projection. Thanks to that, one can still use a custom ID based on the event data just like for multi-stream projections. by @oskardudycz in 187

📝 What's Changed

• Fixed the event store read event metadata inference by @oskardudycz in 180

📚 Docs

• Used PostgreSQL storage in documentation instead of EventStoreDB, as it's the most popular choice and the most feature rich option by @oskardudycz in 181

New Contributors

• @stepaniukm made their first contribution in #186

Full Changelog: 0.26.0...0.27.0

0.26.0

📝 What's Changed

• BREAKING: Changed dbConn for sqliteConnection SQLite connection setup function name. The previous one was a bit enigmatic. by @davecosec in 176
• Fixed typing for Command Handler async result. This was needed to enable async middleware processing for command handling. See more in the example by @oskardudycz in 177

Full Changelog: 0.25.0...0.26.0

0.25.0

🚀 What's New

Added SQLite event store functionality.

Now you can use SQLite event store implementation by installing the package with

npm install @event-driven-io/sqlite

then importing it and using similarly as PostgreSQL event store:

import sqlite3 from 'sqlite3';
import { dbConn, getSQLiteEventStore } from '@event-driven-io/sqlite';

const conn = new sqlite3.Database(':memory:');
const db = dbConn(conn);
const eventStore = getSQLiteEventStore()

It's the first version, so it my have rough edges. Big kudos goes to @davecosec for delivering it! in #173

Besides that

• Added precommit hook to append to stream to SQLite event store by @davecosec in #174

📝 What's Changed

• Fixed browser compatibility test in CI by @oskardudycz in #175

Full Changelog: 0.24.0...0.25.0