get-eventually / go-eventually Goto Github PK

After #2 has been merged, the Lint workflow is failing.

The eventstore.Subscriber interface is used to support push semantics of Event Processors: new Events are pushed from the Event Store to the Processor, similar to Pub/Sub approach.

Push semantics is not always supported by all the event streaming technologies out there, and generally speaking event streaming platforms prefer pull semantics instead (currently supported by the eventstore.Streamer interface).

We can remove any trace of this interface from the codebase for v0.1.0, and only rely on pull semantics. This makes things harder for Volatile Subscriptions, but we could add some support for the Stream* methods to fetch events from the latest one available.

Currently, the eventstore/postgres implementation does not return a value of ErrConflict if there is a optimistic concurrency error: the exception is only raised on the pSQL code and not adapted to the Go error type.

This means that any error handling code based upon eventstore.ErrConflict won't work.

Url provided in CONTRIBUTING section in Readme file:
https://github.com/get-eventually/go-eventually/blob/main/CONTRIBUTING.md
leads to 404

We had to comment the code for Volatile Subscriptions after #42 , but let's try to find a way to re-enable it.

Context and problem statement

Aggregate Roots are typically "small", where the number of Domain Events registered for each AR is in the order of 100-1000.

In such cases, there is no problem rebuilding the state of an AR by the beginning of its Event Stream, as pulling ~1000 events back into the application should still be pretty efficient.

However, there are cases where an AR can record a pretty high number of Domain Events, reaching a point where replaying the Event Stream from the very beginning each time can become a performance bottleneck.

Solution

To alleviate this issue, we can use a Snapshot, which contains the state of the AR at a specific point. Snapshots can be used as a starting point for the AR rehydration to reduce the number of Events that need to be replayed from the Event Stream in the Event Store.

Instead of having a single eventually-go module with all dependencies, it might be a better idea to split functionalities in submodules to limit the number of indirect depedencies pulled from packages requiring eventually-go.

Due to the current limitations of Go, the postgres implementation of the Event Store needs an Event Register to be able to deserialize events from the remote storage into a Go object.

However, this concern is somewhat general to any possibleEvent Store implementation. We can then extract this piece of code in a separate module.

I hate manual tagging because, as everything tasked to a human being, the human factor brings inherent error.

Since we're all ✨ software engineers here ✨ we can automate the tagging process when merging on main -- maybe after the tests have passed?

NOTE: for each feature, a minor release should be used, and fix or minor branch, a patch release should be used instead.