Async IO?

[devnix]

Hi! I was wondering if an async IO would be considered at some time, like for example amp/mysql, or even https://github.com/prooph/event-store-client, which looks like a great fit for the project!

[DavidBadura]

Hey! That is a very good question, and to be honest, I do not know yet.

We have not reached the point where a sync event store is the bottleneck, either in our projects or in projects we are involved in.

To better understand the need, it would be helpful to understand in which situations an async event store can help. So, which environment (events, throughput) are we talking about here?

We currently use Doctrine DBAL for the database connection, and there is a corresponding issue for it: doctrine/dbal#5825
It also lists some adapters to make DBAL async-capable, so I am wondering if this can not (currently) be solved using a DBAL adapter?

[DavidBadura]

And regarding EventStoreDB/kurrent: We wanted to take a look at that sometime. When we have the time :D

[devnix]

Thanks for the response! The use case would be to be able to use this library in a React/Amp based application without blocking the event loop.

I guess I could try to take a look at the suggested packages, but I think they are outdated or just incomplete. I'll do my research.

I still have to dive deeper at your codebase but, you rely on DBAL just for the connection, or do you make actual use of the query builder? If there's not a direct dependency to DBAL and the query builder, a nice alternative could be an interface with adapters for each storage option?

About the EventStoreDB: it feels like a natural storing solution for this context, and the existing PHP library is already asynchronous, which looks like a great advantage!

[DavidBadura]

still have to dive deeper at your codebase but, you rely on DBAL just for the connection, or do you make actual use of the query builder? If there's not a direct dependency to DBAL and the query builder, a nice alternative could be an interface with adapters for each storage option?

Yes, we only use dbal internally. It is fully abstracted, and you can easily write your own stores by implementing this interface:
https://github.com/patchlevel/event-sourcing/blob/3.12.x/src/Store/StreamStore.php

About the EventStoreDB: it feels like a natural storing solution for this context, and the existing PHP library is already asynchronous, which looks like a great advantage!

Absolutely! We do not use it ourselves, so we did not have time to look into it. But we are always happy to see contributions.

[devnix]

So you have your own abstraction! Nice, so I can do one from scratch without having to hack around DBAL 😄

I think I'll work around amphp/mysql, which by the way allows to iterate through an unfinished response, so I guess it's possible to apply events to a large aggregate while the query is still being streamed, that looks killer to me!

I still need to wrap my head around the difference between the Store and the StreamStore, but it will come.

Thank you!

[DavidBadura]

Sounds good.

I still need to wrap my head around the difference between the Store and the StreamStore, but it will come.

Previously, we defined our store using aggregate type and aggregate ID, thus tightly coupling it to even sourcing. With experience, we have generalized and decoupled this, so that our store now only works with streams and can also be used for other purposes. The translation between aggregate type and ID to stream name is then done in the aggregate repository (${aggregateType}-${aggregateId}). By generalizing it, we defined additional methods for the Store API in a new StreamStore interface. This will be merged with Store interface starting with version 4. It is best to use the new StreamStore interface.