Question: Any intention to extend/fork this library to async?

[bolbken]

I'm attempting to use this library in an ASGI app and wondering if an asyncio effort is underway. Saw this issue comment

The principles and abstraction of this library are stellar! I'm hoping with an async implementation the IO performance could be stellar as well. Thoughts? Progress?

I'm eyeing the async SQLAlchemy functionality and/or asyncpg as orm/driver candidates.

High potential I could get some time to begin a naive async implementation soon.

[johnbywater]

Sorry for the delay in answering this. The short answer is yes. Beyond that I'm not really very sure which of several paths to take with this. We have discussed this topic several times on the Slack workspace, but didn't settle on anything yet.

If you haven't already, maybe you could join the Slack workspace and post or DM me on there, and we can schedule some time to shake this down to some kind of decision and move things forward like that?

Many thanks for raising the topic. I'm very interested in this, as are several others.

[johnbywater]

Hey @bolbken just wanted to let you know I'm working on async stuff in this branch: https://github.com/johnbywater/eventsourcing/commits/feature/async_by_duplicating_methods

[MrLokans]

Hi there, just wondering, is there an idea to proceed to implement the async approach? The ideas and the level of maturity are quite astonishing in this library, yet the sync-only nature unfortunately makes it pretty unusable for async-based projects I happen to work on, so I'm interested to hear any thoughts on that, thank you.

[MrLokans]

As far as I can see from the branch commit discussion (f919f27#r71967500) the reason why the development has been abandoned (as far as I understand, at least) is that the async codebase performed poorly compared to the sync on in terms of speed and interested to understand whether it is possible to release those changes even considering this fact (maybe as some part of the beta/non-stable API).

[johnbywater]

Hey @MrLokans thanks for your nice comments about the library, and for your interest in this topic. Let's look into this again. I'm definitely sympathetic about the concern you described. Perhaps this time we should firstly get it working with the POPO persistence module, and then see about other database adaptors.

[dimitar-petrov]

@johnbywater: Is this effort for the persistence mechanisms to support asyncio or also @event decorator will be able to work on async command methods.

[johnbywater]

I don't think the aggregate decorator would need to be an async function? It's just the stack down to the database?

That's unless the aggregate command methods are async. Are you writing aggregates with async command methods too?