cat posts/%e3%83%95%e3%83%ad%e3%83%b3%e3%83%88%e3%82%a8%e3%83%b3%e3%83%89%e3%81%a8%e3%83%90%e3%83%83%e3%82%af%e3%82%a8%e3%83%b3%e3%83%89%e3%82%92%e4%b8%a1%e6%96%b9%e3%82%84%e3%82%8b%e3%82%a8%e3%83%b3%e3%82%b8.md

フロントもバックも書くワイが API 設計で気をつけとること

1 風吹けば名無し 2026/05/23(土) 21:04:00 ID:Fs8Ta3ck
フロントとバックを分業しとるチームに入ったとき、「これフルスタックやってへんと気づきにくいな」と思う場面がいくつかあったわ

2 風吹けば名無し 2026/05/23(土) 21:05:23 ID:Ly6nR4wm
たとえば

3 風吹けば名無し 2026/05/23(土) 21:06:08 ID:Fs8Ta3ck
>>2 API 設計をフロントの画面から考えるかどうかや
バックエンドだけ見とると「DB の構造に沿った API」を作りがちになる

4 風吹けば名無し 2026/05/23(土) 21:07:16 ID:Ly6nR4wm
>>3 それでええやん

5 風吹けば名無し 2026/05/23(土) 21:08:47 ID:Fs8Ta3ck
>>4 フロントが必要なのは「画面を描画するのに必要なデータ」であって、DB の正規化に付き合う必要はないんや
商品詳細ページなら、商品情報 + カテゴリ名 + 在庫数 + 入出庫履歴を1リクエストで取れるレスポンスが欲しかったりする

6 風吹けば名無し 2026/05/23(土) 21:09:40 ID:Ly6nR4wm
>>5 なるほどな

7 風吹けば名無し 2026/05/23(土) 21:10:56 ID:Gd3vM9tp
フルスタックなら問題ないやん

8 風吹けば名無し 2026/05/23(土) 21:11:34 ID:Fs8Ta3ck
>>7 それが罠なんや
一人でフロントもバックも書いとると「自分にとって都合のいい API」を無意識に作ってまう

9 風吹けば名無し 2026/05/23(土) 21:12:35 ID:Gd3vM9tp
>>8 困るんか

10 風吹けば名無し 2026/05/23(土) 21:13:59 ID:Fs8Ta3ck
>>9 後から別の人が使おうとしたとき「これ何のためのパラメータ?」ていう API が量産されとった

11 風吹けば名無し 2026/05/23(土) 21:14:45 ID:Gd3vM9tp
>>10 草

12 風吹けば名無し 2026/05/23(土) 21:15:54 ID:Fs8Ta3ck
>>11 「3ヶ月後の自分は他人」という前提で設計するようにしてから減ったわ

13 風吹けば名無し 2026/05/23(土) 21:17:26 ID:Nw7cB2hq
他に気をつけとることは

14 風吹けば名無し 2026/05/23(土) 21:18:20 ID:Fs8Ta3ck
>>13 「動いてるからいいか」が一番危ない
エラーハンドリングが雑、ログが出てない、テストがない、全部あとから「あのとき直しておけば」になる
動いた瞬間に少し追加投資する習慣あると、半年後の自分がちょっと感謝してくれるで