OSCON 2014: How Instagram.com Works; Pete Huntの要点まとめ
なんか最近こんな記事ばっかですが、まぁええよね！ｗ
今回はこちら。
Instagramがどうやって作られてるか、です。
Pete Huntさんは、FacebookでInstagramのエンジニアやってて、いま噂のReact.jsにも携わってるお方。
How Instagram.com Works
Webでやる理由
このアプリ全盛期にあえてWebでサービスを提供しているその理由は、
- パフォーマンスがいいからではなく、
- ぐぐらびりてぃのためでもなく、
- アプリでもモバイルでもPCでも、ユーザーの利用環境を問わず提供できるから
どうつくるか
Webページをユーザーに届ける方法はいくつかって、
- 従来型のサーバーサイドで全部レンダリングして返す
- ページ内をいくつかのパーツ(Pageletって呼んでた)に区切って、それぞれレンダリングしたページを返す
- JavaScriptでAPI叩いてページ組み立てる(いわゆるSinglePageApp)
この中でいわゆるUXが一番良いのは3番目。
なので、SinglePageAppで作ってる。
どう届けるか
全ファイルを1ファイルにするのはもはや悪手。
Instagramでは9.5MB(gzipで2.5MB)にもなるので、モバイルだとやはり酷。
SinglePageAppのPageとは、EntryPointのことであって、サービス全体のことではない。
そのEntryPointごとにファイルを分けるのが良い。
ライブラリなど、共通のファイルは共通のファイルとして固めておく。
モジュール化
ベタで依存関係を考慮しつつ書いていくのはつらいので、なんかしらModuleシステム使おう。
意識すべきは「モジュール化」とその「依存関係」。
CommonJSライクなのがわかりやすくて良いし、
そういうシステムがあれば、依存関係を気にしないで済む。
そして、モジュールは必要な時に非同期で取得。
Cssであっても非同期にrequire()する。
.coffeeも.tsも。
最終的に「ファイル」を読み込ませて利用するという考え方ではなく、
必要な「モジュール」を依存関係に沿って随時ロードするって考え方でやってる。
Instagramではwebpack使ってる。
Css
JavaScriptだけでSinglePageAppは作れなくて、Cssもちゃんとする必要ある。
こういうのが蔓延すると、あとでメンテしようとしてもこのクラス使われてんの・・？状態になる。
Instagram流のルールとしては、
みんなwebpack使おう
browserifyもrequirejsも、巨大なファイルを提供するだけ。
grunt/gulpも、テストとか動かすには良いけど、そもそもファイルでしかコードを提供できない。
今ある中では、webpackが色々賢くて良い。
Requirejsからwebpackに置き換えたら、ロードパフォーマンス2倍になった。
Howtoつくったよ！
Twitterもやってるよ！
感想
似たような仕事してるので、すっと入ってくる内容で興味深かったです。
とりあえず最初にSinglePageApp is SUCKって言う感覚はすごくよくわかりますｗ
webpackもReactも最近話はよく聞くけど、実際使ってるプロジェクトが身の回りにない(と思ってる)ので、
そういう意味で既に実用化してる + 経験談を語れるってのは、やはりすげーな海外・・。
そして相当先行されてるんやなーと思うと、悔しい感があります。
