A Word from our Summer Interns: Taking on TRex
WHY TREX?
Belvedere Trading currently trades at more than ten different exchanges, which requires testing our proprietary trading software in multiple contexts. A common way to simulate Belvedere’s algorithms is through an exchange simulator, in which a mock exchange is constructed to handle and process incoming orders. To improve upon Belvedere’s testing capability, this year’s intern class developed the Trading Exchange Simulator, known internally as "TRex."
Developing TRex in house enabled the technology to be tailored to the needs of the end user, the Quality Assurance Analysts (QAs), here at Belvedere Trading. Our goal for the summer was to create a simulator for the CME that could be extensible to other exchange protocols.
PROJECT BREAKDOWN
At the beginning of the project, the intern team spent significant time developing the project initiative. After meeting with the Product Owners and Stakeholders, we groomed requirements and decided that the project’s technical development should be broken down into three components: User Interface (UI), Backend, and Regression Testing.
The UI team used a combination of the Python Flask microframework and React.js to build the simulator console. The UI design emulates that of Belvedere’s current exchange simulator, but it is better tailored to a QA’s needs. The basic functionality features a dynamic order book display, with the ability to filter and sort between orders. Additionally, the interface supports an array of mass-market and selective actions that the user can employ within the simulation.
React.js was important to UI development because it enabled reusable components across the interface. We used Flask and RESTful API to store data in the Python backend that interacts with the C++ server. Flask served this purpose nicely because it exposed certain aspects of the orderbook to the UI, which React could then retrieve and display.
The Backend team developed TRex in C and C++. The Backend simulates the entire exchange, from TCP and FIX message parsing to active order book maintenance. The C++ server sends and receives messages from gateways (to which we connect our client software), and it updates the web server with any relevant changes.
The Regression Testing team developed Behave tests prior to transitioning into the UI and Backend teams respectively. This enabled us to independently test TRex by mocking calls from the UI and the gateway.
SUCCESSES, ROADBLOCKS, AND BREAKTHROUGHS
Some of the project’s successes included the well-defined requirements and the team’s cohesiveness. By meeting with the Product Owners and pairing up with dedicated Intern Mentors, the team established project milestones and defined how simulator features would interact with current Belvedere software.
Furthermore, integration between the C++ side and the UI went quite smoothly. The team used an RPC framework, which enforced “contracts” to establish what functions each side could remotely call. This made it much easier to test the functionality before integration; in turn, any bugs found were isolated to the RPC calls, rather than the entire project.
Major roadblocks in the project included an initial lack of familiarity with the trading industry and Belvedere’s process methodology. As discussed in a previous blog post on Agile, Belvedere uses Scrumban, a combination of Scrum and Kanban, in its development cycles. While the intern team had to learn Scrumban, the most difficult part of the onboarding process was learning the coding standards. Belvedere has high coding standards, enforced by intense code reviews. At the beginning of the summer, the interns would need multiple rounds of review to reach Belvedere’s standards. However, by the end of the internship, the interns had learned the standards, and reviews were relatively painless.
Further into the project, we faced some technical roadblocks as well. Testing TRex was difficult due to issues with running Behave, especially when running separate simulator components. Since TRex gives the user full control of the mock exchange, the number of edge cases to test naturally increased as well. These included testing to ensure that smaller features reacted properly when a user changed certain settings from the UI.
As our internship came to a close, we deployed a TRex alpha for the QAs to explore and test. Possible new features for the future include the handling of futures spreads and mass quotes. Check back for more updates on the status of TRex as exciting functionalities are continually introduced.
— Belvedere Summer Interns
