できるだけコントローラではなくモデルで例外処理する

問題: コントローラで例外処理している

アプリケーションが扱うドメイン特有のエラーを例外として表現する場合に、その例外をコントローラで処理するコードを書くと、ほとんどの場合でコードが読みにくくなったり、コードを変更しづらくなったりする結果となる。そして、開発の効率が落ちたり不具合を作りやすくなったりする。

具体的な問題は次のとおり。

コントローラのアクションの凝集度が下がる

コントローラのアクションに、たとえば複数の決済方法のエラーのような微妙に異なる種類の例外に対する処理を書くと、コントローラが肥大化し、凝集度が下がる。結果として、エラーが関わる変更を入れるときに、本来ビジネスロジックだけの変更であっても、コントローラとモデルの両方を必ず変更しなければならなくなる。また、関係の薄いさまざまな例外が1箇所で処理されることになり、コードが読みにくくなる。

class ChargesController < ApplicationController
  def create
    # ...

  # いろいろな例外処理
  rescue FooPay::Error
    # ...

  rescue BarPay::Error
    # ...

  rescue BazPay::Error
    # ...

  # 以降同じような節が続く
  end
end

さらに、こういうコードは「ここで例外処理しているから今回のも追加しておくか」という心理を誘発しやすい(割れ窓)。持続的なWebアプリケーション開発は割れ窓との戦いである。

テストの負担が増える

コントローラ層を対象としてテストする場合、いちいち結合テスト(近年のRailsだとintegration testまたはrequest spec)を書く必要がある。プレーンなクラスやいわゆるモデルなどと比較するとテストの準備が大変になるし、テストの実行速度も落ちる。また、異常系はとくにだが、しばしばリクエストやコンテキストを含めた複雑な事前状態を作る必要があり、読みにくいテストになる。

テストがしづらいところにがんばってテストを書くことはできるが、それは問題解決になっていない。

原因

そもそもコントローラはHTTPのことをやるところだが、それ以上の責務を負わせているのが上述した問題の主な原因といえる。

コントローラは、外から来るリクエストを受け取って、レスポンスを作って返すというのが本来の責務。HTTPに基づいてパラメータやヘッダのパース、Cookieの管理、レスポンスの生成などを実行する。

つまり、コントローラはレイヤードアーキテクチャのUI層やプレゼンテーション層にあたる。これらの責務やレイヤーには、アプリケーションの中核となるビジネスロジック(アプリケーションが解決する問題領域に固有のロジック)は含まれない。

一方、ビジネスロジックはモデルで扱う。これはレイヤードアーキテクチャで言うとドメイン層やモデル層と呼ばれるところ。ビジネスロジックを実行中に処理を継続できなくなったら発生させたいエラーは本来ビジネスロジックとして処理するべきだが、このエラーがモデルを外から利用しているコントローラにまで侵食してくると、上述したような問題が発生する。

解決策

本当に例外を使うべきか考える

ビジネスロジックにおけるエラーは「例外」ではないはず、とまず考えたい。たとえば、ユーザーが変な値を送信してきたときにそれを不正としてエラーを返すのは、例外的ではなく想定内のはず。別の側面だと、例外は制御構造から大域脱出するので、多用するとコードを読むときの負荷を高めうる。

例外の定義の1つを引いてくると『オブジェクト指向入門 第2版 設計・コンセプト』の12章に「例外とはルーチンコールの失敗を引き起こす可能性のある実行時イベントである」とある。つまり、例外とは、ルーチン(メソッド)の実行時に最後まで期待どおり実行できない可能性がある事態の発生を表す*1

どのようなエラーを例外として表現すべきか。技術的な例外としては外部サービスとの通信の失敗や、NoMethodErrorなどの実行時エラーがある。また、ビジネスロジックの例外としては、データとビジネスルールのあいだの不整合などで一度開始したトランザクションを続けられない状態になったとき発生させる例外が考えられる。これらのケースを除くと、本当に例外が必要ではないケースもそれなりにある。

そこで、エラーをできるだけ例外ではない方法で表現できないかを考える。たとえば、ビジネスロジック実行前のデータの検証失敗時に例外を起こすのではなく、検証の実行結果を取得できるような設計にする。これは、RailsだとActiveModel::Validationをうまく使い、入力値に関するエラーは戻り値、またモデルやフォームオブジェクトの属性として取得する事になる。

モデル層で適切にビジネスロジックを書く

ビジネスロジックに関するエラーをコントローラで処理するようになることが問題の原因だと書いた。ビジネスロジックに関するエラー処理をモデル層でやるためには、RailsのActive Recordのモデル(つまり、アクティブレコードパターンに基づいたDBのテーブルに対応しているクラス)だけではなく、必要に応じてふつうのクラスを作るようにする。そして、そのなかでエラー処理をやる。Railsならプレーンなクラスでもいいし、コントローラやビューで使えるようにするならActive Model (ActiveModel::Model)を使ってもよい。

このようなクラスをうまく作るためには、リソースだけではなくアプリケーションにおけるイベントもモデルとして抽出したり、ユースケースを見出してクラスにする必要がある。この話題については、非常にわかりやすくまとまっている次の文献を参照されたい。

トランザクションを張る場合は、例外を発生させることでトランザクションをロールバックする形になる。このケースにも対応するための案としては、次のようにビジネスロジックの一部としてロールバックと例外処理を実行し、このモデルを使う側からは実行結果だけが取得できるよう方法がある。これができると、コントローラは薄くなり、scaffoldしたときの構造に近くなる。

class Foo < ApplicationRecord
  # ...

  def execute_some_business_logic
    transaction do
      foobar!
      save!
    end

    true

  rescue ActiveRecord::RecordInvalid
    false

  rescue Foo::SomeError
    # 特有のビジネス例外としてなにか処理する

    false
  end
end

class FoosController < ApplicationController
  def update
    @foo = Foo.find(params[:id])

    if @foo.execute_some_business_logic
      # ...
    else
      # ...
    end
  end
end

DBと通信できないなどの技術的な例外はそもそもプログラムの実行を続けられないはずなので、ここで処理せず呼び出し元まで例外を突き抜けさせるのがよい。

FAQ: 404、500などのエラーにしたいときはコントローラより上の層で例外処理する必要があるのでは?

利用しているフレームワークにもよるが、404や500などの一般的、技術的エラーはアプリケーション共通の処理を定義していることが多いので、そういうケースで例外を発生させるのは問題なさそうに思う。たとえば、PUT /foos/:foo_id/bars/:bar_idのようにパスパラメータとしてIDが入るリソース設計にすると、

  • foobarは最初にコントローラでDBから探す
  • それらのレコードが見つかったら、そこからビジネスロジックに処理を依頼する

という流れになる。このときは、foobarがなければ、コントローラで例外処理をすることになる。

class BarsController < ApplicationController
  rescue_from ActiveRecord::RecordNotFound do
    # ...
  end

  def update
    foo = Foo.find(params[:foo_id])
    @bar = foo.bars.find(params[:bar_id])

    if @bar.update(bar_params)
      # ...
    end
  end
end

*1:契約によるプログラミングの言葉を使うと、呼び出されたルーチンが事後条件を満足できないときに発生するといえる cf. https://www.slideshare.net/t_wada/exception-design-by-contract

AOPに基づいてconcernモジュールを作る

発端: concernモジュールの命名をどうするか

ここではActiveSupport::Concernをextendしたモジュールのことをconcernモジュールやconcernと呼ぶ。

「Concernに何を実装すべきかは…非常に曖昧」1である。さらに、Railsアプリのメインであるルーティングからモデルまでは命名規約がかっちり決まっているが、concernに明示的な規約はない。concernも基本的にはRubyのモジュールなので、EnumerableComparableのような組み込みモジュールと似たような命名にするべきだろうか。実際、concernの名前に動詞+ableを使うのはよくやると思う。

Rubyのプレーンなモジュールとの違いとして、ActiveSupport::Concernにはincludedclass_methodsが存在する。これらの機能があることで、concernはコールバックの定義やクラスマクロの定義に使われるようなフォースが働いているように見える。そこで、そのような特徴を踏まえたうえでconcernならではの命名があるか考えてみる。

横断的関心事

concernとはいったいなんだったのかというのをふりかえってみると、アスペクト指向プログラミング(AOP)における横断的関心事(cross-cutting concern)が起源の1つといえそう2

AOPにおける横断的関心事についてはこちらが詳しい。

横断的関心事 - アスペクト指向なWiki

横断的関心事の分類の1つとして静的か動的かというものがある。静的な横断的関心事はインタータイプ宣言の機能を担う。AspectJなどではクラスに新たなメソッドやプロパティを追加する仕組みのことをインタータイプ宣言と呼んでいるようだ。一方、動的な横断的関心事はポイントカット+アドバイスの機能を担う。こちらは、コードを実行すると発生する特定のイベント(メソッド呼び出しなど)にあわせてアドバイスと呼ばれるコードを実行する。

それぞれ、concernだと次のようなものにあたるといえそう。

  • 静的な横断的関心事は、スコープやクラスマクロを追加するconcern
  • 動的な横断的関心事は、コールバックを追加するconcern

concernの事例

Basecampの事例

concernといえば、DHHがかつて示していたBasecampのコード例が有名。

これ自体の賛否は置いておくとして、includeしているモジュールがすべてcocnernモジュールだと仮定すると、その名前には次のようなバリエーションがある。

  • 名詞
    • 単数形、複数形
  • 動詞
    • 接尾辞がable
      • スコープやメソッドを追加するために使われているように見える
    • 現在形(原型と三単現両方ある?)
    • 過去分詞

想定しうるバリエーションがあらかた存在する状況で、これだけだと明確なルールが見出しにくい。

api.rubyonrails.orgの事例

ActiveSupport::ConcernFooモジュールのような単純な例だけだったので、concerningのほうを見ると、EventTrackingという名詞のconcernが紹介されている。このconcernはメソッドを追加しつつコールバックも定義している。

AOPの観点でconcernを作る

実事例を見つつ、さきほど書いたAOPの静的・動的横断的関心事によるconcernの分類に基づくと、ある程度納得感のある名前を持つconcernが作れそうに見える。

モジュールやクラスが静的な横断的関心事にあたるconcernをincludeすると、その時点でconcernが定義しているクラスマクロ、スコープ、またインスタンスメソッドが使えるようになる。つまり、それらを利用するか否かにかかわらず使えるようにはなる。とすると、Rubyのプレーンなモジュールと同じく動詞+ableにするのがよさそうに見える。

たとえば、パーフェクトRuby on Railsに載っているようなTaggableなら付与したタグのためにtagged_withスコープやtagsなどの関連が追加されるだろうし、UserSessionIssueableならログインセッションをセットアップするメソッドlogin_as_userが追加されるだろう。

module Taggable
  extend ActiveSupport::Concern

  included do
    has_many :tags #, ...
  end

  class_methods do
    def tagged_with
      # ...
    end
  end
end

module UserSessionIssueable
  extend ActiveSupport::Concern

  def login_as_user
    # ...
  end
end

一方、モジュールやクラスが動的な横断的関心事にあたるconcernをincludeすると、その時点でconcernが持つコールバックを必要に応じて自動で実行するようになる。「できるようになる」よりは「する」なので、concernのモジュール名は動詞の現在形にしておくのがよさそう。また、アトリビュートも追加されて、なんらかの状態を持たされるなら過去分詞にするといいかもしれない。

たとえば、NotifyImportantOperationなら重要な操作をどこかに自動で通知するコールバックを定義するだろうし、Obfuscatedなら特定のアトリビュートを自動で難読化したものを新たにアトリビュートとして持つようにできるだろう。

module NotifyImportantOperation
  extend ActiveSupport::Concern

  included do
    before_action :notify, only: [:create, :destroy]
  end

  def notify
    # ...
  end
end

module Obfuscated
  extend ActiveSupport::Concern

  included do
    attr_reader :obfuscated
    after_validation :set_obfuscated
  end

  def set_obfuscated
    # @obfuscated = ...
  end
end

うまく命名できるconcernになっているかどうか考えることは、大きすぎたりモジュールとしての意味のまとまりが希薄なconcernを作らないようにするのにも役立ちそうだ。

今回のAOPの考えかただと、concernに名詞で命名するとしっくりくる状況があまり思いつかなかった。一方で、EventTrackingの例のように関連とコールバック両方を定義するようなときは、利用可能なメソッドの定義と自動で実行されるコールバックの両方が手に入るので、上記の命名方法よりは適切に名詞で命名したほうがわかりやすいというのはあるかもしれない。


  1. 『パーフェクトRuby on Rails【増補改訂版】』13-1-3

  2. https://texta.pixta.jp/entry/2022/01/12/150000 など参照

Railsエンジンのappディレクトリ配下のクラスを親アプリでオーバーライドする

やりたいこと

Railsエンジンのappディレクトリ配下に存在するクラス(モデルやコントローラ)のメソッドをオーバーライドしたい。

結論

RailsガイドのRailsエンジンについての記事に全部書いてある。Railsエンジンのapp配下のオーバーライドは、to_prepareを使って、親アプリの初期化が終わったあとに実行する。オーバーライドするクラスはclass_evalでリオープンする。

# config/application.rb
module TestApp
  class Application < Rails::Application
    # ...

    # アプリの初期化が終わったときに呼ばれるフック
    config.to_prepare do
      # もしZeitwerkなら`require_dependency`が非推奨なので`load`を使う
      require_dependency Rails.root.join('lib/monkey_patch/foo_bar_engine.rb')
    end
  end
end
# lib/monkey_patch/foo_bar_engine.rb
module MonkeyPatch
  module FooBarEngine
    def do_something
      # 上書きする
    end
  end
end

FooBarEngine::FooBarsController.class_eval do
  prepend ::MonkeyPatch::FooBarEngine
end

詳細

Railsガイドを読めば問題は解決するのだが、思いつく他の方法で試してみて、なぜだめだったかを見てみる。

オーバーライドに失敗する例: その1

親アプリ側のディレクトリに次のようなコードを書くと、このアクションに対応するエンドポイントにリクエストを送るとき、AbstractController::ActionNotFoundのエラーになる。

# app/controllers/foo_bar_engine/foo_bars_controller.rb
module MonkeyPatch
  module FooBarEngine
    def do_something
      # 上書きする
    end
  end
end

module FooBarEngine
  class FooBarsController
    prepend ::MonkeyPatch::FooBarEngine
  end
end

開発環境では、定数参照時にconst_missingになるとActive Supportがautoload_pathsからパスの規約などに基づいて定数を探す。autoload_pathsは例えば次のように確認できる:

[1] pry(main)> puts ActiveSupport::Dependencies.autoload_paths
/usr/src/app/app/assets
/usr/src/app/app/controllers
/usr/src/app/app/controllers/concerns
/usr/src/app/app/helpers
/usr/src/app/app/jobs
/usr/src/app/app/mailers
/usr/src/app/app/models
/usr/src/app/app/models/concerns
/usr/local/bundle/gems/letter_opener_web-1.4.0/app/assets
/usr/local/bundle/gems/letter_opener_web-1.4.0/app/controllers
/usr/local/bundle/gems/letter_opener_web-1.4.0/app/models
/usr/local/bundle/gems/devise-4.7.3/app/controllers
/usr/local/bundle/gems/devise-4.7.3/app/helpers
/usr/local/bundle/gems/devise-4.7.3/app/mailers
/usr/src/app/spec/mailers/previews
=> nil

ここではletter_opener_webやdeviseなどのRailsエンジンのapp配下もautoload_pathsの後ろのほうに入っている。

FooBarsControllerを読み込んでいないとき、アクション実行時にFooBarEngine::FooBarsControllerという定数を解決することになる。autoload_pathsに従うとRailsエンジンより先に親アプリの定義を見てしまい、中身がほぼ空のコントローラのアクションを呼び出してしまってAbstractController::ActionNotFoundになる。

オーバーライドに失敗する例: その2

config/application.rbの末尾でclass_evalでオーバーライド対象のクラスをリオープンしてオーバーライド用のモジュールをprependすると、uninitialized constant FooBarEngine::FooBarsController (NameError)のエラーになる。

# config/application.rb
module TestApp
  class Application < Rails::Application
    # ...

    # これがないとlibにパスが通らない
    config.eager_load_paths << "#{Rails.root}/lib"
  end
end

require_dependency 'lib/monkey_path/foo_bar_engine.rb'
# lib/monkey_path/foo_bar_engine.rb
module MonkeyPatch
  module FooBarEngine
    def do_something
      # オーバーライドする
    end
  end
end

FooBarEngine::FooBarsController.class_eval # この定数が見つからない
  prepend ::MonkeyPatch::FooBarEngine
end

これは、config/environment.rbでconfig/application.rbを読み込んだ時点ではアプリの初期化が終わっておらず、オートロードの準備もできていないので、Railsエンジン配下の定数を探索できないのが理由。

オーバーライドに成功する例

結論に書いたとおり、config.prepare_toフックでオーバーライドする。prepare_toはアプリの初期化が終わった時点で呼び出されるので、オートロードも可能であり、Railsエンジン配下の定数を探索することもできる。

意図せず関連先のカラムでwhereしつつeager loadしたらクエリのパフォーマンスが極端に悪化した事例

問題

15個ぐらいのさまざまなクエリパラメータを検索条件として受け付けることができる一覧取得API(「Item取得API」とする)があった。

そのAPIで取得するItemは複数の関連を持っていた。また、関連先の取得時にN+1問題の対策が不十分だったので、取得するデータで必要な関連先を漏れなくincludesでeager loadした結果、ほとんどのケースでパフォーマンスが改善していた。

しかし、あるクエリパラメータ(qとする)を使うときだけ極端にAPIのパフォーマンスが悪化するという現象が見られた。

先に結論

よく言われていることですが、関連先の取得方法が複雑になりそうなら、preload/eager_loadで読み込み方法を明示的に指定して、意図したクエリを作るようにしましょう。

原因

元々のコードは次のようなイメージ*1:

# ItemsController
def index
  relation = current_user.items

  # クエリパラメータに基づくたくさんのwhere ...
  if params[:q]
    relation = relation.where(genre: { q: params[:q] })
  end
  # さらに続く...

  # 関連先を漏れなくincludes
  relation = relation.includes(
    :genre,
    :sub_items,
    user: :store,
    category: {
      user: :store,
      :sub_items
    }
  )

  # JSONにしてrenderして終わり
end

qは関連先テーブルのカラムをWHEREの条件として用いるときのパラメータ。そのパラメータをAPIに渡してwhereで絞り込みをかけるときだけ、関連先テーブルのカラムでWHEREすることになる。

このとき、Item取得と同時に関連先のテーブルの情報で絞り込みをかける必要があるので、includesはLEFT JOINを発行するeager_loadの挙動となる。すると、includesは指定したすべての関連先を(たとえ他の関連先テーブルのカラムでWHEREするわけではなくても)LEFT JOINで読み込むことになる*2*3

関連先のテーブルすべてをLEFT JOINすると、テーブルの構造が原因で本来取りたいデータセットの行数の3乗程度の数のデータを取得しようとして、DB側でメモリを使い尽くして*4エラーになっていた。

もう少し詳しい経緯

同じ関連先を複数回includesの引数としていた

モデルItemの関連先どうしも関連を持っていた。たとえば、Itemが持つsub_itemscategoryについて、それらどうしやuserへ関連を持つイメージ。これにより、includesの引数に同じ関連先が複数回出てくることがあった:

relation.includes(
  :genre,
  :sub_items, # 1回目
  user: :store, # 1回目
  category: {
    :sub_items # 2回目
    user: :store, # 2回目
  }
)

例えばuserstoreは関連元Itemのメソッドでuser.store.foo?のようにアクセスされるのに加えて、Category#barでもuser.store.bar?のようにアクセスされていた。このとき、たとえばcategoryのネストした関連先指定を省くと、Category#barの呼び出しが複数回あるときに都度クエリが発行されてしまうので、上のように書かざるをえない*5

同じテーブルが複数回LEFT JOINされていた

上記のように関連先を指定していてeager_loadを使うとき、includesへの指定の仕方が2通りあることから、sub_itemsは2通りの結合条件でLEFT JOINされる。細かい点は説明しないが、テーブルの構成的に、このように2回LEFT JOINすると本来取りたい行数の2乗の数データが取得されてしまっていた*6。実際の事例ではもう少し込み入った感じになっていて、実際に取りたい行数の3乗程度の行数を取得しようとしていた。

解決法

解決法は簡単で、問題となったクエリパラメータを使うテーブル以外の関連先テーブルはつねにpreloadを明示的に指定するだけ。qでの絞り込み用のカラムを持つ関連先テーブルはincludesのままにする。

def index
  relation = current_user.items

  # ...
  if params['q']
    relation = relation.where(genre: { q: params['q'] })
  end
  # ...

  # whereで使わない関連先を漏れなくpreload
  relation = relation.preload(
    :sub_items,
    user: :store,
    category: {
      user: :store,
      :sub_items
    }
  )

  # whereで使われるかもしれないのでincludes
  relation = relation.includes(:genre)

  # JSONにしてrenderして終わり
end

問題のパラメータを指定しなければpreloadで読み込んでくれるし、必要なときはeager_loadになる。

今回は、テストの規模ではそこまで遅くなることに気付けなかったのと、問題のパラメータ指定時のクエリを見ていなかったのが敗因。単純なケースならincludesのほうが考えることが少なくて便利だが、関連先の取得方法が複雑になってきたら横着せずにpreloadや(今回は使わなかったが)eager_loadで関連先の読み込み方法を明示的に指定したほうがよい。

*1:出てくるモデルや関連はすべて仮のもの

*2:https://github.com/rails/rails/blob/7b5cc5a5dfcf38522be0a4b5daa97c5b2ba26c20/activerecord/lib/active_record/relation/finder_methods.rb#L379

*3:ちなみに他のクエリパラメータだけ使うときは、関連元テーブルitemsのカラムでWHEREしており、関連先テーブルは複数のクエリで取得するpreloadの挙動になっていた

*4:数十万〜の行数を一発で取ろうとしていた

*5:必ずItemの関連から引くようにするなどより大きい範囲でコードを改善をするのがベターだが、いまはそれができないという仮定

*6:いわゆるproductとproduct variantとoptionのような構成でproductとproduct variantそれぞれにoptionをLEFT JOINしたのに近い cf. https://shopify.dev/docs/admin-api/rest/reference/products/product-variant

リソースとActive Recordのモデルのあいだの差異を吸収するクラスを作る

Web APIのリソースとバックエンドで扱うモデル(特にActive Recordのモデル)に歴史的な事情で差異があり、単純にモデルからリソースへと変換できないとき、それらの差異を吸収するクラスを作って対応することがあったのでメモを残しておきます。


問題

あるWeb APIに、親リソース*1authorが1:Nで持つ子リソースbookの一覧だけを返すエンドポイントGET /booksを追加しようとしていた*2。追加するエンドポイントが返すリソースの例を示す:

{
  "books": [
    {
      "id": 1
      "author_id": 1,
      "title": "Bar",
      "publisher": "Baz, Inc.",
      "released_at": "2020-01-01"
    },
    // ...
  ]
}

なお、従来から、親リソースGET /authorsを取得するときにはbooksも取得はできていたとする。また、既存のAPIリソースはActive Model Serializer (AMS)で生成しているとする。

このエンドポイントで返すリソースが持つフィールド、リソースに対応するActive Record (AR)のモデルの属性、データベース上の対応するテーブルのカラムには、それぞれ微妙にズレが見られた。具体的には次のような問題があった:

  1. ARのモデルが持っている属性の一部だけがリソースの属性となる
  2. テーブルのカラム名とリソースのフィールド名/モデルの属性名が異なる
  3. APIリソースのフィールド名とARモデルのリレーション名が被っている

まず、ARのモデルが持っている属性、すなわち対応するテーブルが持っているすべてのカラムのうち一部だけがリソースの属性となっていた。この場合、リソースを表すJSONに変換するときにフィルタする必要がある。

create_table :books do |t|
  t.column :title, :string
  t.column :release_date, :date
  t.column :memo, :string # リソースには含めない
  # ...
end

また、テーブルのカラム名をよりわかりやすくするために、その後に作られたモデルやAMSのシリアライザでは改名された属性名を使っているケースがあった。

class Book < ApplicationRecord
  alias_attribute :title, :name
end

class BookSerializer < ActiveModel::Serializer
  def released_at
    object.release_date
  end
end

さらに、特殊な事例だが、ARのモデルではリレーションとして定義されている名前が、AMSで生成されるリソースではスカラーな値として提供されているケースがあった。

class Book < ApplicationRecord
  belongs_to :publisher
end

class Publisher < ApplicationRecord
  has_many :books
end

class BookSerializer < ActiveModel::Serializer
  attributes :publisher

  def publisher
    object.publisher.name
  end
end

後述するが、このケースでAMSを使わないようにする場合、リソース用に加工したフィールドの値を作る必要がある。しかし、今回はリレーションとしてそのフィールドと同名のメソッドが存在するので、メソッド名に気をつけないと、そのリレーションを使っている他のコードが壊れてしまってうまくいかない。

今回は、既存のコードをできるだけ変えずにこれらの問題に対処しながら、エンドポイントGET /booksを追加したいとする。

リソースとモデルの間の差異を吸収する層を導入する

問題を解決するために、リソースとモデルの間の差異を吸収する層を導入する。今回はAMSを使わず実現した*3。POROにActive Modelを組み合わせて使う。

次のようにリソースのフィールドとモデルの属性のマッピングを持たせたクラスを書く。リソースだけで使うメソッドはモデルに書く。

class Book < ApplicationRecord
  # ...

  concerning :Api do
    def publisher_name
      publisher.name
    end
  end
end

class Book::ListResource
  include ActiveModel::Model

  attr_accesor :books

  ATTRS_AND_METHODS = {
    id: :id,
    author_id: :author_id,
    title: :title,
    publisher: :publisher_name,
    released_at: :release_date
  }

  def build
    books.map do |book|
      ATTRS_AND_METHODS.map { |attr, method|
        [attr, book.send(method)]
      }.to_h
    end
  end
end

次のように使う。

# コントローラ内での利用例
@books = Book::ListResource.new(
  books: Book.order(:id).limit(20)
)

# JBuiderのテンプレート
json.books @books

感想

  • pros
    • 既存の実装に影響を与えず、コントローラからもシンプルにリソースを生成できた
  • cons
    • ATTRS_AND_METHODSのようなマッピングを書かないといけない
    • 新しい層を導入するので設計意図をなんらかの手段で伝える必要がある

*1:リソースは「APIが返すデータの構造」ぐらいの意味合いとする

*2:これはあくまでも例

*3:内部事情