フロントエンドとバックエンドの命名規則と変換｜揃えようとして失敗した話

:::note ※FE/BEの命名変換で揉めた経験がない人向けの「実体験ベース」記事です :::

結論（私の判断基準）

• FE/BEで無理に揃えない
• API境界で変換する
• 変換層は最初から作っておく

私は「揃えた方が分かりやすい」と思って揃えようとした。失敗した。

🚀 JSON変換 → Case Converter

---

私が揉めた話

揉めた話1：FE/BEで揃えようとした

Pythonのバックエンドは user_name（snake_case）。JavaScriptのフロントエンドも user_name にした。

// ❌ フロントで snake_case を使った
const user_name = response.user_name;
const created_at = response.created_at;

ESLintが警告を出す。チームメンバーから「camelCaseに揃えてほしい」と言われた。直した。

言語の慣習に逆らうと、結局直すことになる。

揉めた話2：変換層を作らなかった

APIレスポンスをそのまま使っていた。snake_case と camelCase が混在した。

後から変換層を作ろうとしたが、どこで何を変換しているか分からなくなった。

変換層は最初から作っておくべきだった。

---

FE/BEで命名規則が違う理由

言語の慣習が違う。これは仕方がない。

側	言語	慣習
バックエンド	Python / Ruby / Go	snake_case
フロントエンド	JavaScript / TypeScript	camelCase

無理に揃えようとせず、それぞれの慣習に従って変換する。

---

変換しないと何が起きるか

// ❌ 統一感がない
const userName = response.user_name;
const createdAt = response.created_at;

読みにくい。ESLintが警告を出す。チームメンバーが混乱する。

// ✅ 変換後
const { userName, createdAt } = convertToCamelCase(response);

---

私の変換ルール

API層で変換する

fetch や axios のレスポンスを受け取った直後に変換。

// axios の場合
axios.get('/api/user').then(response => {
  const user = convertToCamelCase(response.data);
  // 以降は camelCase で統一
});

リクエスト時は逆方向

// フロント → バックエンド
const payload = convertToSnakeCase({
  userName: 'tanaka',
  createdAt: '2025-01-01'
});

---

FE/BEで名前を揃えるべきか

揃えない方が安全。

側	視点	命名例
BE	実体ベース（名詞）	User, Order
FE	役割ベース（文脈）	currentUser, selectedOrder

無理に揃えると、フロント側の名前が不自然になる。

---

迷ったときの判断

迷い	私の判断
FE/BEで揃えるか	揃えない
どこで変換するか	API層
変換層を作るか	最初から作る

---

この記事で解決しない場合

• DBの命名を知りたい → DB設計時のカラム名変換テクニック
• 命名規則の全体像を知りたい → 命名規則の使い分け

---

FE/BEで揃えようとすると、どっちかが不自然になる。変換層を作って、それぞれの慣習に従う。