はじめに
WebアプリケーションフレームワークのRuby on Railsは、2021年12月にバージョン7となりました。これに伴い、クライアントサイド開発のサポートについても大きな変化を遂げ、多様な選択肢が提供されるようになりました。本連載では、このRails 7にフォーカスし、クライアントサイド開発のためのさまざまな機能を、API開発やリアルタイムWeb開発も絡めながら紹介していきます。
対象読者
- Ruby on Railsを長らく使ってきた方
- 他のWebアプリケーション開発フレームワークを使ってきた方
- Railsにおけるフロントエンド開発に関心のある方
必要な環境
本記事のサンプルコードは、以下の環境で動作を確認しています。
-
macOS Monterey
- Ruby on Rails 7.0.1
- Google Chrome 98
Ruby on RailsのこれまでとRails 7
Ruby on Rails（以降、Rails）は、フルスタックのWebアプリケーション開発フレームワークのひとつです。デンマークのプログラマであるDavid Heinemeier Hansson氏（通称はDHH氏）により、2005年12月にバージョン1がリリースされました。名称からわかるように、プログラミング言語にRubyを用いています。最新版は2021年12月にリリースされたばかりのバージョン7です。
RailsはMVCパターンによるフレームワーク
RailsによるWebアプリケーションのアーキテクチャは、MVCパターンに基づきます。MVCパターンとは、アプリケーションの構成要素を「ビジネスロジックを司るモデル（Model）」「UIを司るビュー（View）」「それらの橋渡しを司るコントローラ（Controller）」に分けることで、それぞれの役割を明確にし、独立性を高めるためのデザインパターンです。
多くのWebアプリケーション開発フレームワークと同様に、Railsではこれらをサーバサイドを中心に実装しています。Webブラウザからの要求をコントローラが受けて、それに基づきモデルが処理を実行し、処理結果をビューとしてWebブラウザに返すといった一連の流れは、基本的にサーバサイドで完結します。
MVCパターンとクライアントサイド開発
MVCパターンはRailsの基本ですが、Webアプリケーション開発におけるクライアントサイドの占めるウェイトは、2005年のRailsの登場時から比べるとはるかに増大しています。これは、スマートフォンの普及に伴ってユーザーエクスペリエンスの向上と通信負荷の軽減を求めるニーズが高まったことなどがあります。こうしたニーズには、HTML/CSS/JavaScriptといったクライアントサイドにおける基幹技術の進歩と標準化、Angular/React/VueといったJavaScriptフレームワークの登場が、それぞれ応えてきたと言えます。もちろんWebブラウザも、PC用、モバイル用に関係なく、標準への対応が進んだのも大きいです。
Railsは、このクライアントサイド開発のサポートについて回答を提示してきました。それが後述するアセットパイプラインであり、Webpackerです。これらにより、Railsにおけるクライアントサイド開発は大きく利便性を高めましたが、Rails 7ではさらにWeb技術におけるさまざまなブレークスルーを前提とした、クライアントサイド開発の新たな選択肢が提示されました。開発者は、新しく提供されるライブラリの組み合わせと機能を選択できますが、どれをどのように組み合わせたら目的の機能を得られるか迷うという、新たな問題が発生したとも言えます。
今回を含めた本連載では、Rails 7におけるクライアントサイド開発の新しい選択肢を中心に掘り下げていくことで、この新たな問題の解決の助けとなることを目指します。
SPA/PWAの開発とWeb API
クライアントサイド環境の充実により、従来のページ遷移を伴うアプリケーションではなく単一ページで完結するSPA（Single Page Application）や、Webアプリケーションをネイティブアプリのように端末にインストールしてしまうPWA（Progressive Web Apps）も普及が進んでいます。
これらのアプリケーションでは、フロントエンドはReactなどを使い、バックエンドはAPIとして実装するのが一般的なスタイルです。しかし、Railsではその高い開発効率を生かして、Web APIのためのプラットフォームとして活用することもできます。これを踏まえたRailsのWeb APIモードについても本連載では取り上げていきます。
Railsにおけるクライアントサイド開発サポート
RailsはMVCパターンに基づいたWebアプリケーションフレームワークであること、昨今のWebアプリケーションはクライアントサイド開発の比重が高まっていることを紹介し、Railsがそれに対して回答を続けていることを示しました。ここでは、Railsが具体的にどのようにクライアントサイド開発をサポートしているか、その概略を見ていきます。
Railsバージョンによって異なるサポート
Railsには、初期バージョンからクライアントサイド開発をサポートする仕組みがありました。当初は、公開フォルダである/publicフォルダ以下に置いたJavaScriptファイルやCSSファイルを読み込む仕組みが用意されていただけでしたが、Rails 3.1で「アセットパイプライン」が導入され、クライアントサイド開発のサポートが大きく変化しました。このあとは、Railsのバージョンアップに伴いアセットパイプラインの標準も変化し、現在のRails 7に至っています（図1）。
図1 Railsにおけるクライアントサイド開発サポートの変化
では、アセットパイプラインとは何でしょうか？ Railsの各バージョンにおけるアセットパイプラインの実装に踏み込む前におさらいしておきましょう。
アセットパイプラインとモジュールバンドラー
アセットパイプラインとは、Railsにおけるモジュールバンドラーのフレームワークです。モジュールバンドラーとは、JavaScriptモジュール間の依存関係を解決しながら、複数のモジュール（関数やクラス）を束ねる仕組みを言います。
では、個々のモジュールを直接扱うのではなく、なぜモジュールバンドラーが必要なのでしょうか？ 一般に、クライアントサイド開発では、多数のJavaScriptファイル、CSSファイル、画像ファイルなどが使用されます（これらをアセットと呼びます）。これらを個別に扱った場合、その都度WebブラウザとWebサーバの間にリクエスト・レスポンスのやり取りが発生することになり、パフォーマンス悪化の原因となります。特にJavaScriptファイルやCSSファイルは、比較的軽量であることが多いので、頻繁なやり取りによるオーバヘッドは無視できないものです。これを解決するためにモジュールバンドラーが用いられているのです。
モジュールバンドラーは、JavaScriptファイルやCSSファイルといったファイルを最小化または圧縮して連結します。クライアントサイドでは、この連結されたものを用いることでWebサーバへのリクエスト回数を最小限にして、パフォーマンスの悪化を防ぎます。
アセットパイプラインは、このモジュールバンドラーとしての機能を含めて、下記の機能を備えます。
- 上位言語のコンパイル
- 連結／圧縮
- ファイル名へのダイジェストの付加
- 公開フォルダへの配置
上位言語には、CSSに対するSCSS、JavaScriptに対するCoffeeScriptなどがあります。これらで書かれたスタイルないしスクリプトをコンパイルし、Webブラウザで利用可能なCSSファイルとJavaScriptファイルに変換します（トランスパイルとも言う）。これによってスタイルやスクリプトの開発効率やポータビリティを向上させます。
連結と圧縮では、既述のとおりファイルを圧縮の上連結し、通信の際のパフォーマンスを向上させます。
ファイル名へのダイジェストの付加では、ファイルの内容を走査して求められるダイジェスト（ファイルの内容から計算される文字列）をファイル名に付加し、ファイルの更新をファイル名の変化で知ることができるようにします。
最後の公開フォルダへの配置とは、実際にWebアプリケーションとして公開される場所（/public/assetsフォルダなど）へのアセットの自動的な配置を意味します。Railsでは、/app/assetsフォルダにアセットを置いておけば、あとはアセットパイプラインがトランスパイル、圧縮・連結、ダイジェストの付加、公開フォルダへの配置を自動的に行ってくれるのです。図2は、最初のアセットパイプラインであるSprocketsでの処理の流れを示したものです。
図2 Sprocketsによるアセットパイプライン
最初のアセットパイプライン――Sprockets
既出のとおり、最初のアセットパイプラインはRails 3.1で実装されました（2011年のことです）。使用されたのはSprocketsという汎用のモジュールバンドラーで、Railsへのラッパーであるsprockets-railsというGemライブラリをインストールすることで使用できます。なお、sprockets-railsはRails 7においてもアプリケーション作成時のデフォルトとなっています。-aオプションで後述するPropshaftを指定しない限りは、Sprocketsがインストールされます。
Sprocketsは、アセットパイプラインとしての機能として基本的なものを備えますが、ES6（ECMAScript 6。正式にはECMAScript 2015）登場以前のレガシーなJavaScriptを前提とするなど、機能面での古さが否めません。トランスパイルも、CoffeeScriptやSCSSといったものに限定されます。CSSファイルやJavaScriptファイルのバンドリングを必要としないとか、限られた局面での利用にとどめておくべきでしょう。
スタンダードなWebpackの利用――Webpacker
Rails 5.1からは、Webpackというクライアントサイド開発では定番のモジュールバンドラーをサポートするようになりました（2017年のことです）。これがWebpackerで、RailsへのラッパーであるwebpackerというGemライブラリをインストールすることで使用できます。Rails 5.1ではオプション的な位置付けでしたが、Rails 6においてSprocketsとともにデフォルトとなりました。なおRails 6.xにおいては、JavaScriptはWebpackerでコンパイルする、CSSはSprocketsでコンパイルする、というような使い分けが標準の設定となっていました。
WebpackerはWebpackのRailsにおけるラッパーであるので、その機能のほとんどをWebpackに依存します。WebpackはJavaScriptの実行環境であるNode.jsのモジュールのひとつで、これはすなわちWebpackerの利用にはNode.jsが必須であることを意味します。
Webpackは、モジュールバンドラーとしての機能が基本ですが、ES6で使用可能になったES Modulesによるモジュール形式をサポートします。これに加えて、以下のような特徴も併せ持っています。
- 便利で豊富なツール（ローダーやプラグイン）を備える
- コード変更と同時に画面に反映するホットリロードをサポートする
ローダーは主に変換を担い、プラグインは主に機能拡張を担います。例えばCSSにおいては<style>タグを生成する、使用されるスタイルのみをまとめたCSSファイルを作成する、Dart-Scssという新しいCSSコンパイラを利用する、といったものがあります。JavaScriptにおいてはES6のトランスパイラであるBabelの使用、TypeScriptやCoffeeScriptのためのトランスパイラといったものがあります。特に、新しいES6構文を古いWebブラウザで動くようにトランスパイルするBabelが利用可能なのはWebpackの大きな利点でした。
Webpackerは、Rails 6.1までアセットパイプラインの標準として使われてきましたが、Rails 7においてその位置付けは大きく変わり、標準でインストールされなくなりました。さらに、次期バージョンに相当するWebpacker 6の提供は行われず、Shakapackerという別のGemライブラリによるWebpackのサポートに変わるようです。これは、Rails 7におけるクライアントサイド開発ではWebpackerを前提としないということです。これがどういうことなのか、次で紹介します。
