config.load_defaults 7.1 使用時、ActiveSupport::MessageVerifier と ActiveSupport::MessageEncryptor のデフォルトシリアライゼーションが Marshal から ActiveSupport::JSON に変更され、既存の Marshal メッセージも引き続き読み取り可能ActiveRecord::Base.serialize はデフォルトで YAML を使用しないように変更され、従来のデフォルト値は config.active_record.default_column_serializer = YAML で復元可能- 新しい
7.1 キャッシュフォーマット が追加され、新規アプリのデフォルトとして使用される。既存アプリでは config.load_defaults 7.1 または config.active_support.cache_format_version = 7.1 で有効化可能
6.1 または 7.0 キャッシュフォーマットで書き込まれた項目は 7.1 フォーマットでも読み取り可能- Rails 7.1 のローリングデプロイでは、最初のデプロイではキャッシュフォーマットを維持し、その後のデプロイで
7.1 キャッシュフォーマットを有効化する必要がある
:message_pack および :message_pack_allow_marshal シリアライゼーションが MessageEncryptor、MessageVerifier、config.active_support.message_serializer に追加され、msgpack gem >= 1.7.0 が必要ActiveSupport::KeyGenerator、MessageEncryptor、EncryptedConfiguration、Active Record 暗号化オブジェクトの inspect で 秘密値の露出 を防ぎ、ActionView::Helpers と ERB::Util の XSS 保護も強化has_secure_password に password_challenge 検証と #{attribute}_salt メソッドが追加され、authenticate_by もアカウントの存在有無によるタイミングベースの列挙攻撃を減らすために追加- Active Record における 複合主キー・複合外部キー 関連のサポートが拡張され、タプル構文
where、複合キーのバッチ整列、スキーマからの複合主キー推論をサポート
- PostgreSQL サポートには enum 名変更・値追加・値変更のマイグレーションコマンド、exclusion constraint、unique constraint、
INCLUDE インデックスオプション、NULLS [NOT] DISTINCT インデックスのサポートが追加
- SQLite3 アダプタは Write-Ahead-Log normal syncing mode、capped journal size、shared memory buffer、shared cache 設定により平均 2× の性能向上が明記され、double-quoted string literal を無効化する strict strings mode がデフォルトで有効化
- Active Record の全テーブルバッチ反復はデフォルトで range iteration を使用して性能が改善され、PostgreSQL の 1000 万レコードテストでは querying
253s→30s、updating 288s→124s、deleting 268s→83s という結果が示されている
MemCacheStore と RedisCacheStore の connection pooling がデフォルトで有効化され、無効化するにはキャッシュストア設定で pool: false の指定が必要Trilogy データベースクライアント用アダプタが追加され、adapter: trilogy または trilogy:// 形式の DATABASE_URL を使用可能ActiveRecord::QueryLogs のデフォルトタグ形式が SQLCommenter 形式に変更され、config.active_record.query_log_tags_format = :legacy で従来形式を使用可能- 非推奨化および削除項目として、
ActiveSupport::Deprecation シングルトンの使用、SafeBuffer#clone_empty、#merge の rewhere 引数、add_foreign_key の deferrable: true、TestFixtures#fixture_path、複数の非推奨 Active Record 設定および API の整理を含む
- Action View テストに
ActionView::TestCase.register_parser が追加され、レンダリング結果パーサーを登録できるようになり、デフォルトパーサーとして :html と :json を提供
1件のコメント
Hacker News の意見
Rails は素晴らしいし、今はこれまで以上に良くなっている
キャリアの初期には主に Django と Laravel を使っていて、その後、最近よくあるフロントエンド作業に移り、今年また Rails + Hotwire のプロジェクトを担当することになった
どれほどシンプルになっているかに心から驚いたし、ここまで簡単にできるということを大半の人が忘れてしまっているのが残念。今この業界に入ってくる人たちは、こうしたシンプルさを経験できないかもしれないという点も怖い
Rails を使ったことがない、あるいは「PHP は醜い / Rails は死んだ / JavaScript は汚い」といった話だけを聞いて手を出さなかったのなら、少しの間他人の言うことは無視して、オープンな気持ちで一度試してみることを勧める
同じリポジトリでエンジニア 1,000人が働く環境には最善ではないかもしれないが、小規模チームには競合がなく、他のものよりはるかに先を行っている。正直、Laravel くらいは同じくらい良いかもしれない
初期開発のスピードでは Rails が常に勝つと思う。規約が非常に緻密でよく設計されているので、同じようについてこられるものはほとんどない。Laravel は追いつきつつあるが、まだだと思う
ただし LiveView はあらゆる意味でよりよくスケールする。認証、データベースアクセス、ジョブキュー、メーラー、完全なテストツールなど標準提供も多く、直接 JavaScript をほとんど書かなくて済み、優れた仮想マシンである BEAM もある
少なくとも、こうしたプロジェクトがみな「一歩引こう」という戦いをしてくれているのは良い。職場では React と Relay を使っているが、フロントエンド JavaScript を長く使ってきて、ある程度できると思っていても、越えるべき障害物が多すぎて疲れる
仕事が見つからないので経験も十分に積めず、結局そうした魔法使いたちに押し負ける。その求人は12か月以上出たままになっていることもある
代わりに需要のあるところなので、世の中に JavaScript をさらにばらまいている
構造的には ember-data のアプローチが気に入っている。データセットの左結合/右結合のような作業で自動化できる部分が多く、統合されたモックサーバーもある
ただ、あまりにうまく動くせいか、他のものほど格好よくは見えないようだ
https://emberjs.com/
13,000行の Rails 7.0 アプリを 7.1 に上げたが、7.0 と 7.1 の差分[0]を除けば、テスト設定コードを1行変えただけで全部動いた
簡単なアップグレードパスという面では成功だと思う。これから面白い部分は、7.1 の新機能を使うよう一部のコードをリファクタリングすることだ
興味があれば、Rails / Docker のサンプルアプリも 7.1 に上げてある https://github.com/nickjj/docker-rails-example
Rails 7.1 に Dockerfile が含まれるようにはなったが、Docker Compose を使って開発と本番でそのまま動く体験を作り、Postgres、Redis、Action Cable、Sidekiq などを含めるといった形で、依然として追加できる選択肢は多い
[0]: https://railsdiff.org/7.0.8/7.1.0
かなり大きな Rails 6のコードベースにReactが大量にくっついている状態から、Hotwireを使う新しい「非」JavaScript方式へ上げようとしているところ。幸運を祈ってほしい
Railsはデフォルトを守っている間は素晴らしいが、そのデフォルトから外れた瞬間に苦痛の地になる
フロントエンドエンジニアを採用するなら、React候補者の層は桁違いに大きい。一般的な作業に使えるバニラJavaScriptパッケージを見つけてStimulusコントローラで包むのも、Reactパッケージを探すよりだんだん難しくなっている
Stimulusはコントローラ単位テストを書く方法も特に提供していない。Reactならいつも通りjestとreact-test-rendererを使える
さらに最近のTurbo TypeScript論争は、Hotwireエコシステムの長期運用への信頼を与えるものではなかった
まだ決定はしていない。Stimulusがフロントエンドコードを書く非常にRailsらしい方法に感じられるのは間違いなく利点で、すでにRailsに慣れている小規模チームでは特にそうだ
アプリケーションがかなり単純でフレームワークの流儀によく合うなら、フレームワークは素晴らしい。より複雑で柔軟な構成が必要なら、ライブラリを見るべき
今はslimでサーバーサイドレンダリングをするか、API専用にしてフロントエンドを分離している
RailsはJavaScriptをやろうとして、CoffeeScript、アセットのプリコンパイル、webpackなど、あまりに何度も方向転換してきた
参考までに、Rails 7+でシングルページアプリのJavaScriptを扱う方法も以前よりずっと合理的になっている。実質的には好きなビルドツールをRailsアプリと切り離して使えばよい
開発中は
rails sと一緒にyarn build --watchのようなものも実行する必要があるが、個人的には悪くなく、ずっとシンプルになると思う私たちの会社はRailsアップグレードを自動化するソフトウェアを作っており、Railsアップグレードを代行するフルサービスも提供している。興味があれば steve (at) infield.ai まで連絡するか、https://app.infield.ai/users/sign_upで無料のRailsアップグレード計画を作成できる。クレジットカードは不要
詳細は https://docs.infield.ai/docs/creating-an-upgrade-path を参照
私の場合は、ほぼ webpackの代替のようにすぐはまった
Railsが好きで、Rails 2の頃から断続的に使ってきた
とても良いフレームワークで、たまにWebサイトを立ち上げる必要がある私のような人間にとっては、本当に 最も抵抗の少ない道
ただ、新しいノートPCでRailsを動かせるようにセットアップする過程がつらい。nodeが必要で、そうするとnpmも必要になる。バックエンド開発者なので、nodeをどうセットアップすべきか、どの順番でやるべきかよく分からない
頻繁にやることではないので、毎回格闘しているように感じる。最終的には何とかなるが、なぜ最後にすべて噛み合ったのかはいつも確信がない
必要なものをまとめて整えてくれて、railsがそのまま動くようにしてくれるインストーラがあればいいのに。rvmのインストーラはrubyの上にrailsをセットアップしてくれるが、その下のnodeシステムまではセットアップしてくれない
https://asdf-vm.com/
Nodeは主にフロントエンドツールとして知られていてRailsもその用途で使うが、記憶ではNodeは少なくとも当初、JavaScriptランタイムをバックエンドへ持ち込もうとして作られた
パッケージマネージャなしでも、Windowsでは単にnode.exeで、npmをダウンロードして展開し、nodeとnpmをPATH環境変数に入れればよいはず
それにnodeのインストールはかなり簡単。というか簡単すぎる。もっとずっと難しくて、学位が必要なくらいだったらよかったのに
JavaScriptは他のものと同じく、ただの道具にすぎない。好きであれ嫌いであれ非常に重要な道具であり、好きであれ嫌いであれ長く残るだろう
少し心を開いて、少なくとも基本を学んでみれば、作業はもっと楽になるはず
Rails + HTMXと、非常にインタラクションの多いページにだけ少しJavaScriptを振りかける方式が再び盛り上がってほしい
RailsをSlim/HAMLと一緒に使うのは本当に楽しい。望むなら
ViewComponentsのようなライブラリで部分レンダリングをさらに簡単にすることもできる。そこにWeb Componentsを加えればかなりインタラクティブなページを作れるし、特定のページで本当に必要ならReactも使えるHATEOASはアプリケーションの複雑さを大きく減らしてくれる。それでもAPIが必要なら、異なるMIMEタイプに応答するのも非常に簡単で、望むなら同じエンドポイントを共有することもできる
経験上、Reactを使っているアプリケーションの大半は、実はReactがまったく必要ない。いくつかのポップアップメニューのためにReactを使っている
だからReactなし、あるいはごく少しだけReactを使う大きなアプリが出始めれば、今日の私たちのアプリケーションがどれほど不必要に複雑なのかに気づく人が出てくることを願っている
ところがすでに「みんなReactを使っているからReactに変えるべきだ」という話を見ている。ため息が出る
夢を見ることはできる
公式発表はこちら: https://rubyonrails.org/2023/10/5/Rails-7-1-0-has-been-released
もう少し高レベルな詳細があり、新しい変更点のいくつかを試すのが楽しみ。特に新しい非同期クエリメソッドは、手早い性能改善にかなり役立ちそう
バックエンドにおける Rails は、受けるべき評価を十分に受けていない
ただしフロントエンド側は、非常に長い間ひどい状態だった
今は Rails 7.1 + Hotwired + Importmaps の組み合わせで作業するのが楽しい
しかし、ブラウザで少なくとも ES6 と Import Maps のサポートが良くなるまで待つ必要があった
この記事の日付を見ると、https://web.dev/import-maps-in-all-modern-browsers/ では、2023年3月28日にすべてのモダンブラウザで importmaps が使えるようになったと発表している
だから今までは Webpack、Yarn、その他の JavaScript 補助ツールを避ける方法がなかった
今では importmaps があり、ブラウザの ES6 サポートも十分に良いので https://caniuse.com/?search=es6、追加ツールはほとんど不要でモダンな JavaScript を使える
数週間前、友人が「Rails のリリースが発表されたのに君がアップグレード PR を出していなかったら、それは本当に起きたことなのか？」と冗談を言っていた
さて、そろそろ PR を出す番だ。数か月待機中の 7.0 PR の後ろに積むことになっても
経験上、多くのチームは ActiveRecord でクリーンなコードベースを作るのに苦労している
叩かないでほしいのだけど、まだ Rails 4.2 を使っていて満足している
自分でやる、あるいは B2B 企業向けにやる、JavaScript なし、または少なめのバックエンド SaaS 作業に必要なものはすべて提供してくれるし、低スペックの VPS でも動く
もし答える時間があれば、なぜアップグレードすべきなのか知りたい
古いバージョンの主な問題は、紐づいている gem の脆弱性。たとえば nokogiri は Rails のメジャーアップグレードなしでは上げられない場合がある
ただし、ほとんどのアプリはたとえば複雑な XML パースをしないので、脆弱性のかなりの部分は該当しない。なので安全かどうか確認するためのメンテナンスが少し必要になる。バグを防ぐためにモンキーパッチを入れることもよくある
アップグレードすればセキュリティが向上し、メンテナンス時間が減る。とはいえ、継続的なアップグレードのコストも考慮する必要がある。もう一つの要因は、新しいバージョンではより高速な Ruby のサポートを受けられること
通常 Rails アプリを作るときは最新リリースを使うが、かなり人気があるか、アプリが非常に古くて新しいシステムで何かが動かない場合でなければ、その後の Rails バージョンは上げない