Ruby on RailsはWebアプリケーションフレームワークとして非常に有名で、現在も多くの企業で使われています。Web上にも情報も多く、技術書も多く出版されており、学習環境は非常に整っていると思います。
個人開発を行う上でRuby on Railsを採用している方も多く、魅力的な選択肢の一つだと思います。
一方で筆者は最近は個人開発ではRuby on Railsは採用しておらず、基本的にNext.jsを使っている状況でなので、その立場からの一例として考えをご紹介します。
Webエンジニアとして10年ほど活動しており、キャリアの初めはWordPressでした。2013年頃に注目が集まっていたRuby on Rails 4を学び始め、業務でも使うようになり、以来いくつかのWebサービスをRuby on Railsで構築してきました。
最近も業務でRuby on Rails製のWebサービスの開発に携わっていますが、フロントエンドはReactで構築し、非同期の通信はGraphQLを利用するなど、Reactやフロントエンド技術を中心とした進め方にしています。
それ以外のプロジェクトや個人開発では、TypeScript, React, Next.js, AWS Lambda, AWS AppSyncをよく使うようになりました。
そのような状況からの考えなので、最新のRuby on Rails事情に明るくなく、Ruby on Rails側が不利な考察になってしまっている可能性がありますのでご留意ください。
Ruby on Railsで構築したWebアプリケーションを公開する場合、以下のような選択肢があるかと思います。
筆者は1ではHeroku、2ではVultrやAWS EC2、3ではAWS Fargateの利用経験があります。
Ruby on RailsをホスティングできるPaaSとして有名なHerokuが2022年に無料プランを廃止したことで、無料でRuby on Railsをホスティングできる環境が無くなりました。
Heroku、Render等のPaaSを有料で使う場合、最低月額1,000円以上はかかってしまいそうです。
ポートフォリオのために開発して当分公開しておきたい場合や、家族・友人のために作って公開し続けたい場合など、月々の出費をできるだけ抑えて公開を続けたい場合に不向きと考えました。
AWS App RunnerやCloud Runのようなサービスでは、ゼロスケール(アクセスがない場合は完全にコンテナを停止して費用発生がなくなる)もしくはそれに近い状態が作れるので、これらを活用すればよりコストパフォーマンス良くRuby on Railsをホスティングできる可能性がありますが、後述の別の理由から、そこに注力する優先度は下がっています。
VercelではHobbyプランでは無料でNext.jsをホスティングできます。Next.jsをSPAとして使う場合、ビルドしてしまえばHTML・CSS・JS・その他静的ファイルで構成されるWebサイトとなるので、Amazon S3とAmazon CloudFrontを使ってホスティングすればほぼ無料で公開することもできます。
無料枠があったり、想定される規模のサービスではほぼ無料で運用できてしまうサーバーレス系サービスやPaaSが様々登場したことで、同様の特性が発揮しづらいRuby on Railsの選択の優先度が下がったように感じます。
JavaScriptを書く場合、基本的にTypeScriptを利用するようにしています。イメージするユーザー体験を実現したいと思った場合に、JavaScriptを使う必要が出てくるケースが多く、その場合にJavaScriptのみやjQueryを使うよりもReactのようなライブラリを使いたくなることが大半でした。
結局JavaScriptを使い、それに伴ってReact, TypeScript, ESLint, Prettier等を利用するなら、バックエンドまで同じ要領で開発環境を作れたら効率的だと考えています。
開発技術ごとに得意不得意やパフォーマンスの違いなどがあるので、バックエンドまでTypeScriptで書くことには議論があるかと思いますが、個人開発ではできるだけ技術面はシンプルにして開発自体を減らしたいので、このような意思決定をしています。
HMR(Hot Module Replacement)とは、ローカル開発環境でソースコードを変更した際に、ブラウザの再読み込みを行わずに関連箇所に最新のコードを反映させる仕組みです。UIを少し変えて確認するようなプロセスを繰り返す場合、これが使えると非常に心地よく効率的に開発できます。
React, Vue, Angular等のフロントエンドライブラリ・フレームワークを使った開発では、プロジェクトをセットアップした時点でHMR相当の開発体験が得られます。
これに慣れてしまったので、無いと微妙にストレスを感じるようになってしまいました。
ちなみにRuby on RailsのフロントエンドをReactで実装できるようにしたプロジェクトでは、webpackの設定をカスタマイズして、フロントエンド部分はHMRができるように設定して同等の体験を実現しています。
個人開発の目的は自由に決めて良いものですが、筆者の場合は基本的にアイデアを形にして世に出すところまで持っていきたいです。なので、途中で細かく複雑な意思決定が求められたり、愚直に手を動かして構築するようなプロセスがあるとしんどくなって諦めてしまったり、挑戦が億劫になったりする可能性があります。
そういう観点から、開発のプロセスで省略できる部分は積極的に省略したいと考えています。
Ruby on Rails開発においては、ローカル環境セットアップのためのDockerの設定や、本番環境構築のためのVPS・ネットワークのセットアップ等に時間を割かれた経験があります。コンテナを使う場合、コンテナイメージをビルドするパイプラインの構築や、ダウンタイムなしでデプロイするBlue-Greenデプロイの設定などが大変だった記憶があります。
できるだけコードを書かず、設定を行わないという点を考慮し、IaaSではなくPaaSを積極的に採用するような形を取っています。
そういう意味で、Vercel社が開発しているNext.jsとVercelにロックインされて開発することはかなり理想に近い状態となっています。
Ruby on Railsの思想である「設定より規約」が強く浸透していると感じます。ある特定のやりたいことに対して、Web上の多くの情報が大体同じような解決策を提示している印象があり、学習の際に迷いづらかった記憶があります。
Next.jsの変化が激しいのもありますが、Ruby on Railsほど具体的なレベルで共通認識的な情報があるわけではない印象です。
サーバーの構築やミドルウェアの設定等が不要でそこに属人化の可能性が無い反面、アプリケーションの設計部分に属人化の可能性が多く含まれている印象です。
ActiveRecord, ActiveSupport, RSpecが非常に強力で、Next.js / TypeScript / Jestで実現しようとすると他のライブラリを入れたり頑張って実装したりする必要があるものが、標準機能だけでシンプルに実装できたりします。
Rubyは動的型付け言語であり、Next.js / TypeScript / Jestと比較して不具合発生確率が高いのでは?と考えていましたが、以下のような特徴でそれを抑えていると考えています。
コードは書いた瞬間から負債化すると言われますが全くその通りだと思います。「そもそも書かなくて良い」という状況は非常にありがたいです。
技術選定は様々な要素が絡み合うので、一概にこれが最高というものはないと思います。個人開発に関わる技術に変化があったり、筆者の認識にアップデートがあれば随時本記事を更新していきます。
本記事が意思決定の参考になりましたら幸いです。
個人開発事例