socketioxide icon indicating copy to clipboard operation
socketioxide copied to clipboard

Feature: Adapter trait with optional async

Open Totodore opened this issue 2 years ago • 5 comments

Make a version of the adapter trait async. This will allow remote adapter implementation (e.g redis adapter, mongodb adapter).

Totodore avatar May 24 '23 11:05 Totodore

does the maybe_async crate cut it?

Shorakie avatar May 25 '23 20:05 Shorakie

Yes, it is a good idea, but it implies to also apply maybe_async on Operators and Socket structs to maybe return futures from the adapter.

Totodore avatar May 25 '23 23:05 Totodore

This would be awesome to have! Really enjoy the work you are doing on this

ElijahJohnson5 avatar Feb 18 '24 06:02 ElijahJohnson5

I think there may be scenes that require both async and sync.

headironc avatar Jul 17 '24 03:07 headironc

Sure, the compatibility with previous sync code and the possibility to use both are my main blocking points to move on on this feature. Currently one of the approaches I considered is using Operators to express multi-node async code and keep sync operations on emit/room/ns by default.

socket.emit("test", ()); // default sync behavior that will emit only from this node.
socket.async().emit("test", ()).await; // async behavior shared between nodes.

Other possibilities are:

  • to use feature flags to transform all sync function to async when enabling the async feature on but it would break the default sync feature and features should always be additive for these reasons.
  • To remove sync possibilities on emit/rooms/ns functions and to have everything async by default.

Totodore avatar Jul 17 '24 08:07 Totodore

The PR #395 solves the async adapter issues. However before merging this to the main branch I want to be sure that we have a stable trait for all the adapter implementations.

Therefore the PR #395 will be merged on the feat-adapter-rework branch. And the adapter implementions should be worked on this branch. I would like to have at least 2 implementations (maybe redis and mongo before merging everything to main and making a release).

Currently the Adapter trait is in the socketioxide crate, but I would like to put it in the socketioxide-core crate so that custom adapter implementations only depends on the core crate. Also the implementations should live in this repository in the crates folder.

@torto once PR #395 is merged, would you still like to work on a Mongo adapter (See issue #361)?. I will personnally try to work on a Redis adapter.

Totodore avatar Nov 05 '24 17:11 Totodore

Hello @Totodore I can work on that adpter for sure, I will start today have a look.

torto avatar Nov 19 '24 08:11 torto