Robots are replacing humans in many areas of our lives because they are better at solving certain types of problems. First of all, our reaction speed and the amount of data a trader can process when making investment decisions are finite.
We inevitably find ourselves trapped, bounded by our natural limits. However, the solution that API provides is simple: delegating trading execution tasks to a robot.
Trading API — Application Programming Interface — is one of the critical components of a trading platform. This interface allows different applications to interact with each other.
Trading bots: be quick – or be dead
When trading in several markets simultaneously, one needs to react very quickly, promptly deciding whether to close losses and profits. Therefore, it is possible to program a bot and focus on solving strategic tasks that require analysis instead.
Scalping, for example, allows one to profit from speculation using minimal price changes. Scalpers used to open and close trades within minutes; today, it happens within seconds.
High-frequency trading relies on algorithms and is currently responsible for nearly half of all transactions in U.S. markets. Competing with a machine on logical processing power is almost pointless for a human.
Algorithms cannot decide on their own whether to invest in Bitcoin or Tesla stock, but based on a previously set logic, they can choose the optimal solution instantaneously.
To boost the trading efficiency on our platform, the Digitex team set a goal to make a state-of-the-art trading API.
Below you will find what we have faced so far and what our plans are.
Our API already stands out from the competition
Firstly, Digitex already has a working Websocket trading API based on the Google Protobuf protocol. So every time you interact with the exchange through a web browser, you are using Protobuf – even though you may not be aware.
If you open your browser console and place an order, here is what happens:
CHANGE_LEVERAGE_ALL is an instruction for our Engine to change your leverage on Futures Markets. The Engine will send back a response – for example, confirming that Leverage has been altered or giving the reason why it can’t be changed.
Google Protobuf is a highly effective communication tool since it converts a message to bytecode, the native ‘language’ of computer systems.
Through some more complex tools, including Websocket, our trading API can support up to 1,000 requests per client. However, that would be technically impossible for most exchanges, in part because of their heavyweight JSON objects.
Reading this, one might be thinking: “Cool! How come I never heard about it?” – which is, actually, one of our biggest problems. But, unfortunately, most users do not care for the topic, as only experienced high-frequency traders comprehend it.
We will have documented Trading API
Previous coders at Digitex failed to fully describe the Trading API, messages and methods, besides the resulting interaction.
Fortunately, we have Elena Iakovleva, front-end developer, and Pavel Yushchenko, CTO – who excel at such technology. Together with our new system analyst Nataly Klimochkina, they are creating the existing Websocket API documentation.
To sum up, Google Protobuf is an excellent solution, and after getting familiarized, you’ll love it.
Not a Websocket API fan? Don’t worry!
We know that not every client wishes to learn Websocket API technology. Therefore, we decided to develop a REST API trading solution based on the best market practices.
REST API is the standard communication method between clients and servers. Although slower, it’s enough for those who are not focusing on high-frequency trading.
Last year the previous team created a proxy server between our Websocket and the client to provide traders with REST API, but this creates delays and causes data and orders to be laggy. Our REST API solution will be fully integrated, therefore not facing such issues.
With Google Protobuf, why the need for a REST API?
The answer lies in the future projects at Digitex exchange: native mobile apps for iOS and Android. The back-end of those solutions will require Rest API for data consulting and Websocket API for trading.
To ensure that every new function at Digitex is fully compliant with mobile versions, we now have a dedicated backend developer working side-by-side with our mobile team.
Dedicated team: the key to our success
As you can see, we consider the trading API a top priority. Fulfilling it will bring Digitex exchange one step closer to success, attracting traders with diverse expertise: from those relying on complex trading algorithms to those who seek a well-designed and simple interface.
We allocated significant resources from our backend development team to achieve this goal, besides creating a task force dedicated to the trading API headed by Sergiy Pavlyuk. Sergiy is an experienced python developer with an algorithmic trading background, having previously worked in the financial industry.
We are now ready to test our public REST endpoints and currently working on trading endpoints. The main difficulty is to “seamlessly join” REST API with our matching engine in the backend.
We will provide improved and faster solutions
“Obviously, we will lose some speed compared to Protocol Buffers, but subjectively, I feel we will still be faster in matching orders than our competitors. For the record, I believe trading via REST API will soon become redundant among algorithmic traders at Digitex that use their own algos. Yet, REST is unlikely to die at Digitext since most third-party software uses it for trading. It is also easier to start trading with REST for new traders,” — told Sergiy.
Only a handful of users will use our API directly, as most of them will use either our or third-party client libraries. Our team’s ambition is to create client-side libraries that are easy-to-use and leverage Digitex’s engine capabilities. Those are the functions that we are taking into account:
– ease to prototype and backtest strategies using Jupyter notebooks in Python;
– same function and method calls for REST and Websockets connections, allowing an easy switch between them;
– multiple client-side libraries, starting with Python but later extending to Go, C# and JS.
We have also been discussing some crazy ideas, such as allowing some traders to put their algos right next to our Engine to reduce network latency. Furthermore, building a dockerized solution with pre-built risk and monitoring modules.
“What we do in the end will only depend on our users’ feedback,” — added Sergiy.
Algo traders benefit every other user
Besides the coding needed to improve the Digitex trading API, we are working on the user-end description. We want to make sure that anyone can understand each method and message. Our goal is to improve clients’ trading and operations efficiency and profitability.
Digitex exchange aims to become a knowledge-base and infrastructure reference for algorithmic traders. It’s a win-win for every other client as our overall volume and liquidity improve.
Bye! See you next week with Dev update # 4.