Append Events with an expected version

[watfordsuzy]

I'm looking through the API Docs while playing with Emmett and am wondering about the elision of expectedVersion on the EventStore interface:

emmett/packages/emmett/src/eventStore/eventStore.ts

Lines 3 to 20 in 9650af6

	// #region event-store
	export interface EventStore {
	aggregateStream<Entity, E extends Event>(
	streamName: string,
	options: {
	evolve: (currentState: Entity, event: E) => Entity;
	getInitialState: () => Entity;
	},
	): Promise<Entity | null>;
	readStream<E extends Event>(streamName: string): Promise<E[]>;
	appendToStream<E extends Event, NextExpectedVersion = bigint>(
	streamId: string,
	...events: E[]
	): Promise<NextExpectedVersion>;
	}
	// #endregion event-store

It is my assumption this interface would instead look something like:

// #region event-store
export interface EventStore {
  aggregateStream<Entity, E extends Event, NextExpectedVersion = bigint>(
    streamName: string,
    options: {
      evolve: (currentState: Entity, event: E) => Entity;
      getInitialState: () => Entity;
      startingVersion?: NextExpectedVersion | undefined,
    },
  ): Promise<{ entity: Entity | null, nextExpectedVersion: NextExpectedVersion }>;

  readStream<E extends Event, NextExpectedVersion = bigint>(
    streamName: string,
    startingVersion?: NextExpectedVersion | undefined
  ): Promise<E[]>;

  appendToStream<E extends Event, NextExpectedVersion = bigint>(
    streamId: string,
    expectedVersion?: NextExpectedVersion | undefined,
    ...events: E[]
  ): Promise<NextExpectedVersion>;
}
// #endregion event-store

Is this a conscious design choice to represent a simpler model of event sourcing?

[oskardudycz]

@watfordsuzy, let me quote my response on your PR:

@watfordsuzy, thank you a lot for the PR and for the issue. Indeed, the lack of optimistic concurrency is a big thing. I didn't add that initially without the intention to hide that part or ignore it. The first release was focused on the business logic; now it's time to do the application layer correctly.

I'm planning to do it more or less like in the solution in my self-paced kit: https://github.com/oskardudycz/EventSourcing.NodeJS/blob/2d417bd2e650c16b4af68b6a752bd684ce0a8fc0/workshops/introduction_to_event_sourcing/src/solved/07_optimistic_concurrency_eventstoredb/tools/eventStore.ts#L99

I'm going to pull your changes in and restructure them a bit. Thank you a lot for the contribution and double-checking if I didn't miss it!

I'm going to work on that today and tag you also in the PR that will fully introduce that 🙂

[oskardudycz]

@watfordsuzy see the changes made in:

• Refactored the event store definition to include the optimistic concurrency checks #12 adding the general layout of the Optimistic Concurrency Handling,
• Added InMemory store #13 adding example in-memory implementation

Feedback is welcome 🙂

[watfordsuzy]

Thank you, pulling it down now!