terada_life
目次

今回のセッション要約

テーマ

React / Next.js における API クライアント設計と、class から関数ベースへの置き換え方を整理した。

1. React / Next.js で API クライアントは class が多いのか

  • React / Next.js 全体としては 関数ベースが主流。
  • ただし、外部APIクライアントのように
    • 認証状態を持つ
    • 共通ヘッダーを持つ
    • retry / timeout / pagination を扱う 場合は、class で作るのも十分自然。
  • つまり、
    • UI / hooks / component → 関数文化が強い
    • API client / SDK / service → class も普通にある

2. 提示された IeyasuClient class の評価

提示コードは以下の責務を持っていた。

  • Secret Key から token を取得する認証処理
  • token の保持
  • ページネーション処理
  • retry / timeout 処理
  • 生の HTTP 通信の共通化

このため、単なる fetch ラッパーではなく、小さな SDK / 専用クライアントに近い構成であり、class と相性が良いと判断した。

3. class を関数ベースに変換

「関数ベースにして」という要望に対して、factory 関数 + クロージャで置き換える方針を採用した。

変換後のイメージ

  • createIeyasuClient(config) を呼ぶ
  • 内部で以下をクロージャとして保持する
    • baseUrl
    • token
    • config
  • 外に返すのは API 操作関数のみ
    • authenticate
    • getUsers
    • getMonthlyWorkOutputs

この方式のポイント

  • this が不要
  • new が不要
  • class の private 的な役割をクロージャで実現できる
  • React / Next.js の関数文化になじみやすい

4. ファクトリ関数の解説

ファクトリ関数について整理した。

定義

オブジェクトを作って返す関数。

例:

  • createDog()
  • createApiClient()
  • createIeyasuClient()

特徴

  • new を使わない
  • 内部状態をクロージャで閉じ込められる
  • class の private に近い表現ができる

今回の API client での意味

createIeyasuClient(config) は、

  • config を受け取って
  • token を内部で保持しながら
  • API操作関数を返す

ので、典型的なファクトリ関数と説明した。

5. API 数が増えた場合の考え方

API が増えた場合、1つの createApiClient() の中にすべてを詰め込まない方がよいと整理した。

悪い例

  • getUsers
  • getProjects
  • getTasks
  • getDepartments
  • ... を全部1ファイルに書く

→ 肥大化して保守しづらい

良い分け方

共通層

  • client.ts
    • 認証
    • retry
    • timeout
    • request 共通処理

リソース別モジュール

  • users.ts
  • workOutputs.ts
  • projects.ts
  • tasks.ts

束ねる層

  • index.ts

構成イメージ

lib/ieyasu/
├─ client.ts
├─ users.ts
├─ workOutputs.ts
└─ index.ts

6. 実際の分割構成を提示

IEYASU API クライアントを以下の構成で実装する完成形を提示した。

構成

lib/ieyasu/
├─ client.ts
├─ users.ts
├─ workOutputs.ts
├─ index.ts
└─ types.ts

各ファイルの責務

types.ts

  • HrmosConfig
  • IeyasuUser
  • IeyasuWorkOutput
  • IeyasuApiError

client.ts

  • token 認証
  • retry
  • timeout
  • request() の共通化
  • getIeyasuConfig()

users.ts

  • getUsers()

workOutputs.ts

  • getMonthlyWorkOutputs()

index.ts

  • createIeyasuClient(config)
  • createIeyasuClientFromEnv()

7. さらに増えた場合の発展

APIクライアントがさらに大きくなる場合は、service 層を追加する考え方も整理した。

役割分担

  • client.ts
    • HTTP 通信の土台
  • users.ts, workOutputs.ts
    • エンドポイントごとの API
  • service
    • 複数 API を組み合わせた業務ロジック

例

  • attendanceService.ts
    • users.getUsers()
    • workOutputs.getMonthlyWorkOutputs() を組み合わせて月次勤怠サマリを作る

8. 学習観点でのまとめ

今回のセッションでは、以下を重点的に理解した。

理解したこと

  • React / Next.js は関数文化が強い
  • ただし API client / SDK は class もあり
  • class の代わりに factory 関数 + クロージャ で状態を持てる
  • API が増えたら 共通 client と機能別モジュールに分割する
  • さらに増えたら service 層で業務ロジックを分ける

キーワード

  • API Client Pattern
  • Factory Function
  • Closure
  • Retry / Timeout / Pagination
  • Service Layer
  • Responsibility Separation（責務分離）

9. 最終的な設計の着地点

今回の題材においては、以下のような考え方が自然という結論になった。

  • 単純な API 呼び出しだけなら関数 export で十分
  • 認証状態や共通処理を持つなら factory 関数が有効
  • API数が増えたら
    • client
    • resource modules
    • service に分割する

つまり

「class を完全に避けるべき」ではなく、今回のようなケースでは関数ベースでも十分きれいに設計できる」 という整理になった。