facebookアプリは、その内部動作の違いで、FBMLタイプとiframeタイプのふたつに分類できます。

FBMLタイプは内部的にはfacebookのサーバがreverse proxyとして動作します。ユーザサイドにあるfacebookアプリのレスポンスはfacebookサーバを経由して、エンドユーザのブラウザに届きます。FBMLはfacebook固有のカスタムタグです。HTML(正確にはXHTML)内に<fb:name uid="12345"/>のように記述しておくと、reverse proxyの過程で、タグがfacebookのユーザ名に置き換わります。iframeタイプは、名前から想像できるように、facebookのサイトの中にiframeでユーザサイドのアプリ(ページ)を表示します。

ふたつの動作の違いは、後述する記事(http://www.ccheever.com/blog/?p=10)の図を見ると分かりやすいと思います。

以前(http://dev.ariel-networks.com/Members/inoue/salesforce)、salesforce.comの動作を説明しました。FBMLタイプは、独自カスタムタグがあり、サーバサイドで処理される点はsalesforce.comと同じです。ただし、salesforce.comの方は、アプリの実体がsalesforce.com上にあるのに対し、facebookアプリはユーザサイドに実体がある点が異なります。

salesforce.comの記事で、同じ仕組みを動作させること自体は難しくないと書きました。facebookアプリの方も、同じ仕組みを動作させることだけなら難しくありません。reverse proxy自体はApacheをはじめオープンソースのソフトが既にありますし、reverse proxyする過程でコンテンツ(XHTML)を書き換える処理をいれることは難しくありません(必要なカスタムタグをすべて実装するのは大変ですが、技術的な難易度と言うよりは面倒さによる大変さです)。一方で、salesforce.comと同じで、安全かつスケーラブルかつ安定に動作させることは容易ではありません。単に同じ仕組みで動作させることと、安定運用させることには大きな差があるのです。これはfacebookアプリでも同じです。

実は、ここまでは前振りです。

以下、FBMLタイプとiframeタイプのアプリをそれぞれFBMLアプリとiframeアプリと呼ぶことにします。

従来、世間的にはFBMLアプリが推奨されていました。実際に作ってみると、FBMLアプリの方が素直な作りになります。例えば、画面にユーザ名を出す場合を考えるとよく分かります。FBMLアプリの場合、前述したようにFBMLアプリのレスポンス(XHTML)内に<fb:user/>のタグを書いておくだけです。カスタムタグの処理はfacebookサーバがキャッシュするなどして高速に処理してくれることが期待できます。一方、iframeアプリで同じことをするには、iframeアプリがfacebookサーバにWeb APIベースでユーザ名を取得して、レスポンス(X)HTML内に出力する必要があります。毎回、Web APIを呼ぶオーバーヘッドが嫌ならば、iframeアプリが自前でキャッシュする必要があります。本来facebookサーバが管理しているデータをこういう風にキャッシュするのは不毛に感じます。

では、FBMLアプリで決まりなのかと言うと、そうでも無いのが困りものでした。FBMLアプリはJavaScriptと相性が悪いのです。使えないことはないのですが、色々と制約があります。その点、iframeアプリには何も制約がありません。iframeアプリであれば、元々、facebookを意識せずに作ったWebアプリを簡単に動かせます。特に、AJAXを使うアプリの場合、FBMLアプリでは、facebook用にコードを書き換える必要があります。iframeアプリならそのままのコードで動作します。

結局、facebookと心中する気ならFBMLアプリでいいですが、そうでも無ければ、現実的な解はiframeアプリ、というのが個人的な結論でした。

ここで、iframeアプリ推奨という別の動きがでてきました。

• http://www.ccheever.com/blog/?p=10
• http://developers.facebook.com/news.php?blog=1&story=152

技術的なポイントはXFBMLです。

• http://wiki.developers.facebook.com/index.php/XFBML

XFBMLは一見するとカスタムタグですが、従来カスタムタグと呼ばれていたものがサーバサイドで処理されていたのに対し、XFBMLのカスタムタグはブラウザのJavaScriptが処理をします。他の同種の技術があるのが寡聞にして知らなかったので、これには驚きました。

XFBMLを活用すると、iframeアプリはレスポンスをブラウザに直接返し、facebookの情報(ユーザ名など)はブラウザのJavaScriptがfacebookサーバに問い合わせる形になります。実は、この動作原理は、後発のOpenSocialと同じです。

OpenSocialは(その他多くのJavaScriptベースの技術同様)、伝統的なAPIベースです。クラスライブラリ的と呼んでもいいですし、RPC的と呼んでもいいです。もし(SNSサーバ上の)ユーザ名を取得したければ、JavaScriptのAPIを呼んで、AJAXで取得したユーザ名を表示HTMLに反映させる処理を書きます。一方、XFBMLの場合、XHTML内にカスタムタグを書いておけば、JavaScriptのライブラリコードがAJAXでユーザ名を取得してXFBMLのカスタムタグの部分を置き換えてくれます。

この動作の技術的なポイントは下記の「Cross Domain Communication」です。

• http://wiki.developers.facebook.com/index.php/Cross_Domain_Communication

facebookの技術は馬力はあるけどエレガンスさは無いと侮っていましたが、やられました(もっとも、XFBMLをまだ使っていないので、使ってみたらアラが見つかるかもしれないことは付記しておきます)。