DiscourseのJavaScriptが順次ES6モジュールのフォーマットにコンバートされてますが、Rovin Wardはその理由の一つとして、Railsのアセットパイプラインへの依存を解消し、ember-cliを利用するためであることを挙げています。

新しいリリースをするときのプロセスは、サーバ側のコードに変更がなければ、Railsアプリ全体をデプロイしなくて済むようになる。

とし、その参考としたのが、RailsConf 2014での、Yapp LabsのCo-founder & CTOであるLuke Meliaの講演のようです。

• Railsをバックに、ホームページ、規約ページ、JavaScriptアプリ、JSON APIという構成。
• Railsアプリを本番環境にアップするのに、大量のファイルを転送し、依存関係をインストールし、アプリを起動することで、少なくとも数分かかる。
• JavaScriptの変更だけで数日かかることがある。静的なJavaScriptの変更をデプロイする度に何分か待たされることになる。
• Railsアプリの起動に数秒かかり、その時たまたま負荷が高いと、キューが積み上がり、ユーザエクスペリエンスが損なわれることになる。
• Herokuには、まず新しいサーバ（dynos）を起動させてから３分後にトラフィックを切り替える “preboot” の機能があるし、Puma/Unicorn/HAProxy/Passengerにもこれを軽減するソリューションがあるが、今日は静的なJavaScriptアセットのデプロイの問題を取り上げたい。
• 本番にJavaScriptのファイルの変更がデプロイされるとき、変更前のファイルがパースされた際に付けられたフィンガープリントが変更後は変わるので、一時的に404 Not Foundエラーが返ることがある。（スライド）となると、ダウンタイムをゼロにするには、変更内容が本番アップされる際には、新旧バージョンのアセットがともに数分間本番環境に存在しないと解決できない。
• そこで、RailsアプリのコードはRailsサーバ、JavaScript/CSS/イメージファイルは静的アセットサーバにデプロイする方式はどうか。でも、HTMLページをどうするか？
• HTMLページは静的アセットの本番アッププロセスにあわせてデプロイされるべき。HTMLページはRails側で保持されるべきだが、アップデートはの際は、Railsアプリの再デプロイやRailsサーバの再起動を必要としない仕組みにすべき。
• 各サーバのファイルシステムにHTMLをデプロイする？いや、デプロイ環境においてディスクはエフェメラル（再起動すると消える）であることが多い。Amazon S3に置いて、Railsサーバから読込む？いや、S3はスピードに難あるかも。
• そこで、HTMLをRedisにデプロイしRailsサーバから読込むことにした。既にRedisは使っていたし、スピードと一貫性が担保できる。（スライド）
• このアーキテクチャからすると、JavaScriptアプリとRailsアプリのレポジトリをわけて、別々にデプロイ、バージョン管理をしようというアイデアがうかぶ。JavaScriptを独立したAPIクライアントと考えるとうまくいく。こうなると、JavaScriptのビルドツールは最適なものを自由に選べるようになる。Gulp, Gruntにはじまって、この分野の進化は目覚ましいものがある。
• 自分のプロジェクトでは5分のプロセスが9.94秒に短縮できた。

#rails #javascript #discourse #デプロイ