Async API on hypercore about hypercore HOT 6 CLOSED

How to maintain both a async and sync API?

I would recommend only maintaining an async API, and making the switch throughout.

We would require all consumers to also use an async executor if we don't expose both APIs.

That's accurate; within Rust itself that should be no problem (when using async-std). But for integration with other languages I'm not necessarily sure how that would work.

Is it ok to add async_trait as a dependency?

I'd say so; the only downside of this is some extra boxing, compile times, and weird type signatures in docs. But overall it makes life significantly better, so I'd def recommend using it.

from hypercore.

I'd probably migrate it as well.

from hypercore.

@yoshuawuyts thanks for the inputs. Would you also migrate random-access-storage completely to be async, or would you suggest to use the blanket implementation route?

from hypercore.

There is now a draft PR using async/await on APIs that hit storage: #103

It's built on top of many other PRs tho, so it might take a while to be reviewed and land.

from hypercore.

@Frando Are you ok if we land PR to close some PRs?

We could release it as a RC version, and them try to investigate blocking or smol to abstract over the async executors in future releases.

from hypercore.

Landed on the beta versions

from hypercore.