IBKR_API Architecture¶
The IBKR_API is NOT some wrapper on top of the existing twsapi python API, but rather a complete redesign of the codebase. The new codebase was written with the following ideas in mind. One, a ‘design by contract’ approach was used, where each portion of the system has clearly defined responsibilities. For the most part these responsibilities are explicitly listed in their respective docstrings. The other governing principle was to keep the code ‘DRY’ and to avoid ‘speculative generality’. The codebase you see is the result of this philosophy.
Directory Structure¶
The table below describes various important directories within this API and their intended purpose
| Directory | Description |
|---|---|
| base | The core application internals. Unless you are developing the API this code this code won’t be called directly |
| classes/contracts | Various types of Contract objects such as Stock, Option, Put, Call, etc |
| classes/enum | Various Enum and IntEnum classes that hold all legal values for whatever specific parameter they represent |
| classes/orders | Objects that represent various types of orders that can be placed such as Limit , Discretionary, etc |
| classes/stocks | Dow 30, S&P 500, etc (should/will probably be renamed to indexes…) |
| api.py | IBKR_API interface. Use this if you are looking for a simple synchronized interface |
| client_application.py | ClientApplication Interface. Use this if you are looking for a standard asynchronous event driven approach |
Interfaces¶
There are three primary interfaces to use. For basic usage the IBKR_API class is your best bet. This class hides the complexity of the underlying asynchronous interface provided by the application Bridge (TWS or the IB Gateway) and gives you a straight forward way to query data.
For those users looking to implement real time algorithmic trading systems the ClientApplication class is the right place to start. This class provides an interface similar to what is provided by the official API, minus the artificial complexity.
RabbitMQ¶
Two exchanges are being used trading desk for messages bound for the trading desk. actor for messages bound for the various actors.
Message Exchanges¶
Routing key: <message_type>.<Actor.code>
+==============+====================+=================================================================+ | Exchange | Queue Message Type | Meaning | +==============+====================+=================================================================+ | trading_desk | bridge | (API) Requests from Actors for the bridge application | +————–+——————–+—————————————————————–+ | trading_desk | multi_client | Responses from prior request | +————–+——————–+—————————————————————–+ | actor | bridge | Request for the MultiClientApplication to deliver to the bridge | +————–+——————–+—————————————————————–+ | actor | multi_client | Request from the MultiClientApplication | +————–+——————–+—————————————————————–+