2021年8月13日の日記

営業電話で、時給2,500円の外国人プログラマを雇わないかという電話がかかってきた。
そういえば自分の給料を時給換算していなかったと思い計算してみると、これよりも低かった。
それに気付いたときは辞めることばかり考えていた。
しかし、今の僕はまだ成果を出せていないので仕方のないことだと思う。
転職を考えるのは、数字として現れるような成果を出した後でいいと思う。
2年以内に仕事で何らかの成功を収めたいな。

Webアプリケーションの構築について

Webアプリケーションを構築していく上で気付いたことを書いていく。

Rest API の GET メソッドは「外部キーに紐付く情報」を返してもいい

たとえば一人のユーザーが一つの店舗に属するように RDB 上で設計した後、「ユーザーの情報を表示するコンポーネント」を作りたくなったとする。このとき、ユーザーテーブルは「storeID」などのカラムを持っていて、これをそのままHTTPクライアント側に返すと、クライアント側で別途「storeIDに紐付く店舗名」を取得する手間が発生する。これだけなら2リクエストだけで済むのでまだいいが、もし一人のユーザーが複数の店舗に属するよう設計した場合は、所属する店舗の数だけリクエスト数が増加する。

別途店舗一覧を取得するようにすれば2リクエストで済むが、店舗が多くなってくると辛くなる。

ここで、storeIDなどに紐付く情報を返してもいいことにする。たとえば次のようなレスポンスの形式にする。

interface GetUserResponse {
  id: number;
  storeID: number;
  storeName: string;
}

こうすることで、ユーザー情報を表示する際にも一度のリクエストで済む。

一行をフェッチする GetXXX 関数の戻り値を Promise<T> としたとき、複数行をフェッチする ListXXX 関数の戻り値は Promise<T[]> とする

これら関数に対応する API サーバーの実装は「id で where しているかどうか」だけが異なり、その他の SELECT 文は完全に一致している。

テーブルの行数が多すぎる場合は ListXXX 関数とは別に SearchXXX 関数などを作らなければならないが、そうでない場合は GetXXX と ListXXX だけを作成し、型も Promise<T> と Promise<T[]> といったように共通化できる。
これらを分けても保守が大変になるだけでいいことは多分ない。

疲れたので今日はここまで。