AWS 基礎コース / Chapter 02

AWSへ出す前に、ローカルでアプリとDBを再現する

クラウド構築の前に、データが入ったDBとHTTPで応答するAPIを手元でつなぐ。壊れたときにどの層を見るかまでがこの章の到達点。

TL;DR

  1. migrationはスキーマを、restoreは学習・開発に使う初期データを再現する。
  2. DBクライアントでテーブルとデータを直接確認すると、アプリの応答を裏側から説明できる。
  3. 最後はlocalhostのAPIがworkspace IDを受け、DBのデータを返すところまで確認する。

01再現する最小構成を分ける

PostgreSQL、移行ツール、APIを一度に曖昧にしない

ローカルのdb-migrator、PostgreSQL、Go APIの接続
先にDBの状態を作り、その後にAPIから読む。

Docker ComposeでPostgreSQLを起動し、db-migratorがDBの構造を整える。その上でGo APIを起動するため、HTTPの失敗をDB未準備と混同しにくい。

この章の構成はAWSの完成形そのものではない。まず「アプリが必要とするDB状態」を可視化するための実験環境である。

02スキーマとseedを別の操作として扱う

テーブルがあることと、画面・APIで使えるデータがあることは別

migrationとrestoreでDBを作る流れ
構造を作る操作と、初期データを入れる操作を分けて観察する。

migrationを実行しても、APIが返すべきレコードは自動で現れない。restoreによりseedデータを入れることで、開発用の入力が揃い、APIの成功・失敗を意味のある形で確認できる。

テーブル作成が成功していてもデータが空なら、APIの空レスポンスはアプリ不具合とは限らない。

03HTTP応答をDBの事実へ戻して検証する

curlだけで終えず、どのデータが返ったかを説明できるようにする

curlのAPI応答をTablePlusのDBデータと照合する流れ
HTTPの結果をDBのデータと照合すると、接続全体を説明できる。

localhostのchannels APIへworkspace IDを付けて呼び、レスポンスを得る。続けてDBクライアントで同じworkspaceに関係するデータを確認すれば、API・DB・seedの関係を一本の流れとして把握できる。

成功条件は「プロセスが起動した」ではなく、「意図したデータをHTTPで取得できた」ことである。

結論

  1. ローカルではDBの構造、データ、HTTP応答を順に再現する。
  2. migrationとrestoreを混同しないと、空データの原因を正しく見分けられる。
  3. AWS構築前にこの最小構成を説明できる状態にする。