こういうことを実践できたらメンテナンスしやすいRailsアプリケーションを構築できるんだろうな、というポエムです。
以下の条件を前提に書いています。
ざっと以下のことを考えたいと思います。
下記はこの記事では扱いません、ごめんなさい🙏
余裕があれば続編で書きたいと思います。
結論、分かりません。 ごめんなさい🙏
自分がRailsでフロントを構築したのはRails5の時でerb * jQueryで頑張っていました。
webpackerについては自分はお世話になることはありませんでした。Rails * Next.jsの構成でSPAを構築することが多かったので...。そうこうしているうちにwebpacker自体が非推奨になっていました。今はHotwire * importmap-railsがデフォルトっぽいですね。
今Rails 8アプリを作るなら何も足さないバニラ味にしよう（翻訳）
個人的にはTypeScriptなしではフロントエンドを実装する自信がないのでフロントはRailsでは構築しないかなあ、という感じです。 ただフロントエンドとバックエンドでアプリケーションを分けると
みたいなことを考える必要があるのでその分メンテナンスコストが上がるのかなあ、と思いました。もちろん調べれば資料はたくさん出てくると思うのでやり切れるかどうか、な気がしました。
もしRailsでフロントを構築するなら
<% Book.where(is_published: true).each do |book| %>とか書かない結論、分かりません。 ごめんなさい🙏
RailsはデフォルトではREST APIのみ構築できます。GraphQLを構築するにはgrpahql-rubyなどサードパーティ製のgemが必要です。 自分は実務でも個人開発でもRailsでGraphQLサーバは触ったことはあります。ただ0→1でスキーマを設計したり、実際に運用した経験がないのでどちらが良いかは分からないです。
個人開発で触った時のメモはGraphQLを素振りしてみたに書いていますので興味ある方は読んでみてください。(だいぶ古いですが...)
ちなみにRailsでGraphQLを構築してみてまず感じたのは
ロジックがapp/graphql配下に全て収まるので初見だとちょっと戸惑いそう ということです。
RESTであれば
という流れで実装すると思うのですが、GraphQLの場合
という実装になるので意識を切り替える必要があるかな、と思いました。
そもそもどういったケースでGraphQLがフィットするのか？を理解する必要があるので、GraphQLが解決する問題とその先のユースケースなんかを読むと良いのかな、とか思いました。(saboyutaka氏のGraphQL関連の記事、めちゃ面白い...)
RDBMSも詳しく無いので PostgreSQLかMySQLのどっちがいいのか！ みたいなのはよく分からないです...。
もちろんRailsはPostgreSQLもMySQLも対応しているので、どちらかを採用したからといってそれ自体が開発のボトルネックになることはないのかなあと思います。
ただCloud SpannerやAmazon Aurora DSQLといったPostgreSQL互換の高機能なデータベースが存在するので、将来的なDBの乗り換えも視野に入れるならPostgreSQLを選択しておくのが無難なのかなあ、とか思いました。
TODO: あとで書く
Railsの開発で静的解析、といえばrubocopかなと思います。rubocopには様々なプラグインがありますので特に立ち上げ時で自由に設定できるのであれば片っ端から入れて後から徐々に緩める、という運用で良いのかなと思います。
下記は自分が設定した.rubocop.ymlです。こまめに bundle exec rubocop -A を実行するかgit commit時やCIでチェックするか、いずれにせよ書き方を統一してレビューコストを発生させないことが大事かと思います。
require: - rubocop-rails - rubocop-performance - rubocop-rspec - rubocop-rspec_rails - rubocop-factory_bot - rubocop-rake
またrubocopを運用しているとmetricsabcsizeを幾つにするか、で議論が発生するかと思います。個人的には25~30くらいまでは許容して良いのでは、と思っているのですが、そもそも25~30になる前提の設計が良くないのでは？という意見もあるかと思います。こればかりはチームで議論して決める他ないかと思います。
余談ですが、エディタにRubymineを使うとメソッドのサジェストがいい感じだったりリファクタリングがガツガツ進むのでオススメです。
モデリング、というよりRDBのテーブル設計の話ですね。
以下は セキュリティ、DB設計、パフォーマンス分析＿＿。Railsを使ったWebアプリ開発をパワーアップする書籍6冊 からの引用です。
Railsアプリ開発について説明すると、Railsの本質は全力でDBに乗っかるところにあると思っています。Railsが便利で良くできているのはとどのつまりPostgreSQLやMySQLといったDBシステムが良くできており、RailsはそのDBの良さを下手にねじ曲げようとせず、極力素のまま引き出そうとしているからではないでしょうか。
何度も頷き「分かるな〜」って唸りながら読みました。なのでRailsでアプリケーションを構築するときはテーブル設計にリソースを割いた方が良いと思っています。良くないテーブル設計をすると
という悪循環が発生します。この悲劇を避けるためにも最初から上手にテーブルを設計し続ける技量が求められます。
まず 守破離の守から。
を読むと良いと思います。
など実務で意識すると良いポイントが素晴らしくまとまっています。スライド作成者のsinsoku氏のスライドはどれも素晴らしいのでぜひ読んでみて下さい。
次は守破離の破ですね。
よく話題に上がるのはサービスクラス。自分はサービスクラスが必要になる規模のRailsアプリケーションを構築したことがないので正直よく分からないです。ただ自分が調べた感じではサービスクラスは無い方が良い、という意見が多そうでした。
「今のプロジェクトいろいろ大変なんですよ、app/services とかもあって……」/After Kaigi on Rails 2024 LT Night
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ
サービスクラスを導入されている企業事例も調べてみたところ t_wadaさんにTROCCO®︎開発の悩みを壁打ちしてもらいました なんかがヒットしました。
Railsは、標準のMVCディレクトリ以外では比較的自由に名前空間を切ってしまっても問題ない。自分達の中である程度分類ができているのであれば切ってしまえばいい。
逆に言えば、models配下はトップレベルにファイルが並んでいないと何かと不都合がある。
複数モデルにまたがる保存処理がサービスクラスに置かれることは多いが、その必要があることは少ない。
最後は守破離の離なんですが、Rails開発における離って何なんですかね...(自問自答)
なんかを参考に他社事例を見ると何か見つかるのでしょうか？
TODO: あとで書く
TODO: あとで書く
意外と筆が進まない...