Thursday, January 28, 2016

StockFighterApiClient

TL;DR

I wrote a client library in Swift for StockFighter. It's on github at https://github.com/borland/StockFighterApiClient, feel free to use it or check it out!



If you're a programmer and you haven't heard of it, I'd recommend checking out StockFighter.
It's a "programming game" wherein you have to write code to perform some task in a correct/fast/clever/etc way. In this specific instance, the goal is to write bots to perform high-frequency stock trading (well, actually pretty slow frequency trading compared to real stock markets, but much faster than a human would).

I'm midway through the third level so far, but I've found it quite interesting and challenging to think about some of the strategies for solving some of the problems.

The way it works is you write some code to connect to their cloud servers via a REST api (and/or WebSockets) and have your bot buy and sell stocks on their fake stock exchanges. Different levels have different challenges.

I'm a big fan of Swift at the moment, so I wanted to use it for stockfighter. Swift has

  • Nice syntax and a nice high level - I find swift code to be mostly similar to C#, but with less semicolons and brackets which is always great, and it's often more concise. Code is roughly about the same size as it would be in Ruby or JavaScript.
  • Decent functional programming style support - It has nice lambda functions, things like map/filter over collections are built in and you can extend existing types to add more complicated methods as needed)
  • Null safety - The compiler can enforce that things may or may not be null which is a bit weird at first, but once you get used to it is very nice. I find on average my swift code has a much higher chance of "just working on the first run" primarily due to this.
  • An exception model which I like - I always found Java's explicit checked exceptions to cause too much code bloat, especially having to declare catch blocks for multiple different exception types all over the place. At the same time, I've sometimes found the "transparent" exceptions of C# or C++ aren't as nice because often you simply won't be aware that a method could throw an exception until you find out later in a crash report. The swift model strikes a middle ground, and while it has some shortcomings too, on balance I like it better than either of the other approaches
  • Good performance - It seems to be roughly in the ballpark of C# or Java, but uses less memory and starts up faster due to lack of a "runtime" and garbage collector, which is great
Anyway, I looked online and found one existing client library - RSStockFighter, however, I wanted to write my own client library from the ground up for fun, and for practice.

Additionally RSStockFighter uses a "command object" pattern, wherein you create different kinds of objects representing each different request you might want to make, then you submit them to the server. While such a pattern offers many benefits and is probably good OO design, I find it adds friction to the programming experience and is not what I'd like to use (at least for a project the size of a stock fighter client. It might make more sense when you have an API with hundreds of methods).

Rather than this:

let order = StockFighterOrder(symbol:SF_STOCK_SYMBOL, price:95.00,qty: 100,direction:SF_OrderDirection.Buy,orderType:SF_OrderTypes.Limit.rawValue)
       
StockFighterHelper.sendStockFighterTransaction(order, success: {
    (dict:NSDictionary!) -> Void in
        self.checkOrderResponse(dict)
}, failure: {(str: String) -> Void in
        print(str)
})


I'd much rather write this:

let response = try venue.placeOrderForStock(SYMBOL, price: 9500, qty: 100, direction: .Buy)

HTTP calls in my library are synchronous, and either return a result or throw an exception, which generally makes the code shorter and clearer.

Personally I prefer asynchronous I/O, however then you have to deal with callbacks. The Reactive frameworks - RxSwift in this case - provide a much nicer model than the nested-callbacks approach, so I think if I were to provide async methods I'd use RxSwift - however that means if anyone wants to use my Api they must also take a dependency on RxSwift, so I left it out for now.

My library also provides access to the StockFighter web socket API using SocketRocket behind the scenes. I embedded a copy of SocketRocket in my github repo so there's only one thing to download, but adding third party frameworks such as SocketRocket to a project in Xcode is a bit of a pain. I've documented the process in my README, but it's still not ideal.

I didn't want to use something like CocoaPods / Carthage because they are yet another barrier to entry. I don't want to ask people to go and cruft up their system and install some magical dependency manager which is going to do who-knows-what when I could offer people a simpler "copy some files" option instead. Perhaps that's a topic for another post in future.

Anyway. Head over to github and check it out if you're interested. It's on github at https://github.com/borland/StockFighterApiClient and I'd appreciate any feedback!