はじめに
WebアプリケーションフレームワークRuby on Railsは、この10月にバージョン7.1となりました。2021年12月にリリースされたバージョン7.0ではフロントエンド開発環境が大きく刷新されましたが、ほぼ2年ぶりとなる今回のバージョンアップでも、大型の機能が多数追加されて細かな改善も行われています。本連載では、強化・改善された機能から注目度の高いものをピックアップし、その概要を紹介します。
| 機能 | 概要 |
|---|---|
| デフォルトでDockerfileをサポート | 新規RailsアプリケーションでDockerfileが生成されるように |
| Active Recordの非同期クエリの改善 | Active Record APIの改善で非同期クエリの拡張サポートが使用できるように |
| Active Recordでの属性値の正規化 | normalizesで属性値に対して正規化を宣言できるように |
| 複合主キーをサポート | データベースとアプリケーションの両方で複合主キーがサポートされるように |
| 非同期キュー機能の追加 | 大量のジョブを一度にエンキューするperform_all_laterメソッドが使用できるように |
| 認証システム実装用メソッドの追加 | 特定目的でのトークン生成のためのgenerates_token_forメソッドが使用できるように |
| 自動読み込みの拡張メソッドの追加 | 自動読み込みを拡張するconfig.autoload_libメソッドとconfig.autoload_lib_once設定が使用できるように |
| Trilogy用アダプタの導入 | MySQL互換DBクライアントであるTrilogyとRailsアプリケーションをシームレスに統合できるように |
| JavaScriptランタイムBunのサポート | Node.jsに加えてBunも利用できるように |
| 新たなシリアライザのサポート | ActiveSupport::MessagePackが利用できるように |
| テンプレートでの明示的なlocals | テンプレートに渡される変数を明確に制御できるように |
対象読者
- Railsの最新バージョンの機能を把握したい方
- Railsの経験者で、Railsに改めて入門したい方
- アプリケーションフレームワークの最新パラダイムに関心のある方
必要な環境
本記事のサンプルコードは、以下の環境で動作を確認しています。
-
macOS Sonoma
- Ruby（3.2.2）
- Ruby on Rails（7.1.2）
- Visual Studio Code 1.84.0（Ruby LSP 0.4.13, Rails 0.17.8）
複数ジョブのキューイング機能perform_all_laterメソッドの追加
Active Jobは、ジョブ（処理）のバックグラウンドでの実行をサポートするコンポーネントです。定期的に実行され、処理にも時間のかかるファイルのクリーンナップやメールの送受信、画像の加工やデータ集計などをジョブ化することで、処理を自動化したり夜間に実行することでシステムの負荷を軽減したりできます。
Active Jobでは、perform_laterメソッドを使ってジョブをキューに投入していました（エンキュー）。キューとは、ジョブの実行順を管理する仕組みで、基本的には先入れ先出し（FIFO）方式となるバッファーです。perform_laterメソッドの呼び出しでジョブはキューに投入され、setメソッドによるタイミングで実行されます（Active Jobのメソッドにはperform_nowメソッドもありますが、こちらはキューを使わない即時実行となるので、ここでの解説からは除外します）。
perform_laterジョブは便利ですが、ジョブが数千を超えるなど大量にある場合にはエンキューのためのメソッド呼び出しだけでも大きなオーバーヘッドになります。そこでRails 7.1では、大量のジョブを一度にエンキューできるperform_all_laterメソッドが新たに使えるようになりました。
perform_all_laterメソッドでは、複数のジョブを引数で受け取るか、あるいはジョブの配列を生成してそれを受け取ります。ただし、一括エンキューのためのpush_bulkメソッドを実装するキューイングバックエンド（Sidekiqなど）を必要とします。バックエンドによってはデータベースサーバ（Sidekiqの場合はRedis）を必要とするので、別途稼働させておく必要があります。push_bulkメソッドの実装がないバックエンドでは、従来のperform_laterの呼び出しに置き換えられます。
以下は、WebサイトのクローリングのジョブWebcrawlJobを想定した、それぞれの呼び出し例です。
% rails c
# ジョブを個別にエンキューする
> ActiveJob.perform_all_later(WebcrawlJob.new("https://example.com"), WebcrawlJob.new("https://example.jp"))
# ジョブの配列をエンキューする
> crawl_jobs = Weburl.pluck(:url).map { |url| WebcrawlJob.new(target: url) }
> ActiveJob.perform_all_later(crawl_jobs)
上記例のようにジョブ数が少ない場合にはパフォーマンス上のメリットが生じにくいので、ジョブ数との釣り合いで利用を検討しましょう。
MySQL互換DBクライアントTrilogy用アダプターの導入
RailsにおけるMySQLアダプターといえば、長い間mysql2が使用されてきました。Railsで開発されているGitHubでは、独自開発のMySQLアダプターであるTrilogyを使用しています。Trilogyは、Ruby仮想マシンでの効率的な動作のために特別に設計されたMySQLアダプターです。mysql2と比較して性能や柔軟性に優れ、アプリケーションへも組み込みやすいとされることから、GitHubはもとよりShopifyなどでも利用されています。
Trilogyをアプリケーションで使うには、activerecord-trilogy-adapterをGemfileに追加しbundleコマンドを実行した後、以下のようにconfig/database.ymlファイルに設定します（MySQLデータベースが稼働していて、rails_dbデータベースが存在し、ユーザ名とパスワードが適切に設定されている必要があります）。この場合は、production環境でTrilogyを使い、データベース名はrails_db、ユーザー名とパスワード、ホスト名は環境変数から取得し、接続プールは5個という設定になります。
gem "activerecord-trilogy-adapter"
production: adapter: trilogy database: rails_db username: <%= ENV["MYSQL_USERNAME"] %> password: <%= ENV["MYSQL_PASSWORD"] %> host: <%= ENV["MYSQL_HOST"] %> pool: 5
また、DATABASE_URL環境変数を設定することで、上記設定を上書きすることができます。
% DATABASE_URL="trilogy://localhost/rails_db?username=$MYSQL_USERNAME&password=$MYSQL_PASSWORD&pool=5"
