Part3続き
前回の記事では、2010年から2012年までの軌跡を振り返りました📙
今回は2013年から2015年までのRailsの軌跡についてまとめていきたいと思います！✍️
Railsの軌跡 - 第4章
2013年：Rails4.0リリースとTurbolinksの登場
Rails4.0のリリース
2013年6月にRails4.0がリリースされました！主な内容は以下の通りです。
| 機能 | 説明 |
|---|---|
| Strong Parameters | 2012年の事件を受け、セキュリティ対策であるStrong Parametersが標準機能へ。これにより、開発者は「許可したデータ以外は通さない」という安全なコードを自然と書くようになり、Railsアプリの堅牢性が飛躍的に向上した |
| Turbolinksの導入 | 「SPAのように、画面遷移を高速にしたい」。その願いをサーバーサイド主導で叶えるTurbolinksがデフォルトで搭載された。 JSを駆使しなくても、Railsの規約に従うだけでネイティブアプリのようなサクサク感が出せる。この「Rails Way」なアプローチは、多くの開発者を驚かせた |
| 非同期キューの標準化 | ActiveJob（Rails 4.2で完成）の前段階として、キューイングの仕組みが整理され始めた |
| Ruby2.0への対応 | 2013年2月に登場した Ruby 2.0 をフルサポートし、最新のRubyの機能を活用できるようになった |
Turbolinksって何がすごかったの？？
-
通常のWeb（遅い...😑）
- リンククリック → サーバーにリクエスト送信 → サーバーでHTML生成 → ブラウザで再描画
-
SPA（Reactなど）(速い！🚀でも作るのが大変😅)
- リンククリック → APIにリクエスト送信 → JSON受信 → JavaScriptで画面更新
-
Turbolinks（速い！🚀しかもRailsだけで作れる！😆）
- リンククリック → サーバーにリクエスト送信 → CSS/JSは使い回す → 必要な部分だけ差し替え
当時、ReactやAngularなどのSPAフレームワークが台頭し始めていましたが、Railsコミュニティでは「もっとシンプルに、Railsだけで高速な画面遷移を実現したい！」というニーズがありました。
Turbolinksはそのニーズに応え、Rails開発者にとって画期的なソリューションとなりました！
※ ただし、jQueryなどの既存のJavaScriptライブラリとの相性問題があり、多くの開発者を悩ませることにもなりました...😅
Dockerの登場
2013年3月にはDockerが誕生し、Railsアプリケーションの実行環境をコンテナ化して配布する、現在の開発スタイルの基礎がこの年に生まれました。
Dockerについて詳しくはこちらをご確認ください👀
2014年：Rails4.1&4.2リリース | Rails10周年
Rails4.1リリース
2014年4月にリリースされたRails4.1では、開発者の日常的な不満を解消する実用的な新機能が多数導入されました🎉
| 機能 | 説明 |
|---|---|
| Active Record Enums | データベースの数値を、プログラム上ではわかりやすい言葉（active, archivedなど）として扱えるEnumsが登場した 「 status = 1 って何だっけ？」と悩む必要がなくなり、user.active? のように英語を読む感覚でコードが書けるようになった |
| Action Mailer Previews | メール送信機能の開発・デバッグを容易にするAction Mailer Previewsが導入された メールの内容をブラウザでプレビューできるようになり、開発効率が向上した |
|
Spring (アプリケーションプリローダー) |
コマンド実行時のRailsの起動を高速化するツールが標準搭載された テストやマイグレーションなど、頻繁に実行するコマンドの待ち時間が大幅に短縮され、開発者のストレスが軽減された |
secrets.ymlの導入 |
アプリケーションの秘密情報（APIキーやパスワードなど）を管理するためのsecrets.ymlが導入されたセキュリティ管理が体系化され、より安全なアプリケーション開発が可能になった |
enumについて詳しくはこちらをご確認ください📝
私😌「メールのプレビュー機能はたまにしか使わんけど、パッと確認したいときに便利なんよな」
Rails4.2リリース
2014年12月にリリースされたRails4.2では、以下のような新機能が追加されました！
| 機能 | 説明 |
|---|---|
| Active Job | 非同期処理（バックグラウンドジョブ）の標準インターフェースが導入された。これにより、Sidekiqなどのバックエンドを簡単に切り替えられるようになった |
| メールの非同期送信 |
Active Jobを利用して、deliver_later メソッドでメール送信を簡単にバックグラウンド化できるようになった |
| WebConsole | 開発中のエラー画面上で直接Rubyコードを実行してデバッグできる、インタラクティブなコンソールが標準で統合された |
Rails10周年🎊
2004年の誕生から10周年を迎え、シカゴで開催されたRailsConf 2014では、創設者のDHH氏やYehuda Katz氏らがこれまでの10年を振り返り、将来の展望を語る記念すべき講演が行われました。
2015年：次世代への準備を重ねた年
2015年は、従来の「サーバーサイドでHTMLを生成するRails」という枠を超え、「リアルタイム」や「API」といったモダンWebの要求に全方位で応える準備を整えた年でした！
Rails5.0の発表
2015年のRailsConfでDHH氏より発表されたRails5.0は、コミュニティに大きな期待を抱かせました🥳
| 機能 | 説明 |
|---|---|
| Action Cable | 今までNode.jsなどの外部サービスに頼っていたリアルタイム通信を、Railsだけで実現するためのフレームワークが導入されることが発表されたこれにより、チャットアプリや通知機能などのリアルタイム機能が簡単に実装できるように！ |
| APIモード | それまで外部Gem（rails-api）として提供されていたAPI専用モードが公式に統合されることが発表されたこれにより、フロントエンド（ React/Vueなど）とバックエンドを分離したモダンなアプリケーション開発スタイルに正式対応した |
APIモードって何がいいの？😵💫
従来のRailsとAPIモード、何がどう違うんだろう？？
-
従来のRails（フルスタックモード）
- コントローラーはHTMLレスポンスを返すことが前提
- ビューやアセットパイプラインなど、フロントエンド関連の機能が多数含まれる
-
APIモード
- コントローラーはJSONレスポンスを返すことが前提
- ビューやアセットパイプラインなど、フロントエンド関連の機能は含まれない
- 軽量で高速なAPIサーバーを構築可能
APIモードを使うことで、フロントエンドとバックエンドを明確に分離した設計が容易になり、モダンなWebアプリケーション開発に最適化された環境が提供されました🎉
Rails5.0 β版リリース
2015年12月にはRails5.0のβ版がリリースされ、長年使われてきたrakeコマンドがrailsコマンドに統合されました。
rake db:migrateがrails db:migrateと書けるようになったのはこの時からです。
エコシステムの変化
-
Reactの台頭
- 2013年にFacebookが開発した
Reactが急速に普及し始め、Railsを「APIサーバー」として使い、フロントエンドをReactで構築する構成が増え始めた時期でした。
- 2013年にFacebookが開発した
-
Webpackerの登場
-
RailsアプリケーションでモダンなJavaScript開発を容易にするためにWebpackをどう導入するかが議論され始めました🤔
-
DHH氏は「The Rails Doctrine（Railsの教義）」を整理し、シングルページアプリケーション（SPA）全盛期にあっても、Railsのフルスタックなアプローチがいかに生産的であるかを改めて強調しました。
Part5へ続く
次回は2016年から2018年までの軌跡を振り返ります📙
だんだんと最近の話題になってきてワクワクしてきました！
参考記事