Bringing Cocoa to the Web
A few years ago I was doing a lot of web programming (PHP mostly) and a lot of macOS development. I was constantly switching between the two and it drove me mad. Seriously, I had come up the point where I was typing dollar signs in Objective-C and square brackets in PHP.
OS X programming and the whole “Apple way of doing things” was a very unusual thing to me at the beginning. I think it took me several attempts until I was … well … in it. But once I was, boy was I in it. I grew to enjoy the development pattern, how everything connected to everything. It felt a bit too loose at first, but it soon started to make sense — and a lot of it at that. In 2012 I started work on SnappyApp and other macOS projects and soon dove into the finer points of the Apple SDKs. I grew to like it and became quite apt at it.
It’s all just concatenating strings. Quickly.
I have always been intrigued by having the weirdest technologies produce HTML content and serving them over the web. I remember making a small system while I was in college that would scan my PHP code and then list the functions and classes and make a nice search index and pages for all of then. In bash. Using grep, sed and cut. Because I could. It was obviously very slow and cumbersome but it did produce a usable, serve-able web-page. This was 15 years ago.
At some point, towards the end of 2011, I was starting to get pretty annoyed with the speed of PHP — or lack thereof — so I started looking into more “low-level” stuff. I really didn’t want to start doing things in Java or ASP.NET: those days were behind me. That’s how I came across FastCGI. It was nice and, for a while, PHP was faster; at least for a while.
I still had the problem of typing dollar signs in Objective-C and square brackets in PHP. It was starting to get pretty annoying and, frankly, counter-productive. Call me crazy but I really liked Objective-C — verbosity, endless sequences of nested square brackets and all: to me it made sense. It still does. I wanted to be able to make web-pages with it. But there was nothing quite like what I had in mind … out there.
Back in the pile!
It’s now mid 2013 and I had just moved to Copenhagen, as a freelancer. In my limitless genius I had failed to consider the fact that the whole of Denmark was on vacation and that no-one was in the mood for discussing new projects, not seriously. I remember one of the first meetings with one of my future clients:
“So, when should we have our next meeting?”
“Let me check: September 8th?” We were in late June.
This left me with a lot of time on my hands. I used said time to work on what I was then calling FCGIKit. This thing went through three complete rewrites. Three. I first started with a runloop based FCGI server, but that turned out to be too slow and not very stable, especially in high-concurrency scenarios, so Back in the pile!. Enter Grand Central Dispatch.
I then did a version that turned out to be ok(ish) in terms of speed, but terrible in terms of developer-API. It was too cumbersome. Back in the pile!.
There were some valuable lessons learned, but ultimately the architecture and some of the concepts I experimented with were not up to par with what I wanted to accomplish. I think the concurrency model was the biggest thing that I carried over from that. Of course I tweaked and tuned it a little bit.
Pure-bread horses and rare cocoa beans
It’s now late 2015 and I’m still benchmarking and still frowning. Turns out FastCGI just isn’t fast enough so, somewhere at the beginning of the year, I came to terms with the fact that I was going to have to write my own HTTP implementation. Which I did. I had already left the path of the freelancer in favor of the more cozy, steady-job, one-project-at-a-time life. I was working on Calendize.
The first step however was to write a minimal HTTP server and stress-test the ever-living soul out of it, in order to figure out if this could actually be a thing or if I had been wasting the previous two years on this.
After a few weeks, the moment of truth had finally come upon me. Deep breath. I was running benchmarks against Node’s “hello world” example. My thingie would have to be faster and much more stable in long, high concurrency runs. No pressure. I used to leave ab and siege running for days at a time. I had pages of hand-written tables depicting various scenarios and their outcomes. It was nerve-wrecking. But it was working. I was able to make it run faster and for much longer, especially with HTTP 1.1 keep-alive connections.
Few months later — early 2016 — I was thinking it was releasable, even though I still needed a name. After a bit of brainstorming, I came up with Criollo. No, it’s not named after the horse.
Cocoa beans of the Criollo variety are rarer and considered a delicacy.
That is pretty much the story in a nutshell. It was a very lengthy process, but an extremely satisfying one and, as far as I’m concerned, it’s only the beginning.