(This is a repost from my blog. Original is here --Joey)


When Lars and I started work on Branchable, the Ikiwiki-based wiki and blog hosting service that we first discussed a year ago, and launched two weeks ago, we didn't know what software to use to build it.

Probably, we assumed, we'd need a relational database. (Or maybe Couchdb, we wondered?) To manage the sysadmin jobs of keeping a slew of Ikiwiki sites running, we investigated using Puppet or Chef. (We worried that scaling Puppet or Chef to handle an arbitrary number of ikiwiki sites could be a problem.) For the user interface frontend, we assumed we'd be writing code in some kind of web application framework.

Nearly all of that conventional wisdom turned out to be false. Instead, all the frontend code for Branchable runs as part of Ikiwiki. www.branchable.com is just another Branchable site, though one with some custom plugins that can make other sites and display a user's control panel. Other plugins handle things like the DNS setup interface.

Those plugins are part of the first public site hosted on Branchable, ikiwiki-hosting.branchable.com. That wiki's git repository holds all the code, as well as the wiki for documentation and bug tracking. Also included in ikiwiki-hosting are some backend programs, like ikisite, which handles the high-level site management (creation, deletion, branching, etc), and is what we used instead of Chef. (Though we may use Chef for server deployment later.)

Rather than use a relational database, we did out own little noSQL thing, by using a special, locked-down wiki as our database. That wiki is so special-purpose that it is not even accessible via the web! But it's managed by Branchable just like any other site. Deciding to not use a database was a watershed moment, because at that point we were fully dogfooding everything for Branchable. It's worked out well so far, possibly because our database needs are minimal.

We have over a dozen other Ikiwiki sites in Branchable that we use either internally, or for other special purposes. Like this parked site that is branched every day to refresh sandbox.branchable.com.

So, no database, no Puppet, lots of dogfooding. Did we use a web app framework? Not really. The closest we came is when developing Branchable highlighted that Ikiwiki needed a more user-friendly openid login interface, so I went off and adapted one, and of course added it into Ikiwiki proper. And that uses the JQuery framework. (I might write sometime about all the other Ikiwiki improvements that Branchable spurred.)

We've done a lot of eating our own dogfood at Branchable, but I think it's all been pragmatic, not due to Not Invented Here syndrome. And the result is that Branchable is increasingly flexible in what its sites can do, and runs on a very simple architecture, with no odd special-cases for database servers, etc. It's just a bunch of Ikiwiki sites that work together.

Leaves on tree