


未完。日々メモを足してます。フルスタックな視点で最適なライブラリ選定、シリアライザーの責務、型の運用方法、ファイル構成を考察します。

## 前提としてJSON:APIを使っています。

- js-routes。RailsのAPI一覧を出力するライブラリであり、CIで常に更新しているので、フロントが消されたAPIを叩くような事態を型で防ぎます。
- jsonapi-serializer。コントローラーの返す値が属人的な定義でバラつかないようにしています。
- jsonapi-serializer。Railsが生成したJSON:APIに基づくフォーマットで返すので、そこから冗長なネストを外したりするために、デシリアライザーを利用しています。

## １モデルにつきシリアライザーと型も１つずつ。テーブルとモデル自体の分化に注力することで、シリアライザーの分化を避ける

API毎に同じモデルでもシリアライザーを複数作って、それぞれのニーズ毎に最低限必要なattributesを都度用意する案に反対しています。

仮に通信料さえ莫大になる大規模サービスなら、attribuets最適化のメリットは大きいですが、それであっても、フロントからattributesを絞るリクエストを付与して動的に制御する形で対応するべきであり、やはりモデルに対し存在するシリアライザーと対応する型は常に１つにすべきと思っています。

というのも、ニーズ毎にattributesが違うときは、そもそもテーブル設計が適切でない結果であることが多く、そもそもテーブル設計の見直しで解消すべきだからです。例としてブログサービスで考えます。

記事一覧(index)を表示したいときと、本文（contentカラム）は不要です。title, descriptionカラムだけで十分であり、contentが必要なのは記事個別ページです。ここで提案したいのは、そもそもarticlesテーブルにcontentカラムを含むのではなく、ariticle_contentsテーブルを別に作って、そこにcontentを格納するべき、ということです。

というのも、シリアライザーで絞ったところでcontentカラムがarticlesテーブルに含まれていると、DBとサーバーの通信では容量の大きいcontentカラムがロードされてしまうので、ここに無駄が生じています。

selectで絞ればよい、という論はその通りですが、少なくともRailsではクエリ次第でカラムが無いかもしれない、という状況は開発時の認知負荷が大きすぎます。

## テーブル分化のtips

articles/Article（テーブル名/モデル名）を分化したい場合、article_detail_contents/AritcleDetail::Contentやarticle_detail_hashtags/AritcleDetail::Hashtagという風にdetailという単語をよく使って、ネームスペースの衝突を防いでいます。（※Aritcleモデルが存在すると、Aritcle::Contentが作れないことを言っています。）

## シリアライザー内でアソシエーションに干渉するようなattributeを実装しない

relashinshipsで繋いでアクセスするよりも、シリアライザー内のattributeとしてアソシエーションを参照する形で、attribuetsをリッチにしてrelationshipsを設けない実装を見ます。

この方法自体に反対ではありませんが、「１モデルにつき１シリアライザー案」では、シリアライザーが不特定多数のコントローラーから使い回され、アソシエーションへの参照が任意になるため、attributeに設けると該当アソシエーションへのクエリの発火が強制になるので、避けるべきと考えます。

一方で、目的の数だけシリアライザーを作る場合は、常にattributesを最適化できる・するべきであると思います。

### 参考文献

- https://tech.stmn.co.jp/entry/2022/06/17/184034


未完。日々メモを足してます。フルスタックな視点で最適なライブラリ選定、シリアライザーの責務、型の運用方法、ファイル構成を考察します。
<h2 id="前提としてjsonapiを使っています。">前提としてJSON:APIを使っています。</h2>
<ul>
<li>js-routes。RailsのAPI一覧を出力するライブラリであり、CIで常に更新しているので、フロントが消されたAPIを叩くような事態を型で防ぎます。</li>
<li>jsonapi-serializer。コントローラーの返す値が属人的な定義でバラつかないようにしています。</li>
<li>jsonapi-serializer。Railsが生成したJSON:APIに基づくフォーマットで返すので、そこから冗長なネストを外したりするために、デシリアライザーを利用しています。</li>
</ul>
<h2 id="１モデルにつきシリアライザーと型も１つずつ。テーブルとモデル自体の分化に注力することで、シリアライザーの分化を避ける">１モデルにつきシリアライザーと型も１つずつ。テーブルとモデル自体の分化に注力することで、シリアライザーの分化を避ける</h2>
API毎に同じモデルでもシリアライザーを複数作って、それぞれのニーズ毎に最低限必要なattributesを都度用意する案に反対しています。
仮に通信料さえ莫大になる大規模サービスなら、attribuets最適化のメリットは大きいですが、それであっても、フロントからattributesを絞るリクエストを付与して動的に制御する形で対応するべきであり、やはりモデルに対し存在するシリアライザーと対応する型は常に１つにすべきと思っています。
というのも、ニーズ毎にattributesが違うときは、そもそもテーブル設計が適切でない結果であることが多く、そもそもテーブル設計の見直しで解消すべきだからです。例としてブログサービスで考えます。
記事一覧(index)を表示したいときと、本文（contentカラム）は不要です。title, descriptionカラムだけで十分であり、contentが必要なのは記事個別ページです。ここで提案したいのは、そもそもarticlesテーブルにcontentカラムを含むのではなく、ariticle_contentsテーブルを別に作って、そこにcontentを格納するべき、ということです。
というのも、シリアライザーで絞ったところでcontentカラムがarticlesテーブルに含まれていると、DBとサーバーの通信では容量の大きいcontentカラムがロードされてしまうので、ここに無駄が生じています。
selectで絞ればよい、という論はその通りですが、少なくともRailsではクエリ次第でカラムが無いかもしれない、という状況は開発時の認知負荷が大きすぎます。
<h2 id="テーブル分化のtips">テーブル分化のtips</h2>
articles/Article（テーブル名/モデル名）を分化したい場合、article_detail_contents/AritcleDetail::Contentやarticle_detail_hashtags/AritcleDetail::Hashtagという風にdetailという単語をよく使って、ネームスペースの衝突を防いでいます。（※Aritcleモデルが存在すると、Aritcle::Contentが作れないことを言っています。）
<h2 id="シリアライザー内でアソシエーションに干渉するようなattributeを実装しない">シリアライザー内でアソシエーションに干渉するようなattributeを実装しない</h2>
relashinshipsで繋いでアクセスするよりも、シリアライザー内のattributeとしてアソシエーションを参照する形で、attribuetsをリッチにしてrelationshipsを設けない実装を見ます。
この方法自体に反対ではありませんが、「１モデルにつき１シリアライザー案」では、シリアライザーが不特定多数のコントローラーから使い回され、アソシエーションへの参照が任意になるため、attributeに設けると該当アソシエーションへのクエリの発火が強制になるので、避けるべきと考えます。
一方で、目的の数だけシリアライザーを作る場合は、常にattributesを最適化できる・するべきであると思います。
<h3 id="参考文献">参考文献</h3>
<ul>
<li><a href="https://tech.stmn.co.jp/entry/2022/06/17/184034">https://tech.stmn.co.jp/entry/2022/06/17/184034</a></li>
</ul>

ワタシ的Next.js、Rails間のAPI通信ベストプラクティス

いつうっかりカラム追加時に場所を指定せず、timestapmsの後ろにカラムが追加されてしまって見栄えが悪くなってしまうので、updated_atが一番後ろにないとコケるテストを作成してみました。

rubocopにこういうルールあってほしいのだけど、見た感じなさそう

## 作ったテストはこちら

rails/spec/migration_spec.rb

```ruby
require "rails_helper"

RSpec.describe "DBのカラム順序が指定されてるかチェック", type: :helper do
 let(:sql) do
 "SELECT a.TABLE_NAME, a.COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS " \
 "as a LEFT JOIN INFORMATION_SCHEMA.COLUMNS as b " \
 "ON a.TABLE_SCHEMA=b.TABLE_SCHEMA and a.TABLE_NAME=b.TABLE_NAME and a.ORDINAL_POSITION < b.ORDINAL_POSITION " \
 'WHERE a.TABLE_SCHEMA in ("development", "test") and b.ORDINAL_POSITION is NULL ' \
 'and a.COLUMN_NAME != "updated_at" and a.TABLE_NAME != "schema_migrations";'
 end
 let(:sql_result) { ActiveRecord::Base.connection.execute(sql) }
 let(:invalid_columns) { sql_result.map { |row| row.join(".") } }

 it "テーブルの最後のカラムがupdated_atか否か。新たにカラムを追加する際にはポジションを必ず指定してください。" do
 expect(invalid_columns).to eq []
 end
end
```

いつうっかりカラム追加時に場所を指定せず、timestapmsの後ろにカラムが追加されてしまって見栄えが悪くなってしまうので、updated_atが一番後ろにないとコケるテストを作成してみました。
rubocopにこういうルールあってほしいのだけど、見た感じなさそう
<h2 id="作ったテストはこちら">作ったテストはこちら</h2>
rails/spec/migration_spec.rb
<pre><code class="hljs language-ruby">require &quot;rails_helper&quot;

RSpec.describe &quot;DBのカラム順序が指定されてるかチェック&quot;, type: :helper do
 let(:sql) do
 &quot;SELECT a.TABLE_NAME, a.COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS &quot; \
 &quot;as a LEFT JOIN INFORMATION_SCHEMA.COLUMNS as b &quot; \
 &quot;ON a.TABLE_SCHEMA=b.TABLE_SCHEMA and a.TABLE_NAME=b.TABLE_NAME and a.ORDINAL_POSITION &lt; b.ORDINAL_POSITION &quot; \
 &#x27;WHERE a.TABLE_SCHEMA in (&quot;development&quot;, &quot;test&quot;) and b.ORDINAL_POSITION is NULL &#x27; \
 &#x27;and a.COLUMN_NAME != &quot;updated_at&quot; and a.TABLE_NAME != &quot;schema_migrations&quot;;&#x27;
 end
 let(:sql_result) { ActiveRecord::Base.connection.execute(sql) }
 let(:invalid_columns) { sql_result.map { |row| row.join(&quot;.&quot;) } }

 it &quot;テーブルの最後のカラムがupdated_atか否か。新たにカラムを追加する際にはポジションを必ず指定してください。&quot; do
 expect(invalid_columns).to eq []
 end
end
</code></pre>

カラム追加時にupdated_atの後ろに来ないように、常に場所を指定させるrspec




見ている情報が古かったのか、ずっと誤った書き方をして以下のエラーと格闘していました

```bash
KeyError: 
Trait not registered: 
"title" referenced within "article" definition
```


## 誤ってた書き方

```ruby
factory :article do
  transient do
    title nil
  end
end

```

## 正しくはこう

```ruby
factory :article do
  transient do
    title { nil } # ここ
  end
end
```


見ている情報が古かったのか、ずっと誤った書き方をして以下のエラーと格闘していました
<pre><code class="hljs language-bash">KeyError: 
Trait not registered: 
&quot;title&quot; referenced within &quot;article&quot; definition
</code></pre>
<h2 id="誤ってた書き方">誤ってた書き方</h2>
<pre><code class="hljs language-ruby">factory :article do
 transient do
 title nil
 end
end
</code></pre>
<h2 id="正しくはこう">正しくはこう</h2>
<pre><code class="hljs language-ruby">factory :article do
 transient do
 title { nil } # ここ
 end
end
</code></pre>

UMIHICO BLOG.

#Rails

ワタシ的Next.js、Rails間のAPI通信ベストプラクティス

カラム追加時にupdated_atの後ろに来ないように、常に場所を指定させるrspec

transient使おうとしてTrait not registered referenced within definition