Eleven months ago, a beer and a handshake kickstarted one of Brisbane’s most intriguing startups, API Engine.
Greg Davis, former engineering director of a Brisbane-based software company, was building a fairly hefty API that was a chore to document. His co-founders developed a nifty way to make documenting APIs easier, and over drinks late last year, they reached a gentlemen’s agreement to self-fund and bootstrap the idea into a fully fledged product.
Like most good development tools, API Engine was borne out of a need, in this case API documentation. But it didn’t stop there. Davis and his co-founders soon found they needed to glue together disparate systems, and provide consistent API access – things which are not well-served by the API tools that come out of the box in web development frameworks such as Rails and Play.
The result is a composition utility for software developers that has found a market niche: since December last year more than 2,500 people have signed up to be beta testers and Davis says API Engine frequently receives requests from software development companies to use their system.
API Engine plans to launch the beta offering later this year. When it does, the team will target two market segments: internal APIs found in large enterprises (such as financial institutions), and the plethora of RESTful APIs publicly available on the internet.
A small group of local developers, bootstrapping a company that aims to take the legwork out of documenting and combining APIs is impressive. But once you get under the hood of API Engine, the real intrigue begins.
I’m not going to lie. I was a bit of a functional programming skeptic. It sounded costly, both in terms of development effort, memory and CPU consumption. And having never really seen or heard of Haskell, the purely functional programming language in a production environment, I had written it off as another academic curiosity.
I was using this very argument against functional programming when I first learned about API Engine some months ago. It was the first time I’d heard of Haskell being used in production. But since then, my ambivalence towards this form of programming has slowly been replaced by a newfound appreciation of its real-world advantages.
Davis says size was one of the reasons behind the decision to use Haskell: “The code base itself is no larger than 5,000 lines of code. In fact, it is probably still less than 3,000.” If they had developed API Engine in a more traditional language such as Java, it could have been as much as five times larger.
Not only is their Haskell code small and well structured, it is also robust. “When you come into a new system, you wonder which bits are robust and which aren’t. And Haskell was new, fairly new to me… As it turns out, I never go looking at the Haskell, because that is the bit that never breaks,” Davis laughs.
Choosing Haskell to power the back end of API Engine was a decision influenced not only by technical considerations, but deep principles held by the founders and a sense of responsibility to the next generation of software developers. In Davis’ case, a sense of embarrassment: “I have children, and I am embarrassed to teach them things that our industry is doing today.”
This embarrassment stems from fundamental development practices that currently permeate the industry – how problems are analysed and the awkward way in which code is composed by multiple developers. These are things the team at API Engine thinks can be partially solved by functional programming and Haskell.
Along with enabling developers to build great APIs, Davis and his co-founders are aiming to create a workplace with a development culture steeped in functional programming that they would be proud to share with their children.
The ultimate goal is to have a workplace that will have a positive impact on the general software culture in Brisbane, by promoting new approaches to problems, and challenging the status quo.