Snapshotting feature?

[Ilyes512]

Hi,

I have been looking and playing with this package and so far so good 👍. I was however wondering if it had snapshotting capabilities. My conclusion now seems to be "no". But it seems it did had that feature one time. I found the fallowing info so far:

• First of all I found this cached google page: https://webcache.googleusercontent.com/search?q=cache:AHjtzxdy5XAJ:https://docs.spatie.be/laravel-event-projector/v1/advanced-usage/working-with-snapshots+&cd=1&hl=nl&ct=clnk&gl=nl&client=safari
• I also found some (left over?) exceptions: https://github.com/spatie/laravel-event-projector/search?q=snapshot&unscoped_q=snapshot
• Fix DeleteSnapshotCommandTest #38

So my question now is if it's on the roadmap? What was the reason the old snapshotting capabilities where removed?

BTW, I have to say that (allot of) the commit messages in this repo are ... well, terrible :P. On a positive side! The separate documentation site is easy/nice to read, however there are some mistakes in the examples and some of the wording is not totally correct. Like for example I came across the "Image" while it should have been "Imagine".

[fgilio]

I'm also interested in the snapshotting capabilities.

---

Submitted a tiny PR to replace those "Image" in two locations, couldn't find any others.

[freekmurze]

What was the reason the old snapshotting capabilities where removed?
Because I couldn't find a compelling use case where snapshots are needed. When and how would you use them?

So my question now is if it's on the roadmap?

It's not on the roadmap, but my nuked implementation was 90% ready. If more people ask for this (and present some good use cases), I'm willing to restore the feature, polish it a bit more and release it.

BTW, I have to say that (allot of) the commit messages in this repo are ... well, terrible :P

I'm in team Hemphill: https://twitter.com/davidhemphill/status/1020328960763285504
For bigger projects I do use commit message, but not when I'm hacking away at stuff in a solo project.

Like for example I came across the "Image" while it should have been "Imagine".

Every page in the docs has an edit button at the top. It let's you easily create a PR to fix a spelling error. PRs are highly appreciated! 👍

[freekmurze]

@fgilio thanks for those PRs!

[Miguel-Serejo]

When I was working on my basic implementation project, I did consider using snapshots for the history view mode. However, I wanted full step-by-step history without having to make a snapshot after every event.

In theory, I can see how snapshots would be useful. Having monthly/weekly/daily/hourly snapshots could be useful for metrics (How many new users did I get this month? Let's just compare last month's snapshot to today's). In practice, however, you can get the same metrics by just running a statistical projector on your events, even if you didn't remember to add those metrics to the snapshots.

In the end I couldn't find a valid usage for snapshots (and was actually kinda bummed by that because I had intended my project to explore all of the package's functionality).

Did you have a specific use case for snapshots in mind?

[frizikk]

@36864 As i know snapshots are used for optimize event replay.

Snapshots are sometimes shown in examples of event sourcing. Snapshots are a type of memoization used to help optimize rebuilding state. If we have to rebuild state from a large stream of facts, it can be cumbersome and slow. This is a problem when you want your system to be fast and responsive. So we take snapshots of a projection taken at various points in the stream so that we can begin rebuilding state from a snapshot instead of having to replay the entire stream. So, a snapshot is a cache of a projection of state at some point in time.

[Miguel-Serejo]

Well, that actually makes a lot of sense. After reading that explanation I shifted my perspective from "snapshots every [time interval]" to "snapshots every [event interval]" and now I want them.

I never ran tests with more than a couple hundred events, but I'd bet my history view could benefit from snapshots if the app grew to a few thousand events.

[Ilyes512]

Yes, like @frizikk says it's more like a "savepoint" from which you can start your projections. And it could be you create a snapshot after each passing year or so. I just starting dipping into event-sourcing and so at this point I don' really need it.

At this point I only read the documentation and still have to dive into the library it self (I did fallow along with the examples and made it async instead of sync events).

I am planning on also looking at Prpooh and Eventsauce (maybe also Broadway). I know that Eventsauce does not have snapshotting (but it did mention it made some changes that would make it possible), but Prooph does. I am interested in how they have implemented it and might come back here and try to implement it for this project.

Besides snapshotting I think "Upcasting" is also nice to have.

Edit:

Ah, If we are talking about features. I wonder what would have to change to make multiple event consumer/projectors possible. Now I can only run a single container consuming the specific queue. Would be nice to be able to have multiple consumers running.

[peterfox]

I could see snapshots being pretty useful especially in an age of GDPR etc. At least I think snaphots is what I'm looking for.

I was wandering if there's a way to kind of squash multiple events from a set period or for X number of events into a single event to reduce the need for storing it all. Using the examples in the docs for example, maybe I only want Account events going back 5 years, I don't mind keeping the account created event but I don't need the subtractions and additions before a certain timeframe and instead I want squash anything over those 5 years into one large event. Understandably this breaks aspects of the replay (namely to count transactions) but at the same time I can't see events after that 5 years being useful so I would go into using the feature with that expectation of losing that ability.

[ragingdave]

I would definitely like to see this. Assuming a very high event count system, snapshotting would give the ability to archive old records to not have millions of events to sift through over time.

Granted a sort of archival process could potentially become part of this altogether to enable a rebuild from a snapshot, or even rebuild from the beginning of time. The former using just the last snapshot and replaying events after that snapshot, and the latter enabling going to a secondary "archive" table, replaying those events then continuing to the current events table.

[freekmurze]

I probably will not have the time to code up this feature in the near future.

If somebody's up for it, here's my wip for snapshotting: 50530f2

I removed it because adding support for event streams to snapshots seemed like too much of a hassle.

If you have any questions on this let me know!

[sebastiandedeyne]

Gonna close this. If anyone wants to take over, feel free to continue the discussion in a PR!