🧊

OSCON 2014: How Instagram.com Works; Pete Huntの要点まとめ

なんか最近こんな記事ばっかですが、まぁええよね!w

今回はこちら。

OSCON 2014: How Instagram.com Works; Pete Hunt - YouTube

Instagramがどうやって作られてるか、です。
Pete Huntさんは、FacebookInstagramのエンジニアやってて、いま噂のReact.jsにも携わってるお方。

How Instagram.com Works

Webでやる理由

このアプリ全盛期にあえてWebでサービスを提供しているその理由は、

  • パフォーマンスがいいからではなく、
  • ぐぐらびりてぃのためでもなく、
  • アプリでもモバイルでもPCでも、ユーザーの利用環境を問わず提供できるから

どうつくるか

Webページをユーザーに届ける方法はいくつかって、

  • 従来型のサーバーサイドで全部レンダリングして返す
  • ページ内をいくつかのパーツ(Pageletって呼んでた)に区切って、それぞれレンダリングしたページを返す
  • JavaScriptAPI叩いてページ組み立てる(いわゆる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流のルールとしては、

  • igUserProfileAvatorみたくカッチリ命名
  • CSSとはいえカスケードしない!1セレクタ
  • 1要素には3クラスついてたら、その3クラスはそれぞれ別の内容

みんなwebpack使おう

browserifyもrequirejsも、巨大なファイルを提供するだけ。
grunt/gulpも、テストとか動かすには良いけど、そもそもファイルでしかコードを提供できない。

今ある中では、webpackが色々賢くて良い。
Requirejsからwebpackに置き換えたら、ロードパフォーマンス2倍になった。

Howtoつくったよ!

petehunt/webpack-howto

Twitterもやってるよ!

Pete Hunt(floydophone)さん | Twitter

感想

似たような仕事してるので、すっと入ってくる内容で興味深かったです。
とりあえず最初にSinglePageApp is SUCKって言う感覚はすごくよくわかりますw

webpackもReactも最近話はよく聞くけど、実際使ってるプロジェクトが身の回りにない(と思ってる)ので、
そういう意味で既に実用化してる + 経験談を語れるってのは、やはりすげーな海外・・。

そして相当先行されてるんやなーと思うと、悔しい感があります。