ざっくりとした理解
スキーマ駆動開発
要はAPIのレスポンスから開発していくスタイル
データ駆動開発
要はDBから開発していくスタイル
---
メリデメは一旦置いといて、開発方針としての違いは
スキーマ駆動開発
アップルパイが作りたい→りんごがいるな、パイがいるな…
みたいに成果物が軸にあるように見えた。具体的に言うなら機能ベースなイメージ
データ駆動開発
りんごがある、パイがある→だからアップルパイ作れるよね？
みたいにモノが軸にあるように見えた。具体的に言うならデータ軸なイメージ
---
スキーマ駆動開発のほうが自然といえば自然なんだけど結構難しい。なぜならデータベースを使う以上正規化の問題があるから
例えばブログサイトを作ろうと思ったとき、記事に対してタグやコメントは複数ついてくる。
テーブルに配列は突っ込まないものなので、テーブルを分割する必要がある（正規化）
機能軸で考えるとここの正規化部分を盛り込むことが難しい……
っていうのが悩みだった。
- こういう機能が欲しい
- ということはスキーマはだいたいこんな感じか…？
- ということはDBはこんな感じになってくるか…？
みたいな
更にそうやって考えていくと、このスキーマはまとめてしまっているけど分割してしまったほうがスマートではなかろうか…？
みたいになって、結局蓋を開けてみたらデータ駆動開発っぽくなってしまうという感じでした。
慣れたらなんやかんやうまくやれそうな気もしなくもないし、スキーマ駆動開発の何がいいってFastAPIのスキーマ定義していけばドキュメントの自動生成ができてとても助かるといったところもあるので、ひとまずやっていこうという気持ち
機能ベースなはずなので、いったんDBのことは考えないほうがいいのかなーとか思ったり。
なんとなくだけど責務は分散したいなとか思うので、なんらかのアイテムをpostしたいなというときはAPIを分けてしまったほうがいいのかなと思った。例えばAに紐付く配列Bがあったとして、それらをひとまとめにしてpostするのではなくAと配列Bで別々のAPIを使ってpostしていくみたいな…
重複チェックを走らせたいなんてときに全てひとまとめにすると処理が肥大化しやすいように思うし、柔軟性にかけるかなーという。
この辺開発のセオリーみたいなのがありそうで、まだまだ知識不足が否めない感じあります。
getはどうなんだろう。Aとそれに紐付く配列Bが欲しいと思ったときに、処理でJoinしてデータを渡すほうが自然な気がする。idでjoinするとして、APIのリクエストパラメータとしてidが渡せれていた場合、Aと配列Bそれぞれに対応するAPIを作って、それぞれからデータを取得。画面側でそれぞれ使っていくという形でも問題ないといえば無いけど、どっちがいいのだろうか…
postを分割していくならgetも分割していくほうがいいのかなぁ
ただその場合、例えばapiのurlが/api/A/idみたいにして特定のAを取得するようにした場合、/api/B/idのidがbのidではなくてAとBで共有しているID（この場合はAのidかなぁ）になるのがキモいなぁと思ったり。
postだったらpathパラメータとか使わないし別に分割してもいいように思うのだけど、getの場合pathパラメータ使うだろうしそうなるとさっきあげたみたいな感じになりそうなのがキモいなぁという/api/B/idはBのidに紐付くものが取れないとなんか嫌じゃねみたいな…
かといってqueryパラメータで対応するのもどうなんだろうというお気持ちがあったり…
optionalなqueryパラメータとしてA.idを設定しておいて、それがなければ全リスト返却みたいなapiでもいいのかな。Bのlistapiを作成して、それのqueryパラメータとしてA.idを書いとくみたいな
それだったら出来なくもないけど、Aが配列Bもあること前提みたいな感じだったらやっぱ一緒くたに来る方が気持ちいいような…
うーむわからん、API設計のベストプラクティス教えてほしすぎる
そんな感じの思考整理でした。結局API設計のベストプラクティスがわからないからなんとも言えない感じあったからそこの勉強からな気がしました。おわり
