-
Notifications
You must be signed in to change notification settings - Fork 206
extract async client abstraction. #580
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
Conversation
maciejhirsz
left a comment
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
TarikGul
left a comment
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 <[email protected]>
Co-authored-by: David <[email protected]>
Co-authored-by: David <[email protected]>
Co-authored-by: David <[email protected]>
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.
| "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
shareableparts of thews clientto anasync client abstration.I have called it
core-clientand it's not used byHTTPbecause it can't be extracted to asendingandreceivingend.That's we have two different transport traits for a
senderandreceiversuch 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
jsonrpseeI have tested it in
subxt hereThe benefit that it would be easy to add other transports such as
IPC,web-sysand so on...