TalentX Tech Blog

Tech Blog

プロダクト間のAPI連携をモック化して開発効率を向上させるための取り組み

はじめに

はじめまして、TalentXの小野です!
TalentXでは、MySeries管理のバックエンドの開発を担当しています。

今回は、ローカル環境での開発効率を向上させるために、プロダクト間のAPI連携をモック化した話を紹介したいと思います。

課題:ローカル環境の複雑さ

TalentXのMyシリーズでは、各プロダクトがMySeries管理(各プロダクトで利用する求人やアカウントの共通管理ができるものです)を通じてAPIで連携しています。
しかし、ローカル環境での開発中にこれらのプロダクト間の連携を再現するのは、各プロダクトごとのセットアップやデータの準備が煩雑で時間がかかることが多く、開発効率が低下していました。

そこで、各プロダクト間のAPI連携をモック化することで、ローカル環境での開発効率を向上させることにしました。

直面していた問題

  1. 環境構築の複雑さ
    • 各プロダクトごとに個別セットアップが必要
    • 連携するためにデータの準備が必要
    • 環境不具合時の原因特定が困難
  2. リソースの消費
    • 必要なコンテナ数が多いために高いマシンリソースが必要
  3. 依存関係の管理
    • 他プロダクトの起動待ち時間の発生
    • 他プロダクトの変更による影響

解決策:OpenAPIとPrismを活用したモック化

TalentXでは、複数のプロダクト間のAPI仕様を、OpenAPI(Swagger)形式のYAMLファイルで一元管理しています。
このAPI仕様書を活用し、モックサーバーを自動生成できるツール「Prism」を採用することで、開発環境のモック化を実現しました。

Prismとは

Prismは、API設計ツールを提供するStoplight社が開発したオープンソースのHTTPモックツールです。 OpenAPI 2.0および3.0仕様に基づいて、ドキュメントから自動的にモックサーバーを生成できます。

モックサーバーの動作の説明

Prismを使用することで、以下のようなYAMLファイルを用意するだけで、モックサーバーを簡単に立ち上げることができます。

openapi: 3.0.0
info:
  title: Sample API
  version: 1.0.0
paths:
  /samples:
    get:
      responses:
        '200':
          content:
            application/json:
              schema:
                type: object
                properties:
                  id:
                    type: integer
                    minimum: 1
                  title:
                    type: string

モックサーバーを起動した後、/samplesエンドポイントにアクセスすると、次のようなレスポンスが返されます。

curl localhost:4010/samples 
{"id":1,"title":"string"}

Prism導入手順

1. Docker Composeの設定

Docker Composeを使用して、モックサーバーを含むコンテナを簡単に起動できるように設定しました。以下は、docker-compose.ymlファイルの設定例です。

services:
  mock-sample:
    image: stoplight/prism:4
    container_name: mock-sample
    ports:
      - "4011:4010"
   volumes:
      - ./spec.yaml:/spec.yaml
    command: mock -h 0.0.0.0 /spec.yaml
    profiles:
      - mock
  # ... 他のサービスの設定 ...

2. 環境変数の追加

コンテナからホストにアクセスしたいためhost.docker.internalを使用

MOCK_URL=http://host.docker.internal:4011

# TRUEを設定するとMOCKを利用します
USE_MOCK=true

3. エンドポイントの切り替え

Go言語での実装例

func NewClient() *Client {
    baseURL := os.Getenv("BASE_URL")
    if os.Getenv("APP_ENV") == "local" && os.Getenv("USE_MOCK") == "true" {
        baseURL = os.Getenv("MOCK_URL")
    }

    return &Client{
        baseURL: baseURL,
        httpClient: &http.Client{},
    }
}

導入効果

柔軟な開発環境制御の実現

  • 環境変数による選択的なモック化
# 環境変数での簡単な切り替え
USE_MOCK_A=true   # サービスAをモック化
USE_MOCK_B=false  # サービスBは実環境を使用
  • 必要なコンテナのみを起動
# モック環境のみを起動する場合
docker compose --profile mock up -d

# 通常の開発環境を起動する場合
docker compose up -d

システムリソースの最適化

  • メモリ使用量の削減
  • 起動時間の短縮
  • 開発マシンの負荷軽減

このように、Prismを活用したモック化により、開発環境のセットアップと運用が効率化され、快適な開発体験を実現することができました。
今後としては、新規参画メンバーのオンボーディング時間の短縮などにも期待できそうです。

導入時の注意点

Prismを使用したモックサーバーでは、OpenAPI定義に基づいてレスポンスデータが自動生成されます。そのため、数値型のフィールドでは、適切なバリデーション制約を設定しないと予期せぬ値が返される可能性があります。

問題のある定義例

以下のような定義では、数値フィールドに対する制約がないため、不適切な値が生成される可能性があります。

properties:
    id:
        type: integer
        format: int64
        description: 求人ID
    title:
        type: string
        description: 求人タイトル

↑この定義での実際のレスポンス

{
  "id": -9007199254740991,  # ← 負の値が生成されてしまう
  "title": "string",
}

推奨される定義例

適切なバリデーション制約を追加することで、より実践的なモックデータが生成されます。

properties:
    id:
        type: integer
        format: int64
        description: 求人ID
        minimum: 1 # ← 追加
    title:
        type: string
        description: 求人タイトル

↑この定義での実際のレスポンス

{
  "id": 1,  # ← 制約に従った適切な値が生成される
  "title": "string",
}

まとめ

Prismを使用したモック化の導入により、冒頭で挙げた環境構築の複雑さ、リソース消費の問題、依存関係の管理といった課題を全て解決することができました。
また、既存のOpenAPI定義を活用することで、想定していたよりも大幅に少ない工数で各プロダクトのモック化を実現することができました。

新規APIの開発においても、従来通りのOpenAPI定義の作成から始めることで、特別な対応や追加作業なしでモックサーバーが自動的に生成してくれます。これにより、運用コストを抑えながら開発環境を維持することが可能となりました。

今後も、開発効率を向上させるための取り組みを続けていきたいと思います。

最後に

最後までお読みいただきありがとうございました!

TalentXでは一緒に働く仲間を募集しております。 ご興味ある方は下記リンクの求人をご覧ください! talentx.brandmedia.i-myrefer.jp

カジュアル面談も行っていますのでぜひご応募ください。 i-myrefer.jp