MiniRxSwift

I wanted to provide asynchronous networking for my StockFighterApiClient library, but I had 2 problems

• Callback-based asynchronous programming is not nice. It quickly leads to nested callback hell
• The Reactive Framework provides a much nicer async model, and RxSwift is great. I've used it in other projects and I much prefer it to ReactiveCococa, however RxSwift is a multi-megabyte download with dozens of source files, and I want to keep the ApiClient library as self contained as possible

So, I wrote a small miniaturised version of RxSwift which only contains a few of the core operators.

RxSwift and ReactiveCocoa get bloated by UI bindings and stuff like that which are completely unnecessary for the core Rx functionality, so it's great not to have any of those

It's a single file, approx 400 lines including comments and whitespace, and you can find it here:
https://github.com/borland/StockFighterApiClient/blob/master/MiniRxSwift.swift

It is missing a few things which might end up being important, but even if those get added it will still remain a single file and I doubt it'd ever get over 1000 LOC.

While this is silly wheel re-inventing, and in a serious project I'd just use RxSwift, I found that there were some benefits that came of it.

Protocol Associated Types

It was the first time I'd used protocols with associated types in Swift before. Implementing Observable/Observer as protocols in swift was an interesting journey learning about how associated types worked, and how they are different to generics.

Overall I found associated types to be profoundly strange compared to anything I'd used before in other languages.
I can appreciate that associated types can be more powerful and flexible than generics, but I couldn't help feeling that I didn't actually want or need that extra power/flexibility, and the cost and complexity it imposes (having to create type-erased wrappers such as Apple's AnySequence, or my Observer class) was annoying.
I can't help but think that this is going to be somewhat of a pain for people as they learn swift. I can imagine trying to explain to a new developer on my team why we have to write wrapper classes to bridge between protocols and generics, and I'm pretty sure that's going to be a very confusing and difficult to grasp situation for a newbie.
At any rate, I learned a fundamentally new (to me) concept. That doesn't happen very often once you get past your first few years of programming, so it's been well worth the effort.

Learning/Refreshing Rx knowledge

At work, we've got a lot of C# code that uses the Reactive extensions for .NET. I initially learned Rx way back when it was a pre-release binary dll that Microsoft shipped (I vaguely recall) privately as a helper library in some version of Silverlight or something like that.
I learned it primarily by reading the decompiled source code using Reflector, as there wasn't any documentation or even an official download of Rx for quite some time.

This ended up being great for me, as I got a deep understanding of exactly what is going on behind the scenes for each method and task. No matter how good the documentation for something is, there's no substitute for knowing that (for example) a method takes a lock just before it does some critical thing and when it releases it.

I was only really able to do this though, because Rx back then was much smaller and simpler. The Rx of today has gone through many years of Architecting, Refactoring, Indirecting, Abstracting and Organising. While I've no doubt that it's benefitted the project overall, the downside is that everything is now very hard to find and to learn.
For example, take a look at SelectMany - It's 1739 lines of code just for that class, and to understand it you also need to know how it's base class works.
In contrast, the old original code for SelectMany (known as flatMap in languages other than C#), was a single function, and looked a lot like the one in MiniRxSwift which is entirely self contained, has no classes, and is under 40 LOC including whitespace.
The real RxSwift has taken the approach of porting from C#, so it keeps mostly the same class hierarchy and complexity as the C# implementation, and is equally hard to find your way around.

Hopefully someone one day can look at MiniRxSwift and get a better understanding of Rx

P.S.

I wrote most of this from my understanding of how Rx works. I did look at the Rx documentation, and I definitely looked at the RxSwift source code along the way - not to copy it - but to learn how they were doing things with Protocol-Associated-Types. The swift compiler produces a lot of confusing error messages if you get your generics/PAT bridging code wrong and I wouldn't have been able to do it without some reference code to learn from.

Thanks RxSwift!

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!