目次
APIは別リポジトリとして用意されていた
フロントエンド開発では、画面表示に必要なデータをAPIから取得するケースが多くあります。APIはフロントエンドとバックエンドをつなぐ“窓口”のようなもので、フロントからリクエストを送り、バックエンドからJSONなどのデータを受け取ります。
今回の案件では、APIがフロントとは別リポジトリとして用意されており、ローカル開発ではDockerで起動して利用する前提になっていました。
DockerでAPIを起動したがレスポンスが返らなかった
まずはAPIリポジトリを取得し、Dockerで起動しました。そのうえでフロントエンド側からデータ取得処理を実行し、APIにリクエストが届いているかを確認しようとしました。
しかし、実際にAPIを叩いてみても期待したレスポンスが返らず、設定や起動手順に不足があるのか、リクエストがそもそも到達していないのか、といった切り分けが必要な状態でした。ここで「いったん原因を調べる」フェーズに入りました。
原因を調べる中でMSWの存在を知った
原因調査として、フロント側のデータ取得処理や環境変数、APIの向き先（エンドポイント）などを確認していく中で、Mock Service Worker（MSW）がプロジェクトに導入されていることを知りました。
当初は「なぜこの仕組みが入っているのか」「何に使われているのか」が分からなかったのですが、コードを追っていくと、特定の条件下でMSWが有効になり、ネットワークリクエストを処理している可能性があることが見えてきました。
Mock Service Workerの役割を理解する
MSWは、ブラウザ（または開発環境）で発生するネットワークリクエストをインターセプトし、実際のAPIの代わりにモックレスポンスを返す仕組みです。つまり、フロント側のコードは通常どおりAPIを呼び出しているつもりでも、裏側ではMSWがレスポンスを返している場合があります。
この仕組みがあることで、実APIが未完成だったり、仕様が固まっていない段階でも、フロントエンド側のUIや状態管理の実装を先に進めることができます。
実APIが使えない状況でMSWを活用した
今回の状況では、実APIの確認や到達性の切り分けを進めつつも、フロントエンドの実装自体は止めずに進める必要がありました。そこで、すでに導入されていたMSWを利用し、APIレスポンスが返ってくる前提でUI実装を進める形を取りました。
MSWを使うことで、レスポンスの形式を仮定したうえで画面表示や状態管理を組み立てられ、エラー時や空データのケースも再現しやすくなりました。実APIが安定していない段階でも、フロント側の実装を前倒しできる点が大きなメリットだと感じました。
MSWはあくまで一時的な解決策
MSWは便利ですが、最終的には実APIに置き換える必要があります。モックと実APIでレスポンス仕様がズレていると、統合作業のタイミングで不具合が発生する可能性があるため、モックの内容は可能な範囲で実APIの仕様に寄せておくことが重要です。
一方で、APIが利用できない段階でも開発を止めずに進めるという意味では、MSWは非常に有効な選択肢だと感じました。
まとめ
APIをDockerで起動しても期待したレスポンスが得られず調査を進める中で、プロジェクトにMSWが導入されていることを知り、その役割を理解して活用することで、フロントエンド開発を止めずに進めることができました。
今後は、実API側の疎通を確認しつつ、MSWのモックを実仕様に合わせていくことで、実APIへの切り替えをスムーズに行えるようにしていきたいと考えています。
