A Trip Down Memory Lane

Looking back at the Yobongo codebase 3 years later

As part of my process of searching for a new gig I’m asked to field a lot of questions about my past experience, especially Yobongo since I was a co-founder of the company. A lot has changed in iOS and node.js development over the past 3 years since Caleb and I started Yobongo, and looking back over the source code of the app I felt a bit of nostalgia remembering how primitive iOS development was only a few years ago.

Since Yobongo was a chat app we needed to create a socket connection between the iOS app and the node.js backend in order to make things fast enough. In 2010 the best library was called, unimaginatively, AsyncSocket and seems to be a port of an old Mac library. It doesn’t seem to exist anymore, although CocoaAsyncSocket might be a descendent. Websockets didn’t become a standard until 2011 and SocketRocket was a ways down the road also. AFNetworking also didn’t exist yet or was in very early development. We used ASI for a few things.

We had two JSON libraries in the app, SBJSON which we used to parse the responses coming back from our server and TouchJSON which was required by one of the libraries we used (Flurry I think). Neither of these are used much today. Today NSJSONSerialization and JSONKit are the most common.

Our deploy target was set to iOS 3.1 and we tested on devices all the way back to the 3G and second generation iPod touch. Despite the fact that we didn’t want to go anywhere near Android we tried our best to support as many iOS users as possible. The iPhone 4 was a big step forward in performance but was only a couple months old and only represented a small percentage of users at the time.

ARC did not exist yet, resulting in code littered with retains and releases. The iPhone 4 was also the first retina device which meant we had some issues with text sizing when calculating how tall to make the chat bubbles on the main screen of the app. There were no storyboards, only xibs, and no fancy Asset Catalogs either.

On the node.js side of the equation things were even more primitive. The first version of node we used was somewhere around 0.4.10. There were breaking API changes all the time. The MySQL driver was flakey and not asynchronous so we were more or less forced to use MongoDB which was the best supported. Mongo’s JSON document format works nicely with node.js, but it wasn’t the most stable either . On the plus side, writing a chat server in node.js was easy even back then, and I swapped the backend out from MySQL to Mongo in a day.

Of course scaling Node was a different story. None of the cluster functionality that exists today was around then. I wrote what I called a “proxy” layer (also in node) which was intended to simply pass requests through to worker boxes. The workers would come online and register themselves so we could easily add new instances as we needed them. This worked well enough, but in retrospect it was insanity to use something so un-battle-tested in production and there were a lot of bugs to work through.

All of that considered, it is amazing to me that the Yobongo app worked as well as it did. Things were even stable enough that we had time to implement features like hell-banning (ok that one might have been a high priority given the amount of trolling in chat rooms). Even on EDGE cellular connections you could send and receive chat messages with less than a second of latency most of the time. It was magical to see the chat flowing through the system and watch people meet random strangers in their city who they would’ve never talked to previously and even though the technology might’ve changed drastically that problem is still out there waiting for someone to figure out how to crack it.