はじめに
この記事は、最新のRuby on RailsをキャッチアップしたいRailsエンジニアのアドベントカレンダー2日目です。
最新のRailsの動向を理解するためにまず、Ruby on Railsバージョン5以降の変遷について、その背景とともに整理してみます。
※注意 本記事には筆者の主観に基づいた意見や事実とは異なるかもしれない解釈が盛り込まれる可能性があります。
Rails5
リリース時期: 2016年6月
時代背景
アプリケーション開発におけるリアルタイム機能の重要性が増していった時期だと記憶しています。
メールのような非同期なコミュニケーションではなく、TwitterやLINEのようなリアルタイムに情報が更新されるアプリケーションにユーザーが段々と慣れ始め、多くのアプリがそれに追随していきました。
また、アプリケーションのフロントエンドとバックエンドを分けて開発する今では当たり前の構成も、まだそんなにメジャーではなかったように思います。Railsでビューもサーバ機能も全て作る「モノリス」と呼ばれる形で開発してきたIT企業が、React + Railsという構成に変えていく時期でした。これにより複雑化するフロントエンドに対処できるほか、異なるプラットフォーム（ウェブ、モバイル、デスクトップ）で共通のバックエンドを活用できるため、開発の柔軟性が向上するというメリットもありました。
Rails5のリリースは、これらのトレンドに対応し、開発者が現代のウェブアプリケーションの要求に迅速に対応できるようにするためのものでした。メッセージを送信したら相手の画面にも即座に反映されるようなリアルタイム性を求められる機能の作りやすさを重視したり、APIとしてのサーバというアプローチを取りやすくすることで、Railsはより動的でインタラクティブなアプリケーションの開発を容易にし、同時に開発プロセスを高速化しました。
目玉機能
ActionCable
リアルタイム機能を実装するための機能群。これにより、チャットアプリケーションや通知システムなど、リアルタイムで更新が必要な機能の実装が容易になりました。
それまではWebSocketsというリアルタイム機能を作成するための複雑な仕組みを扱うプログラムやJavaScript、関連するGemなどを駆使しないとできていなかったものが、Railsの枠内でできるようになったことに衝撃を受けました。
APIモード
Rails5からはAPI専用のアプリケーションモードが導入されました。このモードでは、フロントエンドにJavaScriptのライブラリ/フレームワーク（例えばReactやAngular）を使用し、バックエンドはRailsでAPIを提供するようなアーキテクチャを簡単に構築できます。
Rails6
リリース時期: 2019年8月
時代背景
Rails5がリリースされた2016年からさらにフロントエンドの進化が加速し、フロントエンドとバックエンドを分けて開発する形が一般的になりました。具体的には、React、Vue.jsなどのライブラリ、フレームワークでの開発が一気に増えた印象です。
また、スマートフォン、タブレット、デスクトップなど、さまざまなデバイスでのウェブアクセスが増えました。これらのデバイスごとに最適化された体験を提供する必要が生じ、ウェブ開発の複雑さは増加していきました。
ユーザーもiOS/Androidのネイティブアプリに慣れているため、ToBを中心としたWebアプリケーションにも快適な、わかりやすい、サクサク動くウェブ体験を求めるようになりました。これにより、アニメーション、動的なコンテンツ、リアルタイムのデータ更新など、複雑なフロントエンド機能の実装が求められました。こうした機能は決して自己満足的なものではなく、競合に勝つための重要な要素となりました。
そして、ユーザーの目が肥え競争も激化する中で複雑なビジネスロジックやデータベース操作、API統合も必要となっていき、これに伴いバックエンドの開発も複雑化しました。
目玉機能
そんなRails6の目玉機能は以下の通りです。
Action Text
よくブログサービスなどで見るテキストエディタをRailsアプリケーションに簡単に統合する機能です。これにより、ユーザーがウェブサイト上でテキストコンテンツを編集することが容易になりました。
Action Mailbox
受信メールをRailsアプリケーション内で直接処理できるようにする機能。これにより、メールベースのワークフローや顧客サポートシステムを簡単に統合できるようになりました。
Parallel Testing
テストの実行時間を短縮するための機能。テストを並列で実行することにより、大規模なアプリケーションのテスト時間を大幅に短縮できます。
Webpacker by Default
JavaScriptのモジュールバンドラーとしてWebpackerがデフォルトで採用されました。これにより、JavaScriptやCSSなどのフロントエンドの資産をより効率的に管理し、最新のフロントエンドフレームワークとの統合が容易になりました。
Multiple Database Support
複数のデータベースに対応する機能。これにより、大規模なアプリケーションや、異なる種類のデータベースを使い分ける必要があるアプリケーションにとって、データベースの管理が容易になりました。
個人的にはWebpackerが当たり前になり、開発のセットアップが複雑になったなと感じました。Node.jsのバージョンまで気にする必要がでたり、Dockerを使った環境構築やSPAへの対応など、追随するのが大変でした。
こうして書いてみて改めて思うところがあります。それは、SPA開発が興隆していった中でのAction Textの登場はややチグハグだということです。
なぜなら、世間が「フロントはJavaScriptで良いよね」という空気感なのにAction TextはモノリスのRailsアプリで使うような機能だからです。
詳しくは後述しますが、Railsの開発チームの考えはこの頃から「フロントエンドとバックエンド分けて開発するのってタイパ悪くね？」「やっぱりアプリ作るのに複雑なJavaScriptって要らなくね？」となっていたのだなと思います。
Rails7
リリース時期: 2021年12月
背景
この時代、JavaScriptを使ったWebアプリの見た目の作り込みがより複雑になっており、もっと手軽で効率的な方法はないのか、と思ったエンジニアも多かったはずです。それを反映してか、Rails7ではウェブサイトの作成をシンプルにし、ページが速くスムーズに動くようにする新機能が加えられました。特に見た目を作る部分で新しいアプローチが取り入れられ、これまでの容量が大きすぎてパフォーマンスを害しかねないJavaScriptツールを使わずに、もっと簡単に美しいデザインを作れるようになったのがポイントです。
Rails6までのチグハグさが無くなり、ポピュラーなSPA開発とは違う道を行くことを明らかにしたバージョンです。
目玉機能
Importmaps
Rails7では、JavaScriptモジュールを簡単に管理できるようにするためのImportmapsが導入されました。これにより、Webpackerやその他のモジュールバンドラーに依存せず、ブラウザネイティブのJavaScriptモジュールローディングを利用できるようになりました。
Hotwire
SPA的なUIを実現するためのライブラリ群で、TurboとStimulusに大別されます(本当はもうちょっとある)。これにより、SPAのようなリッチなユーザーエクスペリエンスを、JavaScriptを最小限に抑えながら提供できるようになりました。
Tailwind CSSなどCSSフレームワークの統合
Rails7からは、CSSフレームワーク「Tailwind CSS」が簡単に導入、他のCSSと組み合わせられるようになりました。これにより、デザインの実装が容易になります。
終わりに
これから調べること
Railsが辿ってきた変遷に出てくる言葉1つ1つを説明することは紙幅的にも時間的にも不可能でした。
以下に示す参考記事を読めばより詳しい情報を得ることができるので、気になった方はそちらもご参照ください。
参考記事を読んでいく中で、何を知らなければいけないのか、どのように学んでいけば良いかのアイデアを得ることができました。アウトプット前提で調べることのメリットですね。
ここまでRails7について調べて様々な記事を読む中で、以下の言葉が特に重要に感じました。
- importmap
- hotwire
- MutationObserver
抽象度の違う言葉たちですが、Railsが目指しているものを理解するために必要だと思われます。
ここからは実際にRails7のアプリを作りながら具体的な使い方を学び、前述した言葉たちを自分なりに説明できることを目指します。
参考に読んだ記事
Rails 7.0: Fulfilling a vision
TURBO Handbook
Rails7がもつフロントエンドへの「答え」
Re: Rails を主戦場としている自分が今後学ぶべき技術について
STIMULUS Handbook
妄想的DHH理解