プログラミングを独学している人や初心者がいちばんびびるのが、自分のアプリケーションのエンジンとなるバックエンドの構築だ。
それは、どんなインフラの上で動かしても速くて効率的でなければならない。クライアントのプラットホームを選り好みしてはいけない。バックエンドがまともに動かなければ、顧客をハッピーにしたいと願って作った、ほかのあらゆるものも動かない。
Y Combinatorが支援しているTreelineは、バックエンドの構築をできるだけ簡素化して、‘びびり’をなくそうとする。アプリケーションやサービスの中をデータが流れるためのパイプラインが、バックエンドだ、と考えるのだ。
Treelineの協同ファウンダでCEOのMike McNeilは、次のように語る: “アプリケーションのフロントエンドを作ることは、トランプのカードで家を作ることに似ている。たくさんの部品を作り、それらを正確に組み合わせて一つの構造物を作る。セットアップは難しいが、失敗してもやり直しが効く。しかしバックエンドの構築は、ワイングラスを積んで塔を作ことに似ている。そんなに難しくはないが、失敗すると手に負えなくなることがある”。
Treelineのバックエンド開発のやり方は、ビジュアルなスクリプティングツールを使ったことのある人にはおなじみのものに見えるかもしれない。何もかも自分でコードを書くのではなく（実際には必要なコードだけ書いて、GoogleやStack Overflowなどから集めた既製の部品を縫い合わせるだろう）、Treelineでは、既製の論理部品を挿入して“マシン”と呼ばれる実動モジュールを作り、そこに入れるデータ（入力）と結果（出力）を定義する。
そのためにTreelineは、McNeilが作った二つのオープンソースのプロジェクトを利用する。まずSails.js は、JavaScriptとNode.jsを使って比較的容易にアプリケーションを作るためのフレームワークだ。もうひとつのNode-Machine ProjectはJavaScriptのファンクションのオープンスタンダードで、それによってデベロッパは、各アクションが何をするか（処理）、入力として何を提供するか（入力）、そして何を結果として得るか（出力）を正確に知ることができる。ユーザはそれらをピックアップして、自分のコードのマシンに含めていく。そのNode-Machineの公開リポジトリには今、46の“マシンパック”があって、それらが、たとえばWindows AzureやFacebookやStripeなどなどのAPIへのアクセスを与える。
これらの標準化されたマシンを縫い合わせていくために使うのが、Treelineのビジュアルなエディタだ。このエディタは一種のコンパイラのように、ユーザが書いたマシンのコードからJavaScriptのコードを紡ぎだす。TreelineやNode-Machineのリポジトリで間に合わない部分はユーザが自分でマシンを書き、それをTreeline上の自分の作品に落としていく。
McNeilによると、今のところTreelineは、アプリケーションのユーザに面している部分を作るのは得意だが、スケーラブルなバックエンドの構築は誰かに助けてほしい、というインディーのデベロッパが主に利用している。そういうタイプのユーザをさらに助けるために、同社は最近、無料のホスティングも開始したから、初期のビルドをホスティングプラットホームに展開する手間も省ける。まだサーバのスピードが遅いことをMcNeil自身も認めているが、しかし長期的にはうんと大きなユーザのホスティングも（もちろん有料で）やりたい、と彼は言っている。
同社自身がルーツはオープンソースだから、自分が作った’マシン’（Treelineの構築モジュールのこと）をオープンソースにするユーザには、プロダクトを無料で提供する。作品を非公開にしたいユーザには課金するが、でもTreelineで作ったJavaScriptのコードを、Node.jsをサポートしているHerokuのようなところへ展開すれば、その課金も免れる。
McNeilが考えている次の大きなステップは、Treelineのチームワークバージョンというか、複数のデベロッパによるコラボレーションができるTreelineを作って提供することだ。結局のところ、同社の収益化はユーザであるスタートアップたちの成功に依存している（成功してない相手に課金は無理）。また、Treelineは今Sails.jsのコミュニティと協働して、同社のエディタを上手に生産的に使えるJavaScriptデベロッパを仲間にしようとしている。
[原文へ]
（翻訳：iwatani(a.k.a. hiwa）
