RailsはGithubで8.0のマイルストーンを公開し、次のRailsのリリースに向けた目標を示しています。新しいバックグラウンドワーカー、キャッシュバックエンド、アセットパイプライン、モバイルデバイスに通知をプッシュするフレームワーク、そして大量の開発ツールが同梱されています。
Railsの信念のひとつは「モダンなWebアプリケーションの複雑さを圧縮する」であり、これは技術的な言い方をすれば「Webアプリケーションをもっと簡単に構築できるようにする」ということです。Rails 8はこの伝統を受け継ぎ、Railsを本番環境で実行するのに必要なインフラや「可動部分」を減らしています。また、Rails開発者がネイティブ・モバイル・アプリケーションに匹敵する機能を備えたプログレッシブWebアプリケーションを簡単に公開できるようにすることで、アプリストアの産業的な複雑さに対抗しています。
プロダクションでの可動部分が少ない
Redisは高速で信頼性の高いソフトウェアであり、長年Railsスタックの定番となっています。その安定性にもかかわらず、Redisは監視が必要で障害が発生する可能性のある依存関係であることに変わりはありません。キーエビクションという言葉を聞いたことがありますか？デフォルトのRails 8アプリを公開すれば、その意味を知る必要はありません。
Rails 8ではNVMeソリッドステートドライブのおかげではるかに高速になっていることを前提に、Redisからデータベースに多くのワークロードをシフトすることで、Redisへの依存を減らしています。
Solid CacheとSolid Queue
Solid CacheとSolid QueueはRails 8に同梱される2つの新しいソフトウェアライブラリです。どちらもデータベース上に構築されており、キャッシュやバックグラウンドジョブにRedisを使用するライブラリを置き換えるように設計されています。
これらはRedisでバックアップされたワーカーキューやキャッシュと同じくらい速いのでしょうか？いいえ、一般的にはRedisがメモリにデータを保存するのに対し、データベースはディスクにデータをコミットする必要があるので遅くなりますが、NVMeソリッドステートドライブのおかげでデータベースのディスクははるかに高速になったので、ほとんどのRailsアプリのキャッシュとワーカーキューのワークロードを処理するには「十分速い」です。
HTTPリクエストのレート制限など、まだRedisの必要性がある場合もありますが、ほとんどの場合では本番のRailsデプロイメントではRedisをまったく使わなくても大丈夫です。
データベースをバックアップしたActionCable WebSocketブロードキャスト
PostgresとMySQLにはWebSocket経由でWebブラウザにメッセージをブロードキャストする機能が搭載されています。Rails 8にはデータベースを使用して接続されているすべてのクライアントにメッセージをブロードキャストする新しいActionCableアダプタが同梱され、Redisへの依存がなくなります。
データベースはpub/subを主なユースケースとして設計されていないため、制限がある場合があります。たとえば、Postgresのデフォルトの最大ペイロードサイズは8000バイトであり、これは大きなHTMLペイロードをワイヤ経由でプッシュしようとするアプリケーションにとって問題になる可能性があります。
幸運にもRails 8にはTurbo 8ページモーフも同梱されており、モデルが変更されたという事実を公開するだけなので、デフォルトのペイロードサイズ制限に達する可能性は低く、サーバはHTTP経由でHTMLを再読み込みする必要があります。
Sprocketsに代わるPropshaft
WebアプリケーションはCSS、JavaScript、画像アセットを迅速かつ効率的に提供する必要があります。これを行う最も効果的な方法の1つはアセットを"フィンガープリント"し、有効期限のないキャッシュヘッダでそのフィンガープリントを提供することです。
これはまさにPropshaftが行うことです。/images/foo.pngの画像をダイジェストし、/images/foo-586e0b396456675e08bba21db5941a3099b07766084e51400576f7622c5217cc.pngのようなURLを生成します。
Sprocketsは2009年にRailsに搭載されたオリジナルのRailsアセットパイプラインで、webpackのようなJSベースのアセットパイプラインよりも前のものです。そのためSprocketsはSCSSをCSSにコンパイルしたりJavaScriptを最小化したりといった今日のesbuildのようなアセットパイプラインが行う重い作業をすべて行わなければなりませんでした。
今は2024年でほとんどのブラウザがアセットパイプラインなしでJavaScriptとスタイルシートのアセットを効率的にダウンロードできる、あるいはesbuildのようなより高性能なパイプラインが使える世界です。Railsに必要なのは画像や動画、その他のメディアファイルのフィンガープリントURLを生成することだけです。Propshaftが導入されたのはそのためです。CSSとJavaScriptのコンパイル作業から手を引き、最新のブラウザかesbuildのようなより高性能なアセットコンパイラに任せるのです。
ネイティブアプリの代わりにプログレッシブウェブアプリを公開
macOS Sonoma、iOS 17、iPadOS 17はネイティブアプリを必要とせず、ウェブアプリケーションをオペレーティングシステムとよりよく統合することを可能にする「プログレッシブ・ウェブ・アプリケーション」機能を搭載して公開されました。
プッシュ通知
ネイティブアプリケーションを公開する大きな理由の1つは通知でした。たとえば、Railsのチャットアプリでは@userで言及されたときにユーザーに通知してメッセージに返信できるようにする必要があるかもしれません。
Safariの最新バージョンではついにWeb通知機能が導入され、Railsでフレームワークに組み込むことが可能になりました。つまり、ネイティブのiOSアプリケーションをインストールすることなく、モバイルのウェブ通知が可能になりました。
ウェブ通知が既存のgemを使うのか、Railsチームが独自に開発するのかはまだ明らかになっていません。
ホーム画面またはドックへのウェブページの追加
iPhoneやiPadのホーム画面にウェブページを追加する方法が改善され、ドックにウェブページを追加してアプリとして表示できるようになりました。
これはWindowsやAndroidではしばらくの間行われていたことですが、Appleがついにきちんとしたサポートを提供し、アプリを配布するための現実的なチャネルとなったのは喜ばしいことです。
豊富な開発ツール
Rails 8にはRailsアプリケーションの開発とデプロイを容易にするデフォルトツールが多数追加されています。
Kamalを使ったデプロイ
Kamalはrails newを実行するときのデフォルトとして採用されています。Kamalはデプロイツールで、ロードバランサやHTTPS証明書、Dockerなどの管理に慣れていれば、Railsアプリケーションをメタルサーバにデプロイできるようになります。
Fly.ioへのデプロイにKamalは必要ありません。Fly.ioはHTTP証明書を扱うために必要なロードバランサとツールを提供しているからです。
HTTPベーシック認証ジェネレータ
Rails 8にはRailsアプリケーションにHTTPベーシック認証を追加するコードジェネレータが同梱されます。これまではサードパーティのgemや数行のRubyコードで可能だったので、フレームワーク初心者で実装の指針がもっと必要な人にとっては嬉しい追加となるでしょう。
ベンチマークツール
共通のベンチマークツールはホスト間の限定的な比較（apples-to-apples）を可能にします。これらのベンチマークの目的は特定のアプリケーションが本番環境でどのように動作するかを理解することではありません。むしろディスク速度、ネットワーク、その他のサーバ性能の側面をテストするスイートであり、開発者がRailsアプリをどこにデプロイするかについてより多くの情報に基づいた決定を下すのに役立ちます。
Rails 8の言語サーバー
言語サーバーはZed EditorやVS CodeなどのIDEに対して、コーディング中にオートコンプリートのポップオーバーに何を表示するかを指示します。Rails 8ではActiveRecordバリデーションなどのRailsコンストラクトのオートコンプリートを提供する言語サーバーが公開される予定です。
Rubocop
リンターが好きな人のために、Rails 8にはRuboCop Omakaseが同梱される予定です。あなたやあなたのチームが好きなRubyのフレーバーにカスタマイズできます。
Githubとの統合
Rails 8のプロジェクトには.githubフォルダーが用意され、CIやプルリクエストテンプレートなどGithubでの一般的なワークフローを実行するためのすべての設定が行われるようになりました。
Devcontainers
Devcontainersは、Dockerファイルと設定ファイルを介してローカルワークステーションに開発環境をセットアップするスクリプトのセットです。
macOSの場合、ファイル数の多い大規模なRailsプロジェクトではDocker Desktopのハイパーバイザーのパフォーマンスによって開発環境が桁違いに遅くなるという問題が発生する可能性があるので注意してください。
HTTP/2サポートの向上
Railsはいくつかのアップグレードにより、より良いHTTP/2サポートへのゆっくりとした歩みを続けています。
Rack 3
RackはRailsのようなRubyウェブフレームワークとPumaやFalconのようなウェブアプリケーションサーバーの間に位置する低レベルのHTTP APIです。Rack 3はHTTP/2用のより良いAPIを搭載しており、以前のバージョンのRackでHTTP/2を動作させるために必要だったハックのいくつかを一掃しています。
ThrusterでのHTTP/2
ThrusterはRailsアプリ用のDockerfileで、HTTP/2をサポートしていないウェブホスト用のHTTP/2プロキシが含まれています。Fly.ioにアプリをデプロイする場合はFlyのアプリケーションプロキシが追加の設定なしでHTTP/2をサポートしているので、これは必要ありません。
ActiveModel のドキュメント
ActiveModelはActiveRecordから抽出されたAPIで、RubyのオブジェクトをActiveRecord のモデルのように動作させることができます。このAPIは以前から存在していましたが、Rails 8でようやくそれにふさわしいドキュメントが提供されるようになりました。
まとめ
Rails 8はRailsアプリに含まれるデフォルトのツールを大幅に拡張し、Redisのようなプロダクションサービスの依存関係を不要にする新しいフレームワークを導入する大きなリリースになりそうです。これまで通り、新しいRailsアプリを作成するときや後でgemsを取り出すとき、気に入らない部分を削除することはできます。
全体として、Rails 8で提供される機能のほとんどはアプリの初期段階で本番インフラについて考える必要性を遅らせるでしょう。そのため、Web開発に慣れていない人にとって決断すべきことが少なくなり、Railsがより親しみやすくなります。
