Life is beautiful

ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。

App Engine は純粋なソフトウェア・エンジニアにとっての天国

私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。

新しい言語を学ぶのが苦ならApp Engineは避けた方が良い

現時点で、PythonとJavaのみがサポートされているが、App EngineをやるならPythonがおすすめ。私もPythonはApp Engineが初めてだが、とても簡単な言語なのでそれほど苦労せずに使いこなせるようになる。「今さら新しい言語を勉強するのは辛い」とか「RubyかPHPが動くならApp Engineを試してみたい」と考えるような人はApp Engineには手を出さない方が良い。Pythonの習得を苦労しているようでは、Big Tableは使いこなせない（というか、そもそも新しい言語の習得を「楽しい」と感じないならば、ソフトウェア・エンジニアという職に向いていないと）。

フレームワークに頼るな

上に述べたように、App Engineの一番の魅力は、実行効率を直感的に意識してプログラミングできる（もしくは、それを強いられる）ことにある。なので、できるだけサードパーティのフレームワークや巨大なライブラリは避け、必要最低限のコードだけをGoogleが提供している最低限のフレームワーク上にサクッと作るべき。もし、Googleが提供しているフレームワークが難しいと感じたり、不十分と思うのであれば、App Engineは避けた方が良い。私自身、最初はいくつかサードパーティのフレームワークを試してみたが、すべてのソースコードを読まなければ気が済まないし、読むと気に入らないところがたくさん出て来る。で、結局は自分なりの最低限のライブラリ集を作ってそれを再利用してアプリを作る、というのが効率面でも品質面でも一番良いとの結論だ（gdispatchはその副産物）。

Data Modelはできるだけフラットに、かつシンプルに

このあたりが、RDBに慣れた人たちには一番取っ付きにくい部分かもしれないが、Big Table上でのData ModelはRDB上のものとは大きくことなることを理解すべき。私は現在、ファイルの共有サービスをApp Engineで作っているが、ModelはUserとBlobStoreの二つしかない。RDB上に作れば２０個ぐらいのテーブルになりそうな複雑な処理をしているのだが、App Engine上ではたった二つである。「App Engine上ではJoinが出来ないから」という声を良く聞くが、そんな泣き事を言う前に、そもそもJoinが必要になるようなモデル設計（つまりBigtable向きでない設計）をしてしまっていないかを確認すべきである。

GQLはまやかしである

Googleは、App Engine上のQueryを記述するための言語としてGQLという言語を用意しているが、これはSQLに慣れた人に「App EngineにはGQLがあるから怖くない」と誤解させるための、まやかしである。本気でApp Engine上でプログラムを書くのであれば、GQLは使うべきではない。

Task Queueを使いこなせ

Big Tableの一つの大きな特徴は、ReadとWriteの非対称性である（Writeが何倍も遅い）。それゆえに、ループを回して連続でWriteをすのは得策ではない。そこで便利なのがTask Queue。Task Queueを活用したサーバー側での非同期プログラミングができるようになったあたりから、App Engine上でのプログラミングの自由度が大きく広がる。

テンプレートの処理はできるだけクライアントにさせろ

ガラケー向けのサイトでも作っているのならば仕方がないが、パソコン上のブラウザー向けのサービスを作っているのなら、テンプレート処理はクライアント側に処理させるのが得策。つまり、HTML/JS/CSSファイルに加え、HTMLのテンプレートファイルもすべてstaticファイルとしてクライアント側にダウンロードし、JavaScriptからApp EngineのModel APIを直接叩いてJSONの形で結果を受け取り、それをクライアント側でHTMLテンプレートと結合して表示する。つまり、Model/View/ControllerのModelをApp Engine上でPythonで書き、ViewはHTMLテンプレートも含めてすべてstaticファイルとして提供し、ControllerをJavaScriptで記述するのだ。こうすることにより、App Engine側での処理を極力軽くし、かつ、ユーザーにとっては見かけの待ち時間が少ないおもてなしを提供できる。

何と言っても「プログラミングに集中できる」のがApp Engineの醍醐味

そして、私にとってApp Engineの一番の魅力が、サーバーの台数を調整したり、ロードバランスをしたり、データベースのパーティションを気にしたりなどの「サーバーの構築・運営」などの雑務から解放されること。すでに、App Engine上で三つほどサービスを運営しているが、どれも一度走り出してしまえば基本的には「メンテナンス・フリー」になるところがすばらしい。何ヶ月か前にリリースしたTinyMsgも、発言する人や内容によって時々トラフィックが急増するのだが、そのあたりをキチンとハンドリングしてくれるのでとても助かる。

最大の欠点はGoogleにLock-inされてしまうこと

これに関してはあまり解説する必要もないとは思うが、App Engine上にサービスを作るということは、すなわち「Googleのインフラ上でサービスを提供することにコミットする」ことなることは覚悟して進めるべきである。「コンパチブルなオープンソースのプロジェクト」もあるにはあるが、それをサービスとしてGoogleほどの規模とコストで提供するところが現れるまでは（そう簡単には現れないと思うが）、Google が唯一の選択肢である。

長くなってしまったが、以上が私がApp Engineに関して感じていることのまとめだ。確かに「敷居は少々高い」が、一度その敷居を乗り越えてしまうと何とも心地よいプログラミング環境が整っているというのが実情である。その壁を乗り越えるのを「楽しい」と感じるのであれば、かつ、GoogleにLock-inされても良いと考えるのであれば、App Engineはとても良い選択肢だと思う。