Is it possible to communicate with Lean via REST API if the both strategy and Lean are run locally?

Hi Siarhei,

QuantConnect has an API with which Lean integrates. You can submit backtests via the API, but you are using the API to upload C#/F#/python source code to the cloud to be compiled and then executed. You don't use the API to communicate with Lean, you use the API to run Lean and your code in the cloud.

Here is some documentation on the API: https://www.quantconnect.com/lean/docs#topic2195.html

Hi Andrew,

Thank you for your reply. Could you please let me know if Lean can be run locally on local data? I was under impression that it is possible.

Thank you for your help

Hi Siarhei,

Lean can certainly be run locally with local data.  Head on over to the Lean github page and follow the directions for the OS of your choice to get started: https://github.com/QuantConnect/Lean

Excellent. Then it would be nice to communicate with Lean via some programming language agnostic (REST) API. I think this is what the engine needs for a success: people should be able to write their strategies in any programming language and still be able to back-test them with Lean. Could you please let me know if it is possible? For example, I would like to be able to talk to the engine from C++ or Python code.

No, unfortunately it is not possible. 
In order to launch a backtest, you need to send the code (C#, F# or Python) over, compile and run it in the cloud. 

Please checkout, in addition to the docs that Andrew provided, the tests we have written to test the API. 

I've written some "hybrid" algo part Lean part Java. The way I did it was by letting my Lean algo download signals produced by my external daily tick algo (C# has a bunch of communication options at different levels of abstraction, TCP/HTTP/REST whatever works for you.). For backtests your external algo must then either produce signals on demand or have them stored in database accessible to the backtest ahead of time.

Downside is, in the end this is certainly more work than writing everything in Lean, if that's possible. However, I'm planning on returning to this as there is greater flexibility in circumventing Lean's weak points this way.

There is a "dropbox universe selection" example that's a good starting point in illustrating how to interface with external algos.

Don't worry Jared, you've been making great progress since I first started this summer and stuff that didn't work great technically initially has been fixed for the most part.

Most weak points now I'm thinking about are instrinstic to the type of protected specialized cloud environment QC (not Lean, bad wording on my part) is. Stuff like: Process execution being tied to algorithms through backtests and live VPN. Limits in hardware utilization. Supported languages/libraries. To the extent these things can be addressed, it will take you time to do so by necessity. Not all users need these things (nor are all of them that urgent for me) either so it's not necessarily a priority even.

Hi Jared,

If I may make a suggestion. To make Lean independent of the language in which a strategy is written, one could do the following: 1) Lean sends to a strategy via some API a request to process some specific data, 2) strategy accesses this data, makes some decisions and sends them back to Lean, 3) Lean measures performance of the strategy using the decisions. This would make Lean a standalone program, which can be used with any implementation of a strategy. The key suggestion is that Lean should not give data to a strategy via a call of a function, but instead should just instructs it to process some data by describing it through an API.