-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
extract async client abstraction. #580
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, one question.
client/ws-client/src/lib.rs
Outdated
/// | ||
/// You can also prevent the subscription being dropped by calling | ||
/// [`Subscription::next()`](crate::types::Subscription) frequently enough such that the buffer capacity doesn't | ||
/// exceeds. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// exceeds. | |
/// exceed its limit. |
Im a little confused by frequently enough
. Does this mean a user should monitor the subscriptions and as it starts to get close to exceeding its capacity to call [Subscription::next()]
, therefore the implementation on what frequently
is, is based on the user?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's poorly phrased but it means that if the server produces items much faster than you would call Subscription::next()
that might end up with the filling buffer and once it exceeds the configured max_limit
that subscription is simply dropped...
In that scenario you need to either call/poll Subscription::next
more often or increase the buffer max limit, k?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, okay yea that totally makes sense.
more often or increase the buffer max limit
This is what i assumed, just needed some clarification :). Thanks for the explanation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Co-authored-by: David <dvdplm@gmail.com>
Co-authored-by: David <dvdplm@gmail.com>
Co-authored-by: David <dvdplm@gmail.com>
Co-authored-by: David <dvdplm@gmail.com>
The `async-client` is hidden behind a new feature flag `async-client` because it brings in additional dependecies such as tokio rt.
/// | ||
/// ``` | ||
#[derive(Clone, Debug)] | ||
pub struct WsClientBuilder<'a> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this crate could be removed but I kept for it may be easier to use than to use the core client and plug in the actual transport.
@@ -37,6 +37,14 @@ server = [ | |||
"tokio", | |||
] | |||
client = ["futures-util"] | |||
async-client = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to introduce a feature to avoid bring in tokio
and some other deps for http
let addr = run_server().await?; | ||
let uri: Uri = format!("ws://{}", addr).parse()?; | ||
|
||
let client: Client = WsTransportClientBuilder::default().build(uri).await?.into(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
example, do we want this?
@maciejhirsz @dvdplm @TarikGul can take you a quick look on this again after some changes? |
Let's have a round of reviews for this too, it extracts the
shareable
parts of thews client
to anasync client abstration
.I have called it
core-client
and it's not used byHTTP
because it can't be extracted to asending
andreceiving
end.That's we have two different transport traits for a
sender
andreceiver
such that they can be used in different tasks.We can bikeshed on the naming....
Remaining is to expose the client transports from the wrapper crate
jsonrpsee
I have tested it in
subxt here
The benefit that it would be easy to add other transports such as
IPC
,web-sys
and so on...