Ember.jsのサーバサイドレンダリングと強運の話

http://shoptalkshow.com/episodes/147-tom-dale/

1 comment | 2 points | by WazanovaNews 3年弱前 edited


Jshiike 3年弱前 edited | ▲upvoteする | link

Ember.jsを率いて、積極的な発言もあり、今やJavaScriptフレームワークの世界では主要人物となったTom Daleですが、成功する人は、それを掴める強運の持ち主でもあります。

自分は本当にラッキーだった。だから人にアドバイス頼まれても再現が難しい話なんだけど。大学ではコンピュータサイエンスの学位は取ろうとしたんだけど、純粋数学は難しすぎて単位が取れなくて。その後はApple Storeのジーニアスバーで働いていたんだ。友人がAppleのリテールチームにいて、彼は自分がシェルスクリプトをちょっと書けることを知っていて、「プログラマーを必要とするプロジェクトがあって、公式には会社からサポートされてないんだけど、やってみる?Apple Storeで働いてることにしてバイト代払うよ。」と言ってくれたのがSprouteCoreアプリの開発案件。そのアプリがAPIを介してRailsとやりとりするかたちになっていて、Railsは本を読んでちょっといじったことがあったので、そこを担当することを志願。クライアントのSprouteCore自体はJavaScriptだと聞いて、学びたい興味はあったけど、そもそもまったく経験なかったので。しかし、サーバ側はものすごくシンプルだったので、そのAPIについては二週間ほどで作業が完了してしまう。ところが、JavaScriptについては、自分も知らなかったけど周りにも知っているメンバがいないので、やってみればと言われて、本屋で「JavaScript Definitive Guide: Good Part」を購入。ホテルの部屋で、いつクビになるかとビクビクしながら、イチから勉強。

そうこうしているうちに、mobile.meとiCloudがSprouteCore(ちなみにSprouteCoreはEmber.jsの前身となるプロジェクト)を採用することになって、それをメンテしてる人たちと知り合いになれた。2009年か2010年だったんだけど、当時はJavaScriptを使ってアプリっぽく書けるのは誰もいなかったし、そのようなマインドセットも皆なかったけど、自分は新人だったから先入観なくてラッキーにもその場にいたので、実は4ヶ月しか経験なかったけどAppleがSprouteCoreのメンテナーの一人ということで正社員として雇ってくれたんだ。

次の奇跡は(Rails、jQuery、その後Ember.jsやW3Cなどで活躍する)Yehuda KatzがRails3の開発を終えたところで、JavaScriptをクライアント側でうまく利用すればインタラクションが良いユーザ体験を提供できるはずという課題意識を持っていて、SprouteCoreのクリエーターがつくったStrobeをいう会社に入ったこと。SprouteCoreのAPIについてYehudaと少し一緒に仕事をする機会があって、すると彼が自分をAppleからStrobeに誘ってくれたんだ。プログラム経験まだ1年くらいだったのに。それからずっと今まで毎日Yehudaとペアプログラミングでオープンソースに取り組むことになったんだ。[1]

さて、そのEmber.jsはバージョン2.0に向けて、ReactにならってバーチャルDOMの採用や、片方向バインディングをデフォルト化するなどの発表 [2] もしてますが、今日はサーバサイドレンダリングの話。(そもそも、これが本題だったのですが、Shop Talk Showのpodcastを聞いていて、Tom Daleのキャリアの話があまりに面白かったので脱線してしまいました。)

"Inside FastBoot: The road to server-side rendering" と題したブログのエントリーで、

(ページの読み込みが遅れるので)TwitterがクライアントサイドJavaScriptのアプローチをサーバ側でレンダリングするかたちに戻したように、JavaScriptアプリをサーバ側で起動して、ブラウザで「再度水和させる」アプローチは、ここしばらくは王道と考えられていた。しかし、ほとんどの試みはビューレイヤをサーバでHTMLにレンダリングするかたち。これは重要なステップではあるが、これだけでは問題を解決できない。

問題の解決にはビューレイヤだけでなく、アプリを立ち上げるライフサイクル全体(ルーティング / モデルの取得 / レンダリング)を絡める必要がある。Emberのアプリ構造に頼ることで、この複雑さをアプリからフレームワークにもっていくことができる。

新機能FastBootを使って、EmberアプリにHTMLとCSSをすぐに送り、読み込みが終わるとJavaScriptが役割を引き継ぐ。検索エンジン、モバイルユーザ、cURL、JavaScriptを無効にしているユーザからすると、Emberアプリはサーバ側でレンダリングするものと変わらぬ振る舞いとなる。

… 完全なブラウザ環境に依存する部分を注意深く分離するようにしてきた。… DOMベースのレンダリングエンジンを継承するHTMLBarsの開発においても、DOMにタッチする際には抽象化を用い、サーバ側で別のものに取り替えることができるようにした。… これにより、たった1日の作業で、EmberフレームワークがNode.jsで実行できるようにすることができた。

としています。その他詳細はブログ [3] を確認ください。

この機能についてのTomの発言 [4] は、

JavaScriptでアプリを一つ書くとサーバとクライアントでうまくどうにかしてくれるというマジックはない。サーバとクライアントの役割は違う。サーバは、認証 / 認可 / JSON APIのようなレンダリング、クライアントはAPIを利用して美しいインターフェースをレンダリングする。Meteorも、実際は一つのアプリで全てやるというのではなくて、基本的には役割の違う二つのアプリがラップされたもの。

間違っても、サーバアプリをEmberで書こうなんて思わないでほしい。ポイントは、クライアントアプリを書いたら、サーバがプロセスを引き継いで、起動のセッションと最初のレンダリングをして、そのクライアントのステートをブラウザ側に移す。けど要するに単なるクライアントのアプリなんだ。

(「クライアントが全ての可能性のあるrouteを把握し、バックエンドも同じことをするなんて悪夢だ。」というコメントに答えて、)同じじゃないでしょ。正しいアーキテクチャでは、サーバは純粋にモデルに対応している。もし /topuser というページを訪問したければ、home/topuser というURLに行く。バックエンドに topuser のエンドポイントはない。バックエンドにはクエリもしくはフィルタリングができるユーザのエンドポイントがある。(「でも、サーバはそのURLを全て把握しなくてはいけないでしょ。」に対して、)その点については、Emberのサーバサイドレンダリングで対応する仕組み。クライアントがヒットするどのURLも、本番サーバにあるNodeアプリが この場合は /topuser というリクエストを検知する。それがするのはまずEmberアプリを起動して、EmberアプリをこのURLにrouteする。そのEmberアプリがAPIサーバをヒットし、それは同じデータセンタか、同じマシンであるかもしれないし、ものすごく瞬時にデータをとってくる。HTMLをレンダリングして、クライアントに返してくる。基本的に、サーバで実行されるEmberアプリがあり、サーバで実行されるAPIサーバがあり、お互いがやりとりをしていて、EmberアプリがHTMLをブラウザに提供している。

[1] [4] http://shoptalkshow.com/episodes/147-tom-dale/

[2] https://github.com/emberjs/rfcs/pull/15

[3] http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-to-server-side-rendering.html


2014 Topアクセスランキング


Back