Why I'm Building TreeHive

My name is Alex Kieft, and I have been developing websites since 1997, when I was in seventh grade. In the past five years, I've worked on a few personal projects (Engio, CoolMove, and Vidista), several sites for friends and family (Carol Furtado, Adina Bricklin, and Jim Klimek), and a variety of products for my employer (CelticVision and KnowledgeVision). I principally consider myself a front-end developer, working first in HTML and JavaScript, and more recently Flash, Flex, and Adobe AIR. In the process, I've also had to learn the basics of back-end development, namely ASP, PHP, and MySQL. Most recently, though, I've been thrust into the world of APIs, including those offered by Brightcove, PermissionTV, Flickr, QuickBase and Amazon.

TreeHive is the product of several ideas I've had and a couple of problems I've encountered over the last few years. The original kernel was an idea I had while I was working on Engio in 2005. Frustrated by the "yes, no, yes, no" nature of traditional online forums and discussion boards, I envisioned a tree-shaped forum, that encouraged participants to build on branches of discussion where they could add positive, constructive thoughts. If they disagreed with the direction a particular thread was heading, they could branch out and offer a new, alternative discussion, rather than try to tear down what others had said. I built a prototype of what this might look like at the time, but I didn't get very far.

I had to put my tree-shaped forum idea on hold, but I've kept it in the back of my head. In the meantime, I learned a lot of new skills, and I've also thought of a lot of new ideas, especially for web applications. But I've also run into a number of problems that have prevented me from fleshing them out into real projects.

The first problem is that I really don't enjoy working on back-end development unless I'm learning something completely new in the process. Even then, I find it monotonous, tedious, and difficult to debug. Stumbling across CodeIgniter has certainly helped make PHP a lot more tolerable, but I still feel like I'm reinventing the wheel with every new application. The front-end is the exciting part for me, since that's going to be different every time. But the back-end is typically just a mechanism for storing and retrieving data, à la CRUD, with some slight changes to rules each time. I know there are plenty of developers out there who live for this kind of thing, but not me.

Second, I've discovered that I simply have too many ideas and not nearly enough time to fully develop each of them from scratch. Last summer, while on vacation, I tried to list the various ideas that had popped into my head over the last year or so, in an effort to prioritize them. It quickly became clear that, unless I quit my job and hired a crew of freelancers, I simply wouldn't have the capacity to flesh them out. But I might have at least been able to toy with some of them, if it weren't for the back-end problem slowing me down.

Nonetheless, I looked at my list and decided that the tree forum was still the best of the bunch. As I contemplated the potential tedium of building the server-side of what should be an otherwise interesting, enjoyable front-end application, I started considering a couple of other things.

First, I had just finished reading Chapter 7 of Dan Bricklin's book, Bricklin on Technology. In this chapter, he discusses his philosophy about why general-purpose tools, like the spreadsheet and word processor, tend to win out over more focused applications that attempt to solve specialized problems or perform specific functions. Most interesting to me was the idea that when a consumer considers using or buying an application, his uncertainty about the ability of a product to solve his particular problem drives down the price he's willing to pay for it. Highly specific applications lead to greater uncertainty, while general-use tools reduce that uncertainty, because the consumer knows that they can be applied to much wider range of situations. All of this lead me to consider how I could abstract the tree forum idea to become potentially useful in unforeseen ways.

Second, I had been playing with Amazon's cloud computing platforms at work, and I started thinking about how I might be able to construct the tree forum directly on top of Amazon's APIs, thereby avoiding having to build a traditional back-end. However, Amazon's web services all rely on security schemes involving secret tokens to authenticate transactions. That's easy to do when your token is stored in a server-side script, but all client-side applications, even compiled Flex applications, risk exposing that token. Furthermore, Amazon didn't offer a relational database service at the time, and even now with RDS, you still need an intermediate server to properly process and authenticate requests. At this point, I knew I wouldn't be able to get around building a back-end myself, even if it eventually ran on a cloud platform like Amazon EC2 and RDS.

But it prompted me to imagine what an ideal third-party API would look like for an application like mine: one that could support front-end applications without relying on secret keys; one that would allow for relational, branching data structures; one that could easily plug into JavaScript, Flash, or Flex; and one that would require an absolute minimum of back-end development. This was the beginning of the TreeHive idea. Rather than build the tree forum as a standalone application while the rest of my ideas gathered dust, I would try to develop a general-use API that could serve as the foundation of the tree forum, and eventually my other ideas as well. Yes, it would require a hefty dose of less than thrilling server-side programming, but the promise is that I might never have to do it again!

As of right now, I'm nearing completion on the alpha version of TreeHive, which means it will still be some time before I make it available publicly, even in beta. My hope, though, is to eventually publish it under some form of open source license so other developers can see what's going on behind the scenes, and potentially install it on their own systems. Further down the road, I'd like to get it fully running on the cloud and offer access to it as a paid service.

Stay tuned, I'll be providing more technical information about how it all works soon!

What is TreeHive?

TreeHive is a platform with a simple goal: to facilitate and accelerate the development of front-end web applications by supplying a flexible API for storing and retrieving structured data.

TreeHive eliminates the need to define a data model, configure a relational database, program server-side code, or build a user-management system. Instead, it isolates the minimum back-end logic required for your application and condenses it into a single, maintainable document. After that, TreeHive leaves the rest of the work to your JavaScript, Flash, Flex, AIR, or iPhone application.

This is just the beginning, but there's a lot more to come. Stay tuned!