見出し画像

railsのバージョンアップデート作業で思ったこと

昭和のオッサン

つい最近railsアップデート作業を行いました。

やったことは

rails5.0系からrails7.2へのアップデートとrails8への準備です。

最近の私はweb3の開発に力を入れていて、solidity・python・rustのコードを触ることが多く、rails（ruby）はアップデートをしないまま古いバージョンを使っていました。

しかし、さすがにrails5.0系は今の時代だと古過ぎて、開発環境構築にも苦戦するようになってきたので、重い腰を上げてrails update作業をすることにしました。

その作業をしながら思ったことは

railsは現在のweb開発のニーズに合わせた良い進化をしている

ということです。

web2のバックエンドサーバー機能に限定すれば

2024年時点で一番優れたwebフレームワーク

と言えるのではないでしょうか(次点はJavaのspring)。

ここ数年はpython・rust・ goを中心に使っていたこともあって、これらの言語のwebフレームワークにはないrailsの優秀さを再認識することになりました。

というわけで今回は

railsのバージョンアップデート作業で思ったこと

について記載します。

具体的には

  • 時代の流れとrailsの変化

  • railsの価値を決定付けた機能

  • 今後のrailsで気になっていること

について記載します。

時代の流れとrailsの変化


railsは20年の歴史があるwebフレームワークです。

railsが初めて登場した時、当時のweb開発ではstruts(java)がスタンダードなwebフレームワークとして君臨していました。

strutsはその当時に注目されていたアークテクチャであるMVC(model, view, controller)を採用していて、xmlで記述した設定ファイルを書くことで、それまでjspで細かい実装が必要だった汎用的な処理をフレームワークである程度やってくれるという画期的なwebフレームワークでした。

加えてstrutsはjava製だったので、OSに左右されずに開発・動作させることができました。

現在のITエンジニアは、Macを開発機として利用することがほとんどですが、Snow Leopard登場前は、Macは開発者にあまり人気がなく、windowsで開発をすることが一般的でした。

そのような環境の時代背景もあり、java製のwebフレームワークであるstrustsは爆発的に普及しました。

しかしそんなstrutsにも問題がありました。

それは

プロジェクトが大きくなると設定ファイルが肥大化する

ということです。

strutsではMVCコードの設定をxmlに書く必要があったので、設定項目や設定ファイルが多くなって複雑になり、プロジェクトが複雑になるという問題がありました。

そんな時に新しいwebフレームワークとして登場したのが

rails

です。

railsはそれまでのwebフレームワークの欠点を克服するために

設定より規約

という考え方を導入しました。

この考え方は

開発者が個々に設定ファイルを作成するよりも、あらかじめ規約で縛ってしまった方が、結果的にプロダクトがシンプルになり開発効率も高まる

というそれまでの考え方を否定する新しい考え方でした。

具体的な規約としては

  • ArticleのテーブルはArticlesと複数形にする

  • APIのarticles/:id はコントローラーArticleControllerのshowメソッドを使う

といったことです。

これは今では常識となっているweb開発における暗黙のルールですが

当時は賛否両論があり、どちらかというと批判の声の方が大きかった

考え方でした。

また、railsはrubyという型を持たないスクリプト言語を採用していたので、javaほどの信頼を得ることができず、railsはほとんど利用されていませんでした。

当時はrubyより、phpやperlの方がはるかに人気がありました。

railsを多くの人が使うようになったのは、色々な修正が入って使いやすくなったrails3からで、私自身も本格的にプロダクトで利用するようになったのはrails3からです。

そして

rails3からrails5くらいまでがrailsの全盛期

だったと思います。

rails5の頃になると、コンテナを使ったマイクロサービス開発が注目を浴びるようになりました。またreactが登場し、画面描写をrailsが担う必要性が薄れました。

railsもreactを取り込んで開発できるようなupdateが取り入れられましたが、無駄に複雑になるだけでお世辞にも良い出来とは言えず、railsはバックエンドでのみ使われるようになりました。

しかし、バックエンド用途のみだとrailsを使う理由が減り、コンテナの普及と共にコンテナと相性が良くRubyより高速なGo言語を使うことが増えてきて、railsは以前より大きく人気を落としました。

このように徐々に低迷期に入っていったrailsですが、現在はrails8への対応が行われています。

その内容を見ると

rails5から始まった迷走の時期を終え、再び輝きを取り戻してきた

ように思えます。

このまま順調に改善が進めば

第2の全盛期が始まる

のではないでしょうか。

このように思うには理由があり、今のrailsは

実用性重視の進化

を遂げているからです。

今のrailsは

いい意味でAIやweb3といった未来を見ていません。

フロントエンドも

reactなどの流行りものを無理に取り込もうとしていません。

これは

とても良い選択

だと思います。

railsはフロントエンド、AI、web3以外を担うべきだと思うし、それで十分です。

web開発のコアとなるのはバックエンドです。

それはweb3サービスでもAIサービスでも同じです。

なので、多くのリソースをバックエンドの改善に使うのは理にかなっています。

この記事を書いている時点で最新のrails7.2では

  • rubyのYJIT対応による高速化

  • rbsを使った型のチェック

  • docker利用時にjemallocを設定してメモリ割り当てを最適化

などに対応していて、以前より速度やパフォーマンスの問題に悩まされることが減っています。(個人的に型はrailsに不要だと思っています。)

なので、下手にGoやRust等の言語を使って高速化を図るよりも、railsを継続的にupdateできる仕組みを構築した方が、生産性が高くなることがほとんどでしょう。

例えば、rails8でデフォルトでの実装が予定されているKamalは、クラウドサーバーの運営コストに悩まされている中規模程度の開発でかなり支持されるのではないでしょうか。

そして何より、railsは20年かけて進化をし続け、今も最前線で使われているという実績があります。

私はこれまでに多くのwebフレームワークを使ってきましたが、ほとんどのフレームワークは第一線から消えてしまっています。

昔のwebフレームワークで、いまだに最前線で戦えるのはrailsとspringくらいでしょう。

もしあなたが今後、新規でweb開発を考えているなら

webフレームワークの第一候補にrails

を検討することは良い判断だと言えます。

そしてこのrailsを選択するということがwebサービスを構築する上で優れた選択の一つだということは、まだしばらく続くでしょう。

railsの価値を決定付けた機能


では、なぜrailsは競争の激しいwebフレームワークの世界で、ここまで支持され続けてきたのでしょうか。

それは

active record

の完成度にあると私は思います。

これまでに多くのORM(Object-Relational Mapping)が誕生し、それらを私も使ってきましたが

active record以上の完成度のORMライブラリは未だに出てきていない

と思います

他の言語でもactive recordと同じような機能を備えたライブラリはあるのですが、完成度はactive recordよりだいぶ劣ります。

active recordの完成度が高いのは

Rubyという言語とORMの相性の良さ

にあるのだと思います。

active recordの発想と設計自体も素晴らしいですが、20年という長い期間、他の言語でactive recordを超えるライブラリが出ないのは

やはり言語とORMの相性

があるのだと思います。

このことは

サービスの成長は最初の設計が重要である

ということを教えてくれる好例とも言えます。

今後のrailsで気になっていること


最後に

今後のrailsで気になっていること

について記述します。

現在のrailsの進化の方向性は正しいとは思いますが、少しgitHubやshopify等のフィードバックが強く出ているのが気になります。

例えば、trilogyはGitHub社がGitHubのために開発したmysqlAdapterですが、mysqlのcaching_sha2_passwordに対応していないなどの問題があります。

これはGitHubのmysqlがmysql_native_passwordで動作しているからでしょう。

大手企業のフィードバックがあるのは良いことですが、このケースのように特定の企業の仕様が強く反映されてしまうと、汎用的な仕様でなくなってしまうことがあります。

その他には

使いこなすハードルが上がってきている

のも気になります。

YJIT、rbs、Kamalの導入はありがたい反面、railsを使うハードルを上げています。

railsの良いところは

開発初心者でもそれなりにwebアプリが開発できる

ところです。

ここが崩れると、初心者から上級者まで色々な開発者が関わる一般的な現場では全体の生産性が低くなってしまうので、この辺のバランスには注意を払ってrailsチームにはupdateをして欲しいところです。

また、railsでラップされたフロント技術はすぐに廃れていく傾向があるので、update時の変更コストが高いのも弱点と言えます。

今後はweb3やAIを導入することがweb開発でも当たり前になっていくことが考えられますが、railsはこれらの技術を無理やりラップするのでなく、バックエンドの機能を磨き続けることを選択することが重要だと思います。

まとめ


今回は

railsのバージョンアップデート作業で思ったこと

について記載しました。

railsは7系になってから良い方向に舵を切り始めたと思います。

rails5系6系で見切りをつけた人は多いと思いますが、そういった人達ももう一度今のrailsを調査すると見方が変わるのではないでしょうか。

この記事があなたのweb開発に役立てば幸いです。

いいなと思ったら応援しよう！