Batch request with websocket transport

[NicolasKritter]

Hi,
I am transitionning from the web3js library to viem.
It seems that batching request only work with the http transport, when I use the websocket transport all requests are sent one by one.

The multicall works but it seems that I can't override the sender address , I have contract execution errors (I am on a private blockchain and don't have access to the aggregate3 smart contract)

I wanted to make sure that batch calling is currently not implemented with the websocket transport or if I am doing it wrong

my current config

publicClient = createPublicClient({
    transport: webSocket(eth_provider_address, {
      reconnect: { attempts: 10, delay: 500 }
    }),
    batch: { multicall: { wait: 0, deployless: true, batchSize: 10000 } }
  });

batch call test :

const batch = await Promise.all(idList.map((e: string) =>
      viemContract.read.getElementMetaData([e], { account: address })
        .then((r: number[]) => this.parseStatusForApp(r)

        )
    ));

The rpc batch requests works with the websocket transport as rpc request accept either one rpc json {id,data...} or a list of rpc json [{id,data...}].
I played a bit with the api of the viem library and managed to do it by building the batch json and sending it directly through the socket from the rpc client, mimicking the current implementation but sending the body directly

a simple example

// build the jspon rpc request list object
const batchOfRequests = idList.map((element, index) => ({
      method: 'eth_call',
      id: index + '-' + Date.now(),
      params: [
        {
          to: this.contract.options.address, from: this.account.address,
          data: encodeFunctionData({
            functionName: method,
            args: [element],
            abi: this.viemContract.abi
          })
        }, 'latest'
      ]
    }));

//getting the raw client to be able to send our request directly throught it
    const transportClient = await publicClient.transport.getRpcClient();
        if (!transportClient.socket.onmessage) {
          transportClient.socket.onmessage = console.log; // just logging to see the result but needs to pass fn with parsing and callback, the messageEvent.data is a json array of all the results
        }
        transportClient.socket.request({ body: batchOfRequests });

I noted that overriding the onmessage does not mess up with other websocket requests made the standard way

viemContract.read.getElementMetaData([e], { account: this.account.address })

it does not open a second websocket connection either which is good, I am just worried about a potential memory leak playing with the onmessage

Is there a more 'viem native' way to do it, it would also be nice if the batching also works automagically like with the http transport so different eth calls could be merged in one batch for efficiency reason

[sueun-dev]

I checked the current docs and source, and there are really 2 different batching paths in viem here.

1. http(..., { batch: true }) is transport level JSON-RPC batching.
   That exists on the HTTP transport.

2. createPublicClient({ batch: { multicall: ... } }) is eth_call aggregation through Multicall3 or deployless multicall.
   That is client level batching, not WebSocket JSON-RPC batching.

So for the transport part, there is no native WebSocket version of http({ batch: true }) today.
The current webSocket() transport sends one request at a time.

There is also one detail in your example that explains why your reads are not being merged.
When you pass account, viem turns that into from on the eth_call.
The automatic multicall path only runs for a plain to + data call.
Once from is present, it falls back to normal single eth_call requests.

So what you are seeing is expected for this shape of call:

viemContract.read.getElementMetaData([e], { account: address })

If you want the viem native route for many reads with a custom sender, I would use publicClient.multicall() directly instead of many contract.read... calls:

const results = await publicClient.multicall({
  account: address,
  contracts: idList.map((id) => ({
    address: contractAddress,
    abi: contractAbi,
    functionName: 'getElementMetaData',
    args: [id],
  })),
  deployless: true,
  allowFailure: false,
})

If your chain has a deployed Multicall3, use multicallAddress instead of deployless.
If your chain does not have Multicall3 and deployless also fails on that private chain, then viem does not currently have a built in WebSocket batch path for this case.
In that case, the supported fallback is HTTP transport with batch: true.

I would also avoid overriding socket.onmessage.
That is below the supported viem client API, and the socket client is built around single request and single response routing.
It can work as a local hack, but I would not rely on it in production.

So short answer:

• WebSocket transport does not have native JSON-RPC batch mode like HTTP.
• batch.multicall is a different feature.
• account disables the automatic multicall merge for your read calls.

[NicolasKritter]

Thanks for the clarification, as we manage our nodes we can enable the http server in parallel of the websocket server on our nodes

As we are transitionning form web3js to viem, I will temporarly use an implementation tweak to enable batch request on websocket, with a more optimized version of the script I provided in my post in oder to minimize the friction during the migration.

For now I don't see any side effect but i understand that overriding the on message is tricky

Is there performance drawbacks for using websocket over http for batch and single request ?
From my understanding the ideal setup is http to send transaction/read and only keep websocket for events and not having a single client

Our workflow is the user loads of list of elements at login (can be thousands) but then only use the events to update the list (+perform basic read/write on smart contract)