Use Bitmex for price feed

[bonomat]

I recommend using Bitmex API feed. Our "usual" source (kraken) does not offer CFDs.

---

I played around with this library which works nicely: https://github.com/dovahcrow/bitmex-rs/
unfortunately it hasn't been released for a while but the latest master works great.

It comes with ws subscription. This gives you the latest rates

let mut client = BitMEXWebsocket::new().await?;

client
    .send(Command::Subscribe(vec![
        Topic::QuoteBin1m(Some("XBTUSD".to_string())),
    ]))
    .await?;

while let Some(msg) = client.next().await {
println!("{:?}", msg);
    }

[thomaseizinger]

How complicated would it be to use the API ourselves using just a websocket lib like tungstenite? Unless the library offers us functionality like auto-reconnect, I'd hesitate to pull in more dependencies for this. Will likely just make it harder to implement the reconnect functionality we had to build for the kraken websocket.

[bonomat]

How complicated would it be to use the API ourselves using just a websocket lib like tungstenite?

I don't know - didn't try to implement it myself :) Bitmex says The BitMEX API conforms to the Swagger spec for REST endpoints. Any Swagger-compatible client can connect to the BitMEX API and execute commands. So I guess it wouldn't be too hard to implement ourselves.
bitmex-rs uses tokio_tungstenite under the hood for ws (not sure about reconnection functionality). I guess we can just orientate ourselves on it.

Own opinion: After working with it for a day I'm quite happy with it. It offers authenticated and non-authenticated connection for rest and ws api and has all the return types.
What's annoying is that it uses fehler and failure for error handling which I didn't warm up to yet. Besides that, no issues (so far) :)

[thomaseizinger]

What's annoying is that it uses fehler and failure for error handling which I didn't warm up to yet. Besides that, no issues (so far) :)

Oh god. That makes me think it is not very well-maintained :/
failure was an early iteration of what is now the std-lib Error trait but they are incompatible with each other. Most crates have moved on and just utilize the std-lib Error trait.

bitmex-rs uses tokio_tungstenite under the hood for ws (not sure about reconnection functionality). I guess we can just orientate ourselves on it.

Sounds good! Scanning through their Cargo.toml, I can see a few things that I'd like to avoid:

• fehler and failure being two of them
• chrono is a rather heavy and outdated time library. I'd much rather use time 0.3 instead if we need more advanced date-time functionality.
• derive_builder will trade compile-time for convenience. Not an amazing choice for a library.
• Not sure if we need serde_urlencoded and serde_qs for the parts of the API that we want to talk to.

For the price feed, the websocket API should be good enough yeah? Copying / re-implementing the parts that we need sounds better to me. Gives us flexibility to easily implement re-connecting in case Bitmex's API turns out to disconnect at times, similar to the Kraken one and it keeps our dependency graph reasonably lean.

[da-kami]

I don't see any hard blockers in that list, so I think we could just use the existing bitmex-rs library and potentially re-implement parts we need once it becomes a pain.
For the MVP I feel it would be good enough to just use.

[thomaseizinger]

Even if we assume they are not hard blockers (I disagree on the ergonomic hit of bad error handling), then adding a dependency should always offer significant advantage and not just "not have any downsides".

Unless I've missed something, bitmex-rs basically combines tokio_tungstenite with some data structures. If that is the only value proposition, then we might as well depend on tokio_tungstenite ourselves and copy the data structures.

That brings ergonomic error handling and with copying the data structures, most of the effort that goes in writing an API client is also covered.