silverback
silverback copied to clipboard
How to run with the WebsocketRunner
Based on the run() code, the runner class is selected automatically if not provided:
def run(cli_ctx, account, runner_class, recorder, max_exceptions, path):
if not runner_class:
# NOTE: Automatically select runner class
if cli_ctx.provider.ws_uri:
runner_class = WebsocketRunner
elif cli_ctx.provider.http_uri:
runner_class = PollingRunner
...
I couldn't find anywhere how to configure the provider so the ws_uri is used.
if the runner class is provided like:
silverback run "main:app" --network ethereum:mainnet:node --runner silverback.runner:WebsocketRunner
I got:
silverback.exceptions.NoWebsocketAvailableError: Attempted to a use WebsocketRunner without a websocket-compatible provider.
Thanks!
We migrated that into ProviderAPI because some providers have both and some don't, do that it was easier to use out of the box. But yes, it is currently not possible to do it with ape-node, we can fix that!
cc @antazoey, maybe we can add a config item to node in core called like has_websocket: true or something (maybe let the user write the websocket address in their config?) so that this works correctly
cc @antazoey, maybe we can add a config item to
nodein core called likehas_websocket: true
What about something like this: https://github.com/ApeWorX/ape/pull/2194?
What about something like this: ApeWorX/ape#2194?
I was trying/expecting something like that. I would suggest having the three parameters, uri and http_url could be use indistinctly:
node:
ethereum:
mainnet:
uri: ~
ws_uri: ~
http_uri: ~
What about something like this: ApeWorX/ape#2194?
I was trying/expecting something like that. I would suggest having the three parameters, uri and http_url could be use indistinctly:
node: ethereum: mainnet: uri: ~ ws_uri: ~ http_uri: ~
what would be the use case of having a separate http_uri from uri?
cc @antazoey, maybe we can add a config item to
nodein core called likehas_websocket: trueWhat about something like this: ApeWorX/ape#2194?
Looks great! Yes, it is good we solve this in core because I eventually want to upstream the whole Iterator[...]/AyncIterator[...] methods into something that a ProviderAPI can generate w/ v1.0, simplifying this downstream integration a lot by removing the need to specify what type of runner is being used (also includes upstreaming my SubscriptionManager to web3py or a web3py middleware/extension, but that's a whole different can of worms)
I was trying/expecting something like that. I would suggest having the three parameters, uri and http_url could be use indistinctly:
I was considering this as well, and either deprecating uri or have uri check the scheme and work for either (in the case you only need 1)
what would be the use case of having a separate
http_urifromuri?
I was just thinking in backward compatibility, people con just use uri, or if need to specify both can go as they like :) Like this:
node:
ethereum:
mainnet:
uri: ~
ws_uri: ~
or like this:
node:
ethereum:
mainnet:
http_uri: ~
ws_uri: ~