Locally runnable server with built-in data caching, providing both tick-level historical and consolidated real-time cryptocurrency market data via HTTP and WebSocket APIs
Binance Futures has a limit of 200 streams per websocket connection according to their documentation. When using Tardis to listen to the ws-stream-normalized for trades for more than 200 symbols I receive the following error in the logs (debug mode enabled):
This is easy enough to work around on my side as I can chunk the requests up into smaller requests containing at most 200 symbols when the exchange is binance-futures, but it might be a nice addition to Tardis if it would handle this transparently for its users? As otherwise I need to go and look up these limits for each exchange, which sort of ruins the clean uniform abstraction you've built on top of all of the exchange native differences. For instance the Binance spot websocket will allow up to 1024 streams per connection, so it's not even consistent across different Binance exchange APIs.
There doesn't appear to be any downside to centralising this functionality as I think this workaround would be the same in all situations that I can think of right now.
Binance Futures has a limit of 200 streams per websocket connection according to their documentation. When using Tardis to listen to the
ws-stream-normalized
for trades for more than 200 symbols I receive the following error in the logs (debug mode enabled):This is easy enough to work around on my side as I can chunk the requests up into smaller requests containing at most 200 symbols when the exchange is
binance-futures
, but it might be a nice addition to Tardis if it would handle this transparently for its users? As otherwise I need to go and look up these limits for each exchange, which sort of ruins the clean uniform abstraction you've built on top of all of the exchange native differences. For instance the Binance spot websocket will allow up to 1024 streams per connection, so it's not even consistent across different Binance exchange APIs.There doesn't appear to be any downside to centralising this functionality as I think this workaround would be the same in all situations that I can think of right now.