


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

## 前提として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


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




Next.jsとRuby on RailsのプロジェクトをDockerを通じて環境依存せず指定した言語バージョンで構築する

## アーキテクチャの指定

ローカルがM1 Macでデプロイ先が非armの時などケースバイケースで

```bash
export DOCKER_DEFAULT_PLATFORM=linux/amd64
```

## Ruby on Rails

```bash
docker run --rm -v $(pwd):/app -w /app ruby:3.1.1 bash -c "gem install rails && rails new my-backend-website"
```

## Next.js

```bash
docker run --rm -v $(pwd):/app -w /app node:17.8.0 npx create-next-app --example blog-starter-typescript my-frontend-website
```


<p>Next.jsとRuby on RailsのプロジェクトをDockerを通じて環境依存せず指定した言語バージョンで構築する</p>
<h2 id="アーキテクチャの指定">アーキテクチャの指定</h2>
<p>ローカルがM1 Macでデプロイ先が非armの時などケースバイケースで</p>
<pre><code class="hljs language-bash"><span class="hljs-built_in">export</span> DOCKER_DEFAULT_PLATFORM=linux/amd64
</code></pre>
<h2 id="ruby-on-rails">Ruby on Rails</h2>
<pre><code class="hljs language-bash">docker run --<span class="hljs-built_in">rm</span> -v $(<span class="hljs-built_in">pwd</span>):/app -w /app ruby:3.1.1 bash -c <span class="hljs-string">&quot;gem install rails &amp;&amp; rails new my-backend-website&quot;</span>
</code></pre>
<h2 id="nextjs">Next.js</h2>
<pre><code class="hljs language-bash">docker run --<span class="hljs-built_in">rm</span> -v $(<span class="hljs-built_in">pwd</span>):/app -w /app node:17.8.0 npx create-next-app --example blog-starter-typescript my-frontend-website
</code></pre>


UMIHICO BLOG.

#Next.js

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

WEBフレームワークをDockerで作るワンライナー