FIX Protocol Support for GDAX

[beegmon]

I am wondering if there may be a chance to see the FIX protocol/API supported for GDAX (https://docs.gdax.com/#fix-api), for order management in Tribeca.

Since GDAX doesn't support a websocket API for order management (yet) Tribeca is forced to use HTTP REST calls to do order management. This is fine, but HTTP is heavy and usually incurs TCP setup/teardown time for each new call.

FIX, like websocket, sets up a single persistent TCP connection and streams messages over it. This can provide a big bump in speed and reduction in latency for order actions being sent to the exchange.

Additionally, the FIX endpoint on GDAX provides higher req/s limits which would be beneficial and I am also willing to bet that the FIX endpoint provided by GDAX has far less contention on it than the HTTP endpoints it makes available.

I would gladly donate toward getting FIX in place for GDAX as I don't have to time currently to contribute with code, but I wanted to know if there was even interest in doing so.

Thanks!

[ctubio]

i can try for sure xD we are already using websockets for market data, but we are still using http calls for open/cancel orders; maybe we can migrate all to FIX API? (so we dont have 2 connections opened)

since need to rewrite (only 2 files but) 1259 lines, it may take a few days to begin (and another few days to finnish [and another few days to correctly finnish])

[beegmon]

For GDAX, you can't get market data or position information (on the USD/EUR side) from FIX. You can only do order management (new order, cancel order, order status). So if you add FIX, 3 connections will be needed most likely:

1) HTTP -- USD/EUR Wallet Amount and BTC Wallet Amount

2) Websocket -- Market Data

3) FIX -- Order Actions/Order Information and Status (Open, Close, Status, Cancel) -- You will need to track the Order Status of each order to give you USD/EUR Held or BTC Held, instead of depending on the HTTP call for the wallets as it will likely significantly lag behind FIX. Or you could just use the HTTP call for wallet/held position information and accept the lag (but quoting/tdp is based on this value so it should be as up-to-date as possible I would guess)

Other exchanges might support more options through FIX, but many of them also must support a full websocket API for everything like okcoin and bitfinex so its kind of moot for them. However, using different protocols/connections for different things is kind of a plus.

First is gives you separation of concerns, as one connection is a single point of failure. If the HTTP and Websocket sides goes down, but the FIX side is up, you can still cancel orders while you are blind for example.

Second, it allows more efficient use of req/s limits. If all API calls are made over one type of connection, you can quickly hit the limits. However, by spreading them out across connections/different protocols, with different req/s limits, you can more efficiently use the limits to do valuable work...if that makes sense.

The downside is having to manage 3 connections for different types of requests, but the upside is that you can use the best connection/protocol for the type action needed. For order actions on GDAX, FIX makes them as fast and lightweight as possible. Which is what we want for a bot that deals in milliseconds of time I would think.

I would happy to put my BTC/time toward testing and finding bugs in a FIX implementation.

[ctubio]

ok so coOl, no need to modify the whole gdax integration:

• wallet position: already done with 1 http call and already calculated on the fly based on orders status from websocket, see https://github.com/ctubio/tribeca/blob/master/src/server/broker.ts#L516 )
• order events, market trades and market levels: already done with websocket (we know the changes of our orders because of the orderIds in all market events)
• order actions: (buy/sell/cancel) 3 http calls susceptible to be migrated to FIX API

hope this is what you mean too'¡ (so we are in the same page xD)

[beegmon]

That sounds like a reasonable approach.

Getting the order status from FIX directly for each order won't likely be much better/faster than seeing it come over websocket anyways and means less rewriting of stuff, less work for Tribeca to do.

[beegmon]

Looking further at FIX (on GDAX atleast) moving order actions to FIX will definitely help in terms of request limits. Right now, with the authenticated HTTP endpoints, you get a baseline request limit of 5 requests per second bursting up to 10.

With FIX you get 30 request per second, per action type (from the API docs):

FINANCIAL INFORMATION EXCHANGE API The FIX API throttles each command type (eg.: NewOrderSingle, OrderCancelRequest) to 30 commands per second.

That is a 6X increase in command limit per action type compared to the HTTP baseline, or about 12X overall (buy/sell, cancel actions) in round numbers. That is a Significant improvement there.

This is especially useful when running multiple instances of Triebca pointing a different markets in GDAX, since it is very easy to eat through the HTTP baseline + burst limit when running in the BTC + ETH + LTC markets at the same time (Since they all use the same HTTP endpoints for order actions).

I also found this which is an example FIX implementation for GDAX in js. It's old and the API I think has changed a little since this post but its a good start I suppose. -- https://community.coinbase.com/t/sample-fix-connection-to-coinbase-exchange-in-nodejs/7836

[ctubio]

ty for the link'¡

ima leave the old lib here https://github.com/coinbase/gdax-node

[ctubio]

:sunflower: TX received, thanks'¡ on my way

[beegmon]

Very much Excited for this improvement!

[ctubio]

will try with https://github.com/electronifie/node-quickfix but the installation seems not a single step (for now)

also will try https://github.com/defunctzombie/fixjs

[beegmon]

A messy setup ( for now as it can be scripted fairly easily) I think is a good trade off for something like node-quickfix since it uses faster libs when compared to the pure JS implementation.

[ctubio]

seems like quickfix installs easy without so many pain, lets try it'0'¡!

[ctubio]

i dont wanna start crying of happines yet, but we are 1 parameter away from a successfuly FIX communication

[beegmon]

Should be back in the saddle here this coming week to test all the new changes. Thanks for all the hard work!

[maurodelazeri]

@ctubio you da best!!!!

[ctubio]

that was a big update :dancer:

@maurodelazeri :rage4: i will tell to my mum!