Rebuild projection example

[Robertbaelde]

Hi Frank,

Let me start this (controversial) PR by saying that I totally agree with the statement about rebuilds you make in the documentation.

I noticed a few times now, that it might scare people away while choosing an EventSourcing package. Arguments like "Package X is better because it gives you replays out of the box" are easy to make for organisations getting started with EventSourcing. The perspective of "building your own rebuild mechanism" seems scary, and like a lot of work.

The idea behind this "example" rebuild implementation is to show people how easy it is to have a naive implementation (the implementation packages like https://github.com/spatie/laravel-event-sourcing provide).

I've updated the docs with why this naive implementation might not be a good fit in most situations and a short pointer to more robust rebuild strategies.

Curious if you noticed the same questions/discussions on this part of the package? And if you agree an example implementation might make the "Implementing your own is done in a matter of minutes" more concrete?

Although this adds a few lines of code to the package, I made sure that there were no changes needed in the "core". And all code lives in a separate directory that can be split into its own repository.

Cheers ✌️ 🚀

Todo before merge:

• [ ] create read-only repository and test if split works

[frankdejonge]

Hi @Robertbaelde,

Just so you know. I'm taking this under consideration. I might take a different approach in the design to accommodate locking a projection during replays, might need a different interface. I will experiment in the upcoming period to see if we can work towards a generic interface for this. It may not be a speedy thing to land, but it's good to start the discussion of course.

[Robertbaelde]

Nice! Yeah, this is the most naive implementation that would require the application to stop accepting commands once there is a replay happening. I choose this since I wasn't sure what your initial thoughts on the idea would be, and therefore didn't want to make it too complex.

Curious how you'd implement a projection engine that locks during replay, but doesn't keep state. Since eventually you'd need some queue to buffer new events right? Let me know when I can help with implementing some stuff.

I have a repo for a state-full replay engine here: https://github.com/Robertbaelde/ProjectionEngine Feel free to copy (some parts of) it.

I also started work on a replay engine that keeps track of state on an aggregate level. So you could replay a specific aggregate (this strategy comes with some tradeoffs though).

[frankdejonge]

Progress: https://github.com/EventSaucePHP/EventSauce/pull/181/files#diff-e2e1177ccc9e49d89b8890fb96c6e1cc796e6b7ebd6c90ba9b1e2e97fd4cdbc9

[frankdejonge]

@Robertbaelde we can probably close this PR now, right?