Closed iskandersierra closed 4 months ago
@iskandersierra We welcome PRs and submissions. I can't guarantee acceptance, but this would just be adding functionality, so we'll see. One thing to consider is that this client is based on older .NET and is not really fully async all the way through to the socket layer. I'm definitely interested in what you might come up with.
Maybe consider making a IKeyValueAsync interface as a parallel to IKeyValue?
Thanks!
Hi @scottf . I'll try my best to dig a bit around. For now I just want to familiarize myself with the internals, and at least add the async
variants of the current APIs. I think that having IKeyValueAsync
and IObjectStoreAsync
is better than duplicating the API surface of the existing classes, so I'll go with that idea.
For the moment I will not touch the socket access layer. I'm just adding new APIs to make the less amount of noise
I'll publish a draft PR as soon as I have any noticeable advances.
I published the draft here #730
Closed as will not be completed. This can be done manually. Also try https://github.com/nats-io/nats.net.v2
Feature Request
Add Async versions for all JetStream/KeyValue/ObjectStore APIs
Use Case: When using NATS JetStream API from async client code
Proposed Change:
async
variant for methodJetStreamBase.RequestResponseRequired
usingIConnection.RequestAsync
methodasync
variants for methods onJetStreamManagement
async
variant for methodKeyValue._write
usingJetStream.PublishAsync
async
variants for methodsGet
,Put
,Create
,Update
, ... onKeyValue
andKeyValueManagement
ObjectStore
Who Benefits From The Change(s)?
Every developer using an
async
framework and the standard .net Task Pool, where they will avoid locking pooled threads for IO operations involving NATS, enhancing general throughput.Alternative Approaches
Haven't thought of an alternative that does not lock pooled threads.
I propose myself for creating the PR for this issue, in case this effort cannot be developed by the current contributors.