tiagosiebler / binance

Node.js & JavaScript SDK for Binance REST APIs & WebSockets, with TypeScript & browser support, integration tests, beautification & more.
https://www.npmjs.com/package/binance
MIT License
776 stars 266 forks source link

It there a way to get first result message? #461

Closed Simon1093 closed 1 month ago

Simon1093 commented 1 month ago

I was wondering if there is a way to get response message when I subscribe to the stream?

According to https://binance-docs.github.io/apidocs/spot/en/#websocket-market-streams "In the response, if the result received is null this means the request sent was a success": {"result":null,"id":1}

But I couldn't find the right event to get this first response message. I was trying to use

  wsClient.on('reply', (data) => {
        console.log('binance response', data);
  });

But it didn't help.

tiagosiebler commented 1 month ago

When you request subscription to a topic, the WebsocketClient of my binance SDK is actually opening one websocket connection per topic. I made the WS client before binance had the capability of subscribing to topics after opening a connection (which is how my other SDKs work). At some point I will make an upgraded WS client that'll work the modern way, in line with my other SDKs, although the current design has also been extremely stable for me so it's not a concern either.

For your use case in wanting to know exactly when a topic is "ready", given how the WS client works, you can simply listen to the open event. For public topics, while connecting, the WS url being used already includes the requested topics + params in the URL. For the user data stream, the URL includes your listen key. So once the connection is open it's immediately ready.

There's an example using this as a trigger for starting backfills once a specific connection opened (ensuring new candles are coming in before we backfill for continuity in case it takes longer than expected to open): https://github.com/tiagosiebler/binance/blob/master/examples/tracking-candles.ts#L298-L299

I also recommend consuming the reconnecting (something is wrong and the connection will be replaced in a moment) as well as the reconnected (successfully replaced a dead connection with a new one) events. The latter is a good place to run any sync logic for events you may have missed, such as synchronising balances/positions/orders via the REST API: https://github.com/tiagosiebler/binance/blob/master/examples/ws-userdata.ts#L109-L122

In a mid-to-high-freq system, you may want to pause or queue orders while the reconnection is in progress, if you're using the websocket for confirmations/updates.

tiagosiebler commented 1 month ago

Closing this for now, but feel free to reopen / open new issues as needed