ApeWorX / silverback

Blockchain automation library, and SDK for the (upcoming) Silverback Platform
https://apeworx.io/silverback
Apache License 2.0
80 stars 9 forks source link

How to run with the WebsocketRunner #100

Open elier opened 1 month ago

elier commented 1 month ago

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!

linear[bot] commented 1 month ago

SBK-493 How to run with the WebsocketRunner

fubuloubu commented 1 month ago

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

antazoey commented 1 month ago

cc @antazoey, maybe we can add a config item to node in core called like has_websocket: true

What about something like this: https://github.com/ApeWorX/ape/pull/2194?

elier commented 1 month ago

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: ~
fubuloubu commented 1 month ago

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?

fubuloubu commented 1 month ago

cc @antazoey, maybe we can add a config item to node in core called like has_websocket: true

What 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)

antazoey commented 1 month ago

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)

elier commented 1 month ago

what would be the use case of having a separate http_uri from uri?

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: ~