Rails: Evil Martiansが使って選び抜いた夢のgem（翻訳）

Rails: Evil Martiansが使って選び抜いた夢のgem（翻訳）

Railsのエコシステムは実に広大です。あらゆる典型的な作業（のほとんど）を支援する多くのライブラリが出動を心待ちにしています。その中からどうやって正しいライブラリを選べばよいでしょうか？

GitHubスターやダウンロード数といった指標に頼る方法もあります（これについてはThe Ruby Toolboxサイトで貴重な洞察を得られます）。あるいは過去の経験に頼る手もあるでしょう。経験則はライブラリを選ぶうえで有効な手段ですが、新しいgemを極端に敬遠する保守主義におちいる可能性もあります。

我がEvil Martiansでは、gemを選ぶときやgemを新たに構築するかどうかを決定するときは、集団がつちかってきた経験と異星人の本能の両方に賭けています。集合知としての経験のメリットは、さまざまな人々のマインドが長年に渡って蓄積されていることです。私たちは、どうすれば勝利を繰り返せるか、どうすれば失敗を回避できるかというおびただしい知見を積み上げています。この知見をスーパー賢いチャットAIに仕立て上げることは（まだ）できていませんが、本記事でその一端を紹介したいと思います。

ここからは、RailsアプリケーションのGemfile構造に似せた順序で進めます。以下のセクションがあります。

• Railsの基本部分
• バックグラウンドジョブ
• Active Record拡張
• 認証と認可
• HTMLビュー
• アセット管理
• API（とGraphQL）の作成
• ログ出力と計測
• 開発ツール
• テストツール
• その他もろもろ

Railsの基本部分

最初に、Rails Webアプリケーションの根幹となる要素、すなわちWebサーバーとデータベース（RDBMS）を設定する必要があります。

私たちはデータベースにPostgreSQLを選び、WebサーバーにはPumaを選ぶようにしています。
つまり、Gemfileの冒頭部分は以下のような感じになります。

gem 'rails', '~> 7.0.4'
gem 'pg'
gem 'puma'

基本部分に付け加える話はそれほどないので、Ruby on Railsアプリケーションの第3の柱であるバックグラウンドジョブエンジンを見ていきましょう。

バックグラウンドジョブ

Webアプリケーションのパフォーマンスにおける重要な特性は、スループット（throughput: 一定時間に処理できるリクエスト数）です。Ruby（MRI）のコンカレンシー制限、より正確にはGVL（Global Virtual Machine Lock）¹によって、パラレルに配信可能なリクエスト数に上限が加わります。

私たちはスループットを改善するために、リクエストを最短時間で処理できるよう努力を重ねています。それには、処理をできるだけバックグランドに逃がすのがベストです。ここで登場するのが、バックグラウンドジョブを処理するエンジンです。

Railsは、バックグラウンドジョブを定義する抽象化機能をActive Jobとして提供しています。しかし、実際にバックグラウンドジョブを処理するジョブエンジンはユーザーの選択に任されています。私たちはSidekiqを使っています。

gem 'sidekiq'

Sidekiqには、バックグラウンドジョブの実行ロジックをきめ細かく制御できるアドオンが多数あります（オフィシャルなPro版やEnterprise版も含む）。その中でも、火星人たちのプロジェクトで最も多用されている2つのプラグインを2つ紹介します。

gem 'sidekiq-grouping'
gem 'sidekiq-limit_fetch'

sidekiq-grouping gemは、キューに入れられる（enqueued）ジョブをバッファリングして、まとめてバッチ処理できます。ジョブのenqueue率が高いが即座に処理しなくてもいい場合に有用です。典型的なユースケースは、モデルの再インデックスや、モデルへのライブアップデートをブロードキャストするなどです。

sidekiq-limit_fetch gemは、重たいジョブ（あるいはメモリ使用量を肥大化させるジョブ）を制御するために使っています。たとえば、巨大な単一XSLXファイルは同時に1個しかエクスポートできないようにするには、以下のコンフィグでキューに制限をかけます。

# sidekiq.yml
---
:queues:
  - default
  # ...
  - exports
:process_limits:
  exports: 1

本セクションの締めくくりとして、Sidekiq以外のgemについてもいくつか触れておきます。

gem 'schked'

よく実行するジョブについては、Schkedという軽量なソリューションを使っています。これはrufus-schedulerという有名なスケジューラをラップして、テストのサポートやRailsエンジン対応などの機能を追加したものです。

gem 'faktory_worker_ruby'

最後に、私たちの多言語プロジェクトでは、さまざまなサービスから受け取ったジョブをエンキューして処理するFaktoryを用いています。たとえば、Pythonで書かれたMLサービスがあるとすると、そこから分析結果をRailsアプリケーションに送信したり、逆にRailsアプリからPythonアプリに送信したりできます。

Active Record拡張

本セクションの見出しから想像がつくかと思いますが、私たちはRails Wayから”脱線”するようなことはしません。Active Recordは、ビジネスロジックのモデリングとデータベースとのやりとりに用いています。

Active RecordはRailsのサブフレームワークの中でも最も多機能で、RailsがリリースされるたびにActive RecordのAPIが増えています（Rails 7.1にはあの待望のCTE（Common Table Expressions）サポートも追加されるのです！）。
それでもActive Recordに追加したい機能はまだあるので、私たちは多くのプラグインを追加していきます。

私たちはPostgreSQLに特化しているので、PostgreSQL固有の機能を多用しています。個人的にはJSONBが好みです。JSONBは、合理的に使えば生産性が爆伸びします（スキーマやマイグレーションを気にしなくてよくなるなど）。デフォルトのRailsは、JSONBの値を普通のRubyハッシュに変換しますが、このままではビジネスロジックをモデリングするうえでやや力不足です。そういうわけで、以下のライブラリのどちらか1つを用いて、構造化されていないフィールドを強化しています。

gem 'store_attribute'
gem 'store_model'

store_attribute gemは、Active Record組み込みのstore_accessor機能を拡張して型キャストをサポートします。これにより、JSONの値を通常の属性として扱えるようになります。

参考: Wrapping JSON-based ActiveRecord attributes with classes—Martian Chronicles, Evil Martians’ team blog

Store Model gemはそこからさらに一歩踏み込んで、JSON属性を備えたモデルクラスを定義可能にします。

その他によく使っているデータベース機能（PostgreSQL固有でないSQL固有の機能）トップ5といえば、データベースVIEW、トリガー、全文検索、enum型などです。それぞれの機能に対応したgemは以下のとおりです。

gem 'activerecord-postgres_enum'
gem 'pg_search'
gem 'postgresql_cursor'

gem 'fx'
gem 'scenic'
# または
gem 'pg_trunk'

ところで、RailsにPostgreSQL enumのサポートが追加されつつありますね（第一弾の#41469はマージ済みで、第二弾#44898も時間の問題です）。

特徴的な拡張についても、ほんのいくつか触れておきたいと思います。

# Soft-deletion
gem 'discard'
# 期間でグループ化するヘルパー
gem 'groupdate'

Discardは、最小限のソフト削除（soft-deletion）機能を提供します（default_scopeをアタッチしません）。機能が最小限に絞られているので、用途に応じてカスタマイズしやすく、ソフト削除を用いるほとんどのアプリケーションで使われています。

参考: Soft deletion with PostgreSQL: but with logic on the database!—Martian Chronicles, Evil Martians’ team blog

Groupdate gemは、時系列集計レポートを扱う（かつ、TimescaleDBなどの時系列データベースにまだ移行していない）プロジェクトになくてはならないものです。

認証と認可

私がこの5年間に付き合ってきたアプリケーションのほとんどには、以下の1行がありました。

gem 'devise'

きっと本記事読者も、10人のうち9人はDeviseをバンドルしているに違いありません。それが現実です（が、それでも私は夢を見たいのです）。

機会は少ないのですが、Railsアプリケーションをゼロから構築する場合は、最初にDevise以外の認証ライブラリを検討してみると決めています。さて、その筆頭は…（ドラムロール）、何とRails自身なのです！has_secure_password²機能を使えば、かなりの程度までやれます。

諦めてDeviseに立ち返る前に、他にもいくつか候補があります。

gem 'sorcery'
gem 'jwt_sessions'

Sorceryは歴史の長いgemです。Deviseよりもマジックが控えめで（READMEには逆のことが書かれていますが）、Deviseほど癖が強くなく、プラガブルアーキテクチャを備えています（つまり必要な部分だけを手軽に選べます）。

JWT Sessionsライブラリは、トークンベース認証の構築に必要なものすべてを提供しています。モバイルやSPAフロントエンドを持つAPI専用のRailsアプリの構築に最適です。

さて、OAuthドリブンの認証ソリューションについてはまるっと割愛して（これだけでたっぷり一本の記事が書けます）、認可機能の話に移ることにしましょう。

「あれ、認証も認可も同じようなものなんじゃないの？」いえいえ、認証（authentication）と認可（authorization）は全然違います。両者の根本的な違いは、どんな問いに回答するかの違いに基づいています。
認証は「この人は誰ですか？」という問いに回答する機能ですが、認可は「私がこれを行うことは許されますか？」という問いに回答する機能です。すなわち、認可ではロール（role: 役割）と権限（permission）を扱うことになります。

認可機能は、「認可モデル」と「認可（適用）レイヤ」という2つのコンポーネントに分けられます。前者の認可モデルは、パーミッションの背後に置かれるビジネスロジック（ロールや細かなパーミッションなどを使うかどうかなど）を表します。後者の認可レイヤは、認可ルールを実際に適用する方法を定義します。

参考: Access denied: the missing guide to authorization in Rails

認可モデルはアプリケーションに強く特化しすぎていて一般化が難しいのですが、認可レイヤの実装についてはgemに同梱されている一般的な手法が使えます。
私たちは長年Punditを認可の強制適用に用いてきましたが、今ならもっとよい選択肢があります。

gem 'action_policy'

Action PolicyはPunditの強化版です。このgemのコンセプト（ポリシー）はPunditと同じですが、パフォーマンスや開発エクスペリエンスを重視する優れた機能を提供します。

HTMLビュー

古典的なRails Wayでは、「HTMLファースト」が想定されていました。サーバーはMVC（Model-View-Controller）パラダイムの3つの要素である”M”、”V”、”C”について責務を負います。API専用Railsアプリという暗黒時代を経て後、最近の私たちはHTML-over-the-wireというルネッサンスの時代を今まさに目撃しています。こうして、今の私たちは再びビューテンプレートを書くようになっているのです！

しかし2020年代ともなれば、ビューテンプレートの書き方も変わります。

gem 'view_component'
gem 'view_component-contrib'
gem 'lookbook', require: false

gem 'turbo-rails'

HotwireはHTMLベースのアプリケーションをインタラクティブかつリアクティブにし、ViewComponentはテンプレートとそのロジックを整理するのに役立ちます。

実践ViewComponent（1）: 現代的なRailsフロントエンド構築の心得（翻訳）

実践ViewComponent（2）: コンポーネントを徹底的に強化する（翻訳）

アセット管理

Rails 5でWebpackerが導入されて以来、Railsでアセットを扱うのが面倒でした。今ではRails 7でこの問題に対する公式のソリューション（importmap-rails、jsbundling-rails、cssbundling-rails）が使えるようになりました。しかし私たち火星人は別の方法にしました。

# 訳注: gemのリポジトリ名は`vite_ruby`です
gem 'vite_rails'

Viteを利用するアセット管理は、バックエンド指向とフロントエンド指向の中間に位置します。HotwireアプリケーションとReact SPAのどちらについてもシンプルに利用可能です（さらに私たちのセットアップは両者のハイブリッドになることもしばしばです）。vite_ruby gemは、それらに加えて五つ星級の開発エクスペリエンスを提供してくれます。

参考: Vite-lizing Rails: get live reload and hot replacement with Vite Ruby—Martian Chronicles, Evil Martians’ team blog

私たちのGemileには、他にもアセット関連gemがいくつか追加されています。

gem 'imgproxy'
gem 'premailer-rails'

ユーザーが生成した大量のコンテンツを扱う必要が生じたときに、Rubyサーバーのリソースを画像変換のために浪費したくないですよね？そんなときは専用のプロキシサーバーに重い処理を任せましょう。もちろん、私たちは独自のimgproxyをそれ用の連携gemとともに使っているので、Railsアプリで使うのは朝飯前です。

メールに書式を設定するなら、premailer-rails gemが逸品中の逸品です。自分たちのCSSクラスを自由に用いてメールに書式を設定すれば、メールテンプレートのレンダリング中にPremailerがそれらを解きほぐしてスタイル属性にしてくれます。

API（とGraphQL）の作成

HTML-over-the-wireによる手法が人気を盛り返しつつあるとはいえ、長年に渡るJS支配はそう簡単にはゆるがないでしょう。そういうわけで、APIファーストのRailsアプリケーションも当分安泰だろうと思われます。

私たちがJSON APIを作成するときは、たいてい以下のツールを利用します。

gem 'alba'
gem 'oj'
# または
gem 'panko_serializer'

AlbaとPankoは、どちらもデータシリアライズのパフォーマンスに注力しており、Active Model Serializerに似た使いやすいインターフェイスを提供しています。PankoはC拡張を使っていることもあり、active_model_serializersに近いAPIを提供している現在もメンテ中のライブラリの中では最速のベンチマーク結果を叩き出しているので、ライブラリの乗り換え先候補としてもよいでしょう。一方、Albaはもっと機能が豊富で、しかもかなり高速です（JSONシリアライズドライバにOjを使う場合）。

ただし、私たちが実際に用いるのはGraphQLの方が多いので、今度はGraphQL関連のgemを紹介します。

gem 'graphql', '~> 2.0.0'

# コネクションでカーソルベースのページネーションを行う
gem 'graphql-connections'
# GraphQLのキャッシュを適切にする
gem 'graphql-fragment_cache'
# Apolloの永続化クエリをサポート
gem 'graphql-persisted_queries'

# はい、Action PolicyはGraphQLで公式に統合されています
gem 'action_policy-graphql', '~> 0.3'

gem 'graphql-schema_comparator', group: :development

# N+1クエリ問題を（ずぼらな）プロのように解決！
gem 'ar_lazy_preload'

私たちが使っているGraphQLライブラリはパフォーマンス指向です（そして私たち火星人が作っています…これは偶然？）。graphql-schema_comparator gemをDangerというツールと併用することで、スキーマを変更するプルリクが来たら警告するようになっています（おかげでスキーマ変更を見落とさずに済みます）。

ところで、GraphQLグループにar_lazy_preloadというgemが追加されている理由が気になる人もいるかもしれませんね。このライブラリはActive Recordの拡張ではありますが、特にGraphQL APIと組み合わせると大変便利なのです。N+1クエリ問題を退治するのに使われる古典的な#preloadや#eager_loadはあまり効率がよくありません。遅延プリロード（lazy preload）を用いることで、データローダーやバッチローダーによるパフォーマンス低下や複雑性のオーバーヘッドを回避できるようになります（もちろん、完璧ではありませんが）。

ログ出力と計測

私たちの偉大なるGemfileさまのproductionグループには、以下のログ出力/監視ツールが含まれています。

group :production do
  gem 'yabeda-sidekiq', require: false
  gem 'yabeda-puma-plugin', require: false

  gem 'lograge'
end

YabedaはRubyアプリやRailsアプリで使えるinstrumentation（計測）フレームワークです。著名なライブラリ（SidekiqやPumaなど）や監視バックエンド（PrometheusやDataDogなど）を対象とするさまざまなプラグインが利用できます。

参考: Yabeda: monitoring monogatari by Evil Martians

Logrageは、Railsの冗長なログ出力を簡潔な形式で構造化することで、ログ収集システムで解析しやすくしたり、クエリ可能なデータソースに変換したりできます。

開発ツール

本番環境の話はこのぐらいにして、開発環境の話に移りましょう（私たちの仕事は、実はエンジニアなのですから）。Rubyは開発者が幸せになれるように設計されていますが、この原則に沿ってRubyでアプリケーションを開発するには、ツールを少しばかり調整する必要があります。

どうすればRails開発者が心の底から幸せを感じられるようになるでしょうか？はい、開発環境でトラブルが一切発生しなくなることですよね この問題は、Dockerで十分解決できます。

クジラに乗ったRuby: Evil Martians流Docker+Ruby/Rails開発環境構築（更新翻訳）

他にはどんなことができるでしょうか？退屈な定形作業を減らすことですよね。そこで私たちは、そういう作業を支援するロボットを追加してクールな作業に専念できるようにしたり、開発エクスペリエンスをもっと快適にして良いコードを書けるようにするgemを追加しています。

以下は火星人たちがRailsプロジェクトで利用している有名な開発ツールです。

gem 'bootsnap', require: false

bootsnapはRailsにデフォルトでバンドルされるので、自分で導入する必要はありません。そのまま使いましょう！

gem 'database_validations'
gem 'database_consistency'

database_validations gemとdatabase_consistency gemのペアは、モデル層とデータベーススキーマの間で一貫性を強制するのに役立ちます。null: falseを指定すると、validates :foo, presence: trueと書かなければならなくなります。validates :bar, uniqueness: trueを指定すると、そのカラムにuniqueインデックスを定義する必要があります。

gem 'isolator'
gem 'after_commit_everywhere'

多くのデータベース操作はトランザクション上で行われるので、ACID原則はどんなときも忘れてはいけません。データベーストランザクションは論理トランザクションと同じではなく、データベース以外の場所で発生する副作用についてはデータベースで保護できないので、自分たちで対処する必要があります。

たとえば、”記事を公開しました”というメールをデータベーストランザクション内から送信すると、トランザクションのコミットが万一失敗した場合に誤ってメール通知が送信されてしまう可能性があります。

同様に、あるAPIリクエストを実行したときにトランザクションがロールバックされると、サードパーティのシステム（支払いゲートウェイなど）との不整合が生じる可能性があります。

Isolator gemはそうした問題の特定に役立ち、after_commit_everywhere gemはCOMMITが成功した場合に副作用を実行する便利なAPIを提供します。

その他のデータベース関連gemについても寸評を加えておきます。

# マイグレーションによるダウンタイムを防ぐ
gem 'strong_migrations'
# データベースのヘルスに役立つ洞察を得られる
gem 'rails-pg-extras'

# productionデータベースの一部をマスクしてダンプし、
# ローカルでのプロファイリングやベンチマークを行えるようにする
gem 'evil-seed'

ベンチマーク実行やプロファイリングも開発の一部です。ここではそういう場面で有用なgemをいくつか紹介します。

# プロファイリングで必須のツールをいくつか
gem 'derailed_benchmarks'
gem 'rack-mini-profiler'
gem 'stackprof'

Stackprofといえば、Speedscopeという素晴らしいスタックプロファイルツールもぜひどうぞ。

gem 'bundler-audit', require: false
gem 'brakeman', require: false

セキュリティは避けて通るわけにはいきません。bundle auditを実行して既知のCVEがプロジェクトの依存関係に含まれていないかどうかをチェックしましょう。
また、Brakemanを定期的に実行してコードベースのセキュリティ問題をスキャンしましょう。今なら、CIサービスが独自に提供しているセキュリティ分析ツールを代わりに使う手もあります。

gem 'danger', require: false

Dangerは、コードレビューのエクスペリエンスをレベルアップします。たとえば以下のように、複雑な定形作業を自動化したり変更をハイライトしたりします。やりたいことはほぼ何でも自動化スクリプトにお任せできます。

• ラベルの自動追加
• テストがない場合に警告する
• 望ましくないstructure.sql変更
• etc.

参考: Danger on Rails: make robots do some code review for you!—Martian Chronicles, Evil Martians’ team blog

gem 'next_rails'

Railsをアップグレードするなら、next_rails gemにアップグレード作業の道案内をやってもらいましょう。

gem 'attractor'
gem 'coverband'

コードベースを健全な状態に保つには、定期検査を実施して、コードの中で最も痛んでいる部分を監視する必要があります。

たとえば静的解析では、「チャーンvs複雑性」³のような有名な手法を用いることでリファクタリングする価値があるかどうかを判定できます。この種のツールは豊富にありますが、私たちが選んだのはAttractorです。

production環境でのカバレッジ（私たちはCoverband gemを使っています）は、コードのどの部分の重要性が高いかについて別の視点を提供してくれます。つまり、リファクタリング中はここに注目する必要があります。また、消す必要のある”デッドコード”（まったく実行されないコード）も検出できます。

残りは定番のgemです。

eval_gemfile 'gemfiles/rubocop.gemfile'

# gemfiles/rubocop.gemfile
gem 'standard'
gem 'rubocop-rspec'
gem 'rubocop-rails'

私たちのRuboCop化手法について詳しくは、以下の関連記事をどうぞ。

参考: RuboCoping with legacy: Bring your Ruby code up to Standard—Martian Chronicles, Evil Martians’ team blog

テストツール

テストを書いて実行することは日々の開発業務の一部でもありますが、それでも独自の工夫を盛り込むべきです。Ruby and Railsでアプリケーションを構築する大きなメリットのひとつは、高度なテストという文化が栄えていることです。

まずは基本的なものから。

gem 'rspec-rails'
gem 'factory_bot'

はい、私たちもRSpecのファンであり、fixtureよりもFactoryBotによるfactoryを重用しています（ただしfactoryだけを使うわけではありません）。MinitestとRSpecのどちらがいいか、factoryとfixtureのどちらがいいかという話は別の機会に譲ることにして、パラダイムに関わらないライブラリの話を続けることにします。

gem 'cuprite'
gem 'site_prism'

高速かつ壊れにくいシステムテストを作成するには、最新のブラウザ制御ツール（Cuprite）を利用するとともに、テストシナリオをオブジェクト指向で記述します（site_prismのPage Object Modelパターンを用います）。

gem 'with_model'

with_modelも私たちのお気に入りgemのひとつです。かなり昔に、Railsモデルのconcernsのテストを改善する方法を探していたときに初めてこのgemを発見しました。このライブラリを使うと、データベースの一時テーブルに接続された一時的なモデルを作成できるようになるので、モジュールやRailsのconcernsはもちろん、振る舞いが共有される任意の実装をテストできるようになります。

gem 'n_plus_one_control'

N+1クエリ問題は、Railsアプリケーションで頻発する問題のひとつです。N+1クエリ問題は発生しやすく、問題を検出するツールはいくつかあるものの、（最近のActive Recordの.strict_loading機能を除けば）問題を防止することまではできません。

n_plus_one_control gemを使えば、今後N+1クエリの発生を防止するテストを書けるようになります。

gem 'webmock'
gem 'vcr'

テストが外の世界にアクセスするようなことは決してあってはなりません。私の経験則はいたってシンプルで、ネットのつながらない飛行機に乗っていても実行すればパスするテストだけが、良いテストです。

webmockのWebMock.disable_net_connect!をrails_helper.rbまたはtest_helper.rbに追加するだけで、テストが実際のネットワーク呼び出しに依存することを回避できます。

ネットワーク経由の呼び出しや時間も、不安定なテストの原因になる可能性があります。

gem 'zonebie'

テストが時間に依存するのをエレガントに防ぐ方法のひとつは、タイムゾーンをランダムに変更してテストを実行することです。zonebie gemをバンドルに含めるだけでこれをやってくれます。

私たちは、かの有名なTimecop gemを使っていない点にご注意ください（TimecopはRailsでは冗長です）。代わりに、以下の記事のようにRails組み込みのTimeHelpersを利用できます。

参考: Replace Timecop With Rails’ Time Helpers in RSpec – Andy Croll

gem 'rspec-instafail', require: false
gem 'fuubar', require: false

RSpecユーザー向けの便利ツールもいくつか紹介します。

Fuubarは、RSpecのプログレスバーを見やすくフォーマットします（これがRSpecのデフォルトでない理由がわかりません）。

rspec-instafailも、CIでテストを実行するときに便利なフォーマッタです。エラーが発生した時点でエラーが表示されるので、テストスイートの実行完了を待たずに修正を開始できます。

最後に、私たちのGemfileでtestグループのトリを務める重要なgemを紹介します。

gem 'test-prof'

TestProfは、”Railsの遅いテストスイートを診断する名医”です。テストが数百件であろうと数万件に達していようと、速いテストは常に価値があります。TestProfを使えば、わずかな手間でテスト実行時間を劇的に改善できます。

TestProf: Ruby/Railsの遅いテストを診断するgem（翻訳）

その他もろもろ

私たちが使っている素晴らしいライブラリすべてを1本のブログ記事だけで解説するのは基本的に無理です。そこでボーナスとして、いくつかの便利ライブラリをピックアップして紹介します。

gem 'anycable-rails'

gem 'feature_toggles'

gem 'redlock'

gem 'anyway_config'

gem 'retriable'

gem 'dry-initializer'
gem 'dry-monads'
gem 'dry-effects'

それぞれのgemについて、使いたくなる状況を手短に記します。

• リアルタイム機能を構築したい: AnyCableの出番です。

• フィーチャートグル機能を手軽に導入したい:  feature_togglesという最小限のソリューションがあります。

• 分散ロックメカニズムを探している: Redisはそのような場合に最適です。redlockはそのための方法です。

• アプリケーションのコンフィグを管理したい: Anyway Configのコンフィギュレーションクラスの利用を検討してみましょう。

• リトライロジックを手書きするのがだるい: retriable gemをチェックしてみましょう。

• Serviceオブジェクトが散らかるのを何とかしたい: dry-rbシリーズを検討してみましょう。
  • 例: dry-initializerの宣言的パラメータを使う
  • 例: dry-monadsのResultオブジェクトを使う（dry-monadsは特にRubyのパターンマッチングとの相性が優れています）

• 抽象化されたレイヤ間でコンテキストをもっと安全に受け渡ししたい: dry-effectsライブラリの”algebraic effects”を試してみましょう。

この調子でいくらでも続けられますが、あまり押し付けがましいのも考えものです。理想のツールベルトはエンジニアごとに違って当然なので、いろいろ試しながら自分に合ったツールベルトを作り上げましょう！その他のツールについては鵜呑みにせず、参考程度に考えて使いましょう。

以上、夢のお話でした

さて、どうやら現実に帰ってくるときが来たようです。火星人たちの「理想の」Gemfileがどのようなものか、皆さんにもある程度想像いただけることを、そして運良く皆さんも自分なりの夢を描くためのインスピレーションを得られることを願っています。

Evil Martiansは、お客様のプロジェクトやプロダクトの設計ニーズにお応えいたします。夢のRailsプロジェクト（あるいはそれ以上のプロジェクト）であるかを問わず、お客様のWebアプリケーションやモバイルアプリケーションで、プロダクト設計、フロントエンド、ソフトウェア信頼性のような専門家による解決が必要な問題がおありでしたら、いつでも私たちが出動いたします！プロジェクトを軌道に乗せて現実化したいお客様もお待ちしております。元記事のフォームまでご相談をお寄せください。

Changelog

（原文Changelog）

1.0.1 (2023-01-20)

• redis-mutexをredlockに置き換えた（redis-mutexの作者自らおすすめまでしているため）

関連記事

AnyCable 1.0: RubyとGoによるリアルタイムWebの4年間（翻訳）

Rails: anyway_config gemでRubyの設定を正しく整理しよう（翻訳）

The post Rails: Evil Martiansが使って選び抜いた夢のgem（翻訳） first appeared on TechRacho.