Besides what's already implemented on main, the following things would be nice to have before calling a v1.0.0 release:

• At least one or two implementations of actual event logs, so files, kafka, DB table, maybe Cassandra.
• Codecs, circe/binary would be a good start. Maybe protobuf or avro or something too.
• Rename the lib to something that sounds less like it's about elasticsearch
• Redo the docs
• Do a video on it. Maybe buy a green screen for it so I can be over the presentation.
• Machinery for "snapshotting" the event log.

MapRef right now is kind of weird in that it's not the only implementation out there, and it could probably be implemented better besides. Right now it's a bit naive and will work up to a certain performance limit where you might want a "real" concurrent data structure. Look into alternatives to bring in, and if necessary create PRs for features to make them more like the one written here.

It would look really nice if this project had a fancy microsite. Look at sbt-microsite, and also docusaurus. Will probably go with the latter. Wire in documentation, and maybe include some fancy GIFs and examples.

It'd be nice if it were possible to use FS2 ES in ScalaJS for state management. Maybe also consider including abstractions explicitly for this purpose.

Right now when creating a new EventState via hydrated it will .compile.drain the stream applying the events. This might not always be desirable, so provide a version where instead of running the stream separately it emits a single value of the final state. The current hydrated constructor can then just be based on it in turn.

Hi @sloshy :) I wondered what the status of this library is. Also, do you intend moving to CE 3 and Fs2 3?

Currently if one does N simultaneous requests to use an EventState through EventStateManager, it will evaluate the hydration stream up to N times, wasting resources. Thinking I should use Deferred or some other mechanism to synchronize access to state until after the first (and only) evaluation of the hydration stream.

To get these working Agitation would need a PR to support this as the primary reason it doesn't work is there are no "in" constructors in that library.

The name is confusing, and invokes connotations with cats.effect.Resource when it is an entirely distinct concept. Maybe something with "cache" in the name.

As event-sourced state accrues more events, it's often required to make snapshots or checkpoints that represent partially-accumulated state to speed the process of rehydrating up. This library does not have an explicit snapshotting mechanism, but rather it assumes that a "snapshot event" is persisted in your incoming event stream. So what if you use a different location for your snapshots such as HDFS/S3? It's certainly doable, though it might be confusing for a newcomer. Write out some documentation on how this should be done, and if necessary figure out architectural changes in the library to make this a better-supported feature.

A giant text blurb in a single README isn't the best kind of documentation. Ideally it should have sections that you can navigate to, and also possibly be built as a microsite. At the same time, take the opportunity to reword and make more approachable the underlying concepts of the library.

Sometimes it might be useful to know what event triggered what state. The internals of the various EventState implementations should be flexible enough to handle this option. In particular, this change would require rethinking the idea of an "initial state" to always require some incoming event. For the default case where there is no initial event, it can be modeled internally using Option[E] or something.