なんとなく「APIってデータベースの設計がそのまま反映されるもの」ってイメージ、わたしも最初持ってたんだよね💭 でも実際やってみると、これがけっこうややこしいことに…😳
たとえば、DBのスキーマをそのままAPIにしちゃうと、DBの変更がAPIのクライアント側をバリバリ壊すことが多くて、ヒヤヒヤしちゃうのよ💦
しかも、DBの内部事情がAPIから丸見えになったり、後から整理（リファクタリング）しようとすると超大変だったり…うーん、やっぱり何か違う気がするなぁって感じるよね✨
APIはDBとは別の「約束事」だと思う
APIっていうのはクライアントが使いやすいように設計された独自の契約みたいなもの。
だから、DBのテーブル構造にピッタリ合わせる必要はないんだよね💡
例えば、DBには複雑なジョインや中間テーブルがあっても、APIではもっとシンプルに「このデータだけほしい！」を叶える形で設計できる✨
そうすると、クライアントも使いやすいし、バックエンド側もDBの細かい変更をAPIに影響させずに済むからラクチンなのだ👍
どうやって分ける？API設計 vs DB設計
ここで悩むのが、「DBを先に作るべき？それともAPI先行？」ってところ🤔
わたしが思うに、
- APIを先に考えると、ユーザーが本当に欲しい情報や機能にフォーカスできる
- 逆にDBから作ると、データの整合性や効率が考えやすいメリットがある
でも、最初から両方バラバラに作るのは難しいし、結局どっちかに引っ張られちゃうことも多いよね💦
だから、ポイントは「APIはDBにただ従うだけじゃなくて、ちゃんと独立した設計を意識する」ことかなって思うよ🌸
たとえDBが変わっても、APIのインターフェースは変えなくて済むように工夫するのが大事✨
まとめると…
- APIはDBの1:1コピーにしないほうがいいよ！
- APIはクライアントのニーズに合わせて設計するのが理想
- DB設計とAPI設計は別モノと思って、両方のバランスを取るのがカギ
まあ、最初はわたしも混乱してたけど、こうやって考え方を切り替えたらちょっと気持ちが楽になったかも💭
APIとDBは別々の会話をしてるイメージでやると、変なトラブル減るんじゃないかな〜って思ったよ🥺✨
はてな
コメント
ハンナ
APIとDBは別物にする派だけど、マッピングは絶対手動でやれ。 自動ツールとか魔法みたいなのは火山にでも投げ捨てたい。
ハンナ
以前、Reactフロントの新ウェブアプリ案件を引き継いだら、前任者はDBテーブルごとにAPI作ってクライアント側に調整させてて超カオスに。 Railsはこういうパターンが多い気がする。
レオ
結局API側で調整する設計に作り直したら何年も安定して、モバイルチームもすぐ使えて超スムーズだったから、この方針は超おすすめ。
リリー
レスポンスのフォーマット場所は変わってもニーズの変化問題は同じ、大企業ならそこは問題にならない。
クリス
まずAPI設計から始めて、フロントとバックエンドの契約にしよう。 DBはクエリや容量最適化重視で、フロントは必要なデータをAPIで取って使いやすく加工すればOK。
クリス
自分はたいていリポジトリ、サービス、プレゼンテーションの3層構造にしてる。 ゆるく結合しドメインモデルでやり取りすると手間はかかるけど結果的に楽になる。
ロバート
昔はバックエンドがCRUDだけ作ってフロントがそれ使うのが普通だったけど、EAで専属のHTTP開発者がいてフロントに合わせたAPI作ってたのが目から鱗だった。
グレース
ミドルウェアで後方互換性処理を詰め込むのはどうなんだろうね。 新しいスキーマで動的に対応するのは頭痛いからちゃんとマイグレーションしろって話。
キンバリー
DBスキーマはあくまで内部実装で、型の変換はDB層がやるもの。 自分はグローバル型やコアAPIの型定義でサービス間をつなげてる感じ。
サラ
業界6ヶ月の新人だけど、こういう記事はありがたい。 まだ問題に直面してないかもだけど今後気をつけたい。
ハンナ
うちの職場でもよくある話で、単純だけどバックエンドに改善説得するのはマジ大変。
ジョージ
APIはReact単独用なのに契約は超汎用的。 公開APIなら使い道わからないから仕方ない面もあるけどね。
リリー
.NET開発者としてはDTOとプロジェクションでやるのがベストだと思ってる。
ノーラン
スキーマ、スキーマ、スキーマ！
キンバリー
ドメインオブジェクトをアプリの中心にしてDBやAPIのモデルとマッピングしよう。 Pythonならpydanticやmarshmallowが便利。
ハンナ
スキーマ変えたら必ずどこか壊れるだけ。 そんなの時間の無駄で保守性も落ちる。 不要な層は増やすほど面倒になるよ！
