10
$\begingroup$

I was wondering what kind of front end is used for trading applications. Coming from a quant background, I was always only concerned with research and back end of the application but am at a total loss when it comes to front end/ gui. Most of my coding has been done in c++ and I am using just a config file to pass parameters.

Now it turns out due to regulatory reasons, this might not suffice. I need to have a front end which can start/ stop the strategy, change parameters and fetch order and trade history. So question boils down to this, How can I create a simple ui which can sit on another machine, communicate with the colocated machine and do all this.

Initially I thought of using web/javascript but not much is out there regarding this. Qt is another option but I suspect it will require substantial rewrite of the code and learning.

What is the preferred front end for medium to high frequency trading applications which have the core strategy running in c++?

Improve this question
$\endgroup$
1
  • 1
    $\begingroup$ Just curious. What regulatory change is motivating this? $\endgroup$
    – David Addison
    Commented Oct 10, 2018 at 22:20

5 Answers 5

Reset to default
7
+50
$\begingroup$

If I was in your position I would start to research how I can create a web server is C++ and expose calls to create a REST service. In other words, can you make your code status output to HTTP?

From there, the rest should be easy. You would just need to create a GUI that can access REST services, which virtually all modern languages can. You could focus on something like AngularJS. It consumes services quite easily and also lets you display them quickly. If you combine Angular with a template from Themeforest (as someone else suggested) you could have a very nice GUI in no time.

You sound like a busy person. If you can do the first part of creating the REST service, then a good developer should be able to help you with the secon

Improve this answer
$\endgroup$
2
  • $\begingroup$ thanks, I am currently going this way only. currently testing with html to see if everything works. this is fast and efficient definitely. $\endgroup$
    – nxshar2
    Commented Sep 4, 2014 at 4:39
  • $\begingroup$ @NaveenSharma Best of luck. I'm glad you're going down this road. The answers with c# suggestions (or any other new language) are ultimately misguided for what you need. You should definitely be able to do what you need with minimal new C++ code - introducing a new language is not the answer here. $\endgroup$
    – Unknown Coder
    Commented Sep 5, 2014 at 15:08
3
$\begingroup$

If your goal is to just send basic commands, and avoid rewriting you models, I suggest you to create a PID server in combination with a web/JavaScript site as GUI.

The PID server monitors the PID’s of the strategies running on the server and executes the commands as they come. The server could consist of a webserver listening on port 8888 with a simple JSON interface, to make it super flexible.

Get a nice ‘Admin Panel’ on http://themeforest.net, and you are all set!

Good practices regarding security:

  1. Only allow JSON posts to the PID server from the webservers IP.
  2. Use validation of the incoming commands, so the PID server cannot be used to take over the strategy server.
  3. Encrypt the commands being send back and forth.

Getting up to speed

It's a really simple implementation, basically just a webserver that feeds your models the desired commands through the CMD.

C# Process class

C# webserver example

Be aware! I found the two links just now, and I do not guarantee the quality of code in the webserver.

Improve this answer
$\endgroup$
8
  • $\begingroup$ I am clueless on PID servers. can you point to any links for the same on how to go about setting one up for c++? $\endgroup$
    – nxshar2
    Commented Aug 28, 2014 at 19:44
  • $\begingroup$ Updated the answer with the 'Getting up to speed' part. $\endgroup$
    – chjortlund
    Commented Aug 28, 2014 at 20:01
  • $\begingroup$ these both are c# links. can these be used in c++/ g++ as well? excuse my ignorance as have not coded in c# for >8 years $\endgroup$
    – nxshar2
    Commented Aug 28, 2014 at 20:13
  • $\begingroup$ No, But I suggest you create a new application that acts as the middle man between the webinterface and your current C++ models/applications. You can make the PID server in any language you prefer, as long as it can be executed on the server. $\endgroup$
    – chjortlund
    Commented Aug 28, 2014 at 20:15
  • $\begingroup$ Can you recommend a more thorough reference on the subject (preferably starting from the basics and working up)? $\endgroup$
    – John
    Commented Aug 28, 2014 at 21:45
3
$\begingroup$

I am currently developing a position keeping system and I am very satisfied with my choice of language/libraries:

1) Pure GUI in C#. C# is very pretty language, and Visual Studio Express is a very good free IDE, where you can spawn all the buttons, lists and inputs you need. .NET is otherwise very versatile library for other stuff (built-in data structures, web requests, unzip, app.config, etc.). You can link C++ libraries to C#.

2) For fast grid-like data display I use http://www.codeproject.com/Articles/20672/Real-Time-Data-Grid . It works well and haven't notice any performance problems for hundreds of simultaneously displaying cells.

3) As an alternative end-user interface, I use RTD feed to excel (see http://weblogs.asp.net/kennykerr/Rtd3). This allows users to link the program realtime data to excel and do their own custom calculations.

4) For network communication (either client-server or within one machine between different processes), I use ZeroMQ (http://zeromq.org). It protects you from the nasty low-level socket stuff and is implemented on many platforms/languages, so you can tie many different programs together under common interface. Some tutorial for C# can be found here: http://www.codeproject.com/Articles/488207/ZeroMQ-via-Csharp-Introduction

So far the only downside of this choice is, that the default Win32 buttons/components are not exactly too pretty, so if you need something good looking, you must pay for that. But that is not my issue :) There is an option to develop GUI in WPF, but so far I am afraid to do so, since I only get negative references on that (it is supposedly too slow).

Improve this answer
$\endgroup$
2
$\begingroup$

Have you considered socket programming? if you need 'real time' control http://www.codeproject.com/Articles/586000/Networking-and-Socket-programming-tutorial-in-C

If you only want to reset the parameter periodically(like end of the day), you can setup a service and communicate via http/rest/soap.

"fetch order and trade history" should be done in a separate app from your live trading component in my opinion.

also i think you will get more responses if you post this to stackoverflow.com

Improve this answer
$\endgroup$
1
  • 3
    $\begingroup$ Hi Xin, welcome to quant.SE! Thank you for your contribution and please don't encourage cross posting. The question as is fits fine here and isn't an actual programming problem so to be honest I doubt it's really on-topic on SO. $\endgroup$
    – Bob Jansen ♦
    Commented Aug 28, 2014 at 9:19
2
$\begingroup$

I was also interested in the same question, and decide to share my project and research so far.

I built a Futures Trading back tester in python, which eventually will support live/paper trading. Here's rough sketch of the design:

--------------        --------------       ------------
| MarketData | --->   | Backtester |  -->  | Results  |
| (MongoDB)  |        | (Engine)   |       | (MongoDb |
--------------        --------------       ------------
                            ^
                            |
                      ---------------
                      | Algoritms   | 
                      ---------------

The market data is drip-fed into the Backtester's engine, which processes it against the input algorithms to decide if it wants to take a trade. All the results (i.e. trade log, trade statistics, etc...) are output back into the MongoDB.

Front End Requirements

Next, my goal is to build a front end. I want the front end to allow a user to setup backtests. i.e. Input parameters for the backtest such as start/end time, algorithm, starting cash, etc.., buttons to start/stop/halt trading, etc... Once the backtest starts, I want the user to see the backtest trading happen real-time on the charts. They should be able to setup multiple charts, i.e. 5-min candlesticks, 1hr, daily, etc... I also want to the stats to update live as the backtest runs, including an equity curve chart. Quantopian has something similar (see quantopian.com) although I want to build this ground up for various reasons.

Front End / Client-side Frameworks

It seems to me that a front-end framework, such as AngularJS or ReactJS, would be useful here to allow for an interactive experience that I'm trying to create. I'm leaning towards ReactJS mostly because I found this awesome stock charts project: http://rrag.github.io/react-stockcharts/.

There's other projects such as Plotly's Dash (which is built on top of ReactJS, Plotly.js, and D3). But I'm finding that Plotly's charts are a bit rigid, i.e. y-axis doesn't adjust on a chart as you zoom, and don't support all of the same out-of-box chart features as does react-stockcharts. There's also Plotly's Dash. Although I'm finding it difficult to integrate Dash into an existing Web App (see some of the discussion in their forums on this topic). But Dash does allow you do have live (interval) updates to the charts. Its fairly new, so it has potential in the future. But I'm leaning towards ReactJS and react-stockcharts.

I also considered going with Grafana, which is an out-of-the-box front end mainly for monitoring and alerting applications (think IT admin wants to monitor CPU, Mem, etc.., for several servers in their lab). They have a limited support for a few input data sources, i.e. InfluxDB, MySQL, Elasticsearch, Graphite, etc... It seems like InfluxDB is a preferred database to use, probably because I think its developed by the same people that built Grafana (they deliver these into a complete solution called InfluxData). There are other plug-ins for MongoDB, candlestick charting, and plotly. But it feels difficult trying to integrate and use all of these plugins to get the same experience as react-stockcharts. And in the end, this application doesn't feel right for a stock charting or backtesting web app.

Service-side Frameworks

I'm still not completely certain if I need a service-side framework. Although I'm considering to use Node.js. Node.js apparently also acts as a Web Server. But what attracts me to Node.js is the fact that it support async jobs. So when the user submits backtest jobs, these jobs can be submitted via Node.js into the backend (MongoDB). And likewise, it can wait and feed back the trade results to the client. It doesn't connect/disconnect frequently like traditional Web Server HTTP requests. The connection stays active and does work asynchronously. (I'm a newbie to all of this, so anyone can correct me if I'm wrong about any of this).

Flask is also worth checking out. Since my backend is python, it might be easier to integrate and even eliminate having to go through a database.

Lastly, I found there's these free open source web stacks.

1. MEAN (MongoDB, ExpressJS, AngularJS, NodeJS)

Here's their website: http://mean.io/

Also, you can get this up and running pretty quick with Docker Compose: https://hub.docker.com/r/meanjs/mean/

2. MERN (MongoDB, ExpressJS, ReactJS, NodeJS)

Here's their website: http://mern.io/

Also, you can get this up and running pretty quick with Docker Compose: https://github.com/Hashnode/mern-starter

And some interesting discussion on Mongo's website about these:

https://www.mongodb.com/blog/post/the-modern-application-stack-part-1-introducing-the-mean-stack

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.