Planning the first trading bot on DOM

Hello everybody,
i would like to know few suggestions about planning my first trading bot on ES.
Right now I only wrote few strategy with pine script on Tradingview, but on the Dom I think is completely another thing.

First of all I would like to know if with this API I can receive DOM data as market orders, limit orders (add and pull for at least 10 levels). If yes, that great, then … the plan starts.

I am trying to get knowledge and so far I arrived at the point where I divide the project into this two macro area: Backtesting and Execution. I do not care about portfolio management because I will trade only on ES with a max loss per day.

Backtesting:
In your experience which is the best way to backtest a Dom strategy? I mean with candles is quite easy, but with the level 2 I think I have to setup a backtesting environment. Is there something ready I can use?
I think for this stage I need a tick per tick data, so I do not have to worry about latency, internet and other performance considerations. More than that because here there is no performance issue I can use different language, like python or node js.

Execution:
For dom trading bot I read around and I see that most of the people suggest C++. Usually to work with dataframe I use python (i see also node has some library but never tested) so I am wondering if using python or node can really affect my performance considering that the strategy that I have in mind goes for 3, 4 tick at a time.

As you can see I am really at the beginning of this new journey and every suggestion will be very appreciated! Thanks again.

Hi @Somtam,

First of all, yes you can receive DOM updates via API using a WebSocket and the md/subscribedom WebSocket operation. There are details for setting up your WebSocket here. You’ll want to connect your WebSocket to the market data URL: 'wss://md.tradovateapi.com/v1/websocket'. There are specific details about retrieving DOM data here. You can request fine grain tick data as well using the md/getchart operation, which is also retrieved through the Market Data WebSocket API.

I’m not sure if you’ll be able to differentiate between the order types however. Our DOM data is structured like this:

{
  "e":"md",
  "d": {
    "doms": [ // "doms" may contain multiple DOM objects
      {
        "contractId":123456, // ID of the DOM contract
        "timestamp":"2017-04-13T11:33:57.488Z",
        "bids": [ // Actual depth of "bids" may vary depending on available data
          {"price":2335.25,"size":33},
          ...
          {"price":2333,"size":758}
        ],
        "offers": [ // Actual depth of "offers" may vary depending on available data
          {"price":2335.5,"size":255},
          ...
          {"price":2337.75,"size":466}
        ]
      }
    ]
  }
}

For Backtesting, that same DOM data can be accessed historically (along with other data like user session data, or chart data) by using a Market Replay socket. The goal of the Market Replay socket is to replay a period of time chosen by the subscriber as if it were happening in real time (or up to 400% of real time). The trick to using the replay socket is to treat it as if it were both a Market Data socket and a real-time user data socket. I wrote a bit about the differences and how you could set up your sockets in this post.

For Execution, I’ve encountered people developing software using the API in a variety of languages, Python and NodeJS are both quite common. We have a pretty detailed JavaScript guide that hits all the major points of the API using browser based JS. You can convert most of that knowledge to the Node platform as well so long as you use the ws NPM package - its the same interface as the browser based WebSockets. There are Python based WebSocket implementations out there as well.

You can receive DOM quotes, however many levels are available. Source: Tradovate API

Backtesting:
To backtest, you simulate a DOM using either fabricated data or historical data only taking into account the instant quotes and not looking at an x,y plot like you do for charts. The research you do would be translated to code and the code would perform calculations on incoming data.

Execution:
You can use any language you want to connect to the websocket. Python, Javascript, C# are common options. C++ isn’t really necessary unless you’re trying to squeeze out microseconds. But if you really want to go with C++, there is a websocket library to connect to the Tradovate API with: GitHub - zaphoyd/websocketpp: C++ websocket client/server library

1 Like

Thanks very much to you all,
I really appreciate your time.

This is a good starting point for me.
Thanks again!