학습 기록
백엔드의 API가 완성되기 전에 API의 응답 결과 대신 사용할 수 있도록 만든 가짜 데이터.
단순하게는 로컬 변수에 선언하는 방법이 있고, 로컬 서버에 저장된 json 파일 등을 http get 요청으로 가져오는 방법도 있다. 그 외 Mocking을 도와주는 다양한 라이브러리도 존재하는데 MSW가 유명하다.
MSW는 API를 mocking 할 수 있게 해주는 라이브러리로 Service Worker API를 사용하여 실제 요청을 가로채 관찰하고 모의 응답을 보내준다.
백엔드와 함께 프로젝트를 진행하면 백엔드가 API를 만들어 줄 때까지 프론트엔드는 기다려야 상황이 생긴다. 이때 MSW를 사용하면 실제 API를 사용하는 것 처럼 MSW가 요청을 가로채서 원하는 mock 데이터를 가져다 주기 때문에 시간을 좀 더 효율적으로 사용할 수 있게 된다.
Service Worker API는 브라우저가 제공하는 API이기 때문에 SSR이 이루어지는 nodejs 환경에서는 사용할 수 없다. 그러나 MSW는 nodejs 환경에서도 기능을 제공하는데 이는 웹 환경을 모방하는 class를 자체적으로 선언해서 사용하기 때문이다.
SSR를 지원하는 MSW도 App router 환경에서는 제대로 작동하지 못한다. (v1.31 기준) 이는 두 가지 이유가 있다. 첫 번째로 MSW는 어플리케이션의 어느 위치에서든 모듈 patching을 전달해 줄 수 있는 프로세스가 필요하다. 보통 다른 페이지들의 최상위에서 작동하는 root layout이 이 역할을 하는데, Next.js는 root layout과 페이지의 프로세스가 분리되어 있어 한 프로세스에서의 patching이 다른 프로세스에 영향을 미치지 못한다. 두 번째로 Next.js의 페이지 기반 프로세스는 계속 무작위 포트에서 생겨나고 사라지는 방식이라서 MSW가 모든 포트를 커버하긴 어렵다. MSW issue
다른 Mocking 방법을 찾아보다 발견한 게 Next.js의 기본 기능은 Route Handler이다. Route Handler는 설정한 api path에 따라 응답 및 요청을 커스텀하여 사용할 수 있는 서버리스 함수이다. 응답과 요청을 MSW처럼 커스텀할 수 있고 GET, POST, DELETE, PUT 등의 다양한 메서드를 모두 사용할 수 있다는 점에서 Mocking 방법으로 채택하였다.
Mock data를 다른 파일에 모아서 저장한 뒤 Route Handler가 이를 응답에 사용하도록 구현한다. Route Handler의 path는 백엔드의 path와 동일하도록 설정한다. api url을 추상화하는 util 함수를 만들고 로컬 환경 변수에 따라 url을 백엔드의 것과 Route Hander의 것으로 변경할 수 있도록 구현한다.
이를 통해 컴포넌트 레벨에서는 로직 변경없이 Mock data와 실제 응답 데이터를 바꿔가며 사용할 수 있다.
Route Handler는 공식문서에는 언급되어있지 않지만 Client Component에서 정상적으로 사용할 수 있는 것으로 보인다. Server Component의 경우 build 중에 Route Handler와 함께 만들어지는 데 이땐 서버가 작동하는 상황이 아니기 때문에 렌더링 중에 Route Handler를 사용할 수 없다. 때문에 배포 환경에서는 Mock data를 제대로 fetch해오지 못하는 모습을 볼 수 있었다. Dev 모드에서는 Server Component와 Route Handler 모두 요청이 들어올 때 생성되어 작동하는 것으로 추측되고 이로 인해 Server Component에서의 Route Handler 사용에 문제가 없었던 것으로 보인다.
이러한 문제가 존재하지만 Mock data 자체가 개발 중에 필요한 기능이라는 것을 생각했을 때 Dev 모드에서만 작동하는 것도 의미가 있다고 생각해서 계속 사용하기로 선택했다. Route Handler는 이후 Next.js 버전에서 발전될 가능성이 높아 이후 Dev 모드에서 작동하지 않을 가능성은 적을 거라고 생각한다.