MSW
MSW(Mock Service Worker)는 API Mocking 라이브러리로, 서버향의 네트워크 요청을 가로채서 모의 응답을 보내주는 역할을 합니다. 따라서, MSW 라이브러리를 통하면 Mock 서버를 구축하지 않아도 네트워크 수준에서 Mocking 할 수 있습니다.
MSW가 이러한 역할을 할 수 있는 이유는 Service Worker를 통해 HTTP 요청을 가로채기 때문입니다.
Service Worker가 뭐에요?
Service Worker는 웹 애플리케이션의 메인 스레드와 분리된 별도의 백그라운드 스레드에서 실행시킬 수 있는 기술 중 하나입니다. Service Worker 덕분에 애플리케이션의 UI Block 없이 연산을 처리할 수 있습니다.
이러한 특징으로 인해, Service Worker는 다음과 같은 기능에 많이 사용되고 있습니다.
- 네트워크가 원활할 때 동기화를 시켜주는 백그라운드 동기화 기능이나, 높은 비용의 계산을 처리할 때 또는 푸시 이벤트를 생성할 때 주로 사용됩니다.
- MSW의 동작 방식과 관계되어 있는, 네트워크 요청을 가로채는 행위도 수행할 수 있습니다. Service Worker가 애플리케이션과 서버 사이에서 Request를 가로채서 직접 Fetch에 대한 컨트롤도 할 수 있기 때문에 색다른 작업이 가능해집니다. 예를 들어, HTTP Request와 Response를 보고 캐싱 처리를 한다든지, 필요하다면 로깅을 한다든지 하는 여러 가지 새로운 동작을 만들어 낼 수 있습니다. MSW도 이 과정을 통해서 Request를 가로채서 Response를 Mocking하는 원리로 사용합니다.
참고로, Service Worker의 사용이 제한되는 경우도 있습니다.
- Service Wordker는 대부분의 모던 브라우저에서 지원하고 있으나, IE와 같은 일부 브라우저에서는 지원하고 있지 않습니다.
- 그 외에는, 기본적으로 localhost가 아닌 환경이라면 HTTPS 보안 프로토콜 환경이 필요합니다. Service Worker 중간에서 네트워크로 연결을 가로채고 조작할 수 있는 강력한 기능을 갖고 있기 때문에, Service Worker에서는 HTTPS가 기본적으로 제공되는 환경에서만 사용할 수 있습니다.
즉, MSW는 Service Worker를 기반으로 모의 API를 만들어내기 때문에 다른 프론트엔드에서 사용하는 수많은 라이브러리나 프레임워크에 종속적이지 않고 호환성에 문제없이 동작합니다.
MSW 동작 원리
먼저, 브라우저에 service worker를 설치합니다.
설치 이후부터는 브라우저에서 실제 이루어지는 요청을 Sevice Worker가 가로채게 됩니다.
Service worker에서는 해당하는 실제 요청을 복사해서 MSW에게 해당 요청과 일치하는 모의 응답을 제공받고 이를 브라우저에 그대로 전달하게 됩니다.
이러한 과정을 통해서, 실제 서버 존재 여부와 상관없이 실제 요청으로 이루어지지 않고 예상할 수 있는 요청에 대해 Mocking이 가능해집니다. 이렇게 Mocking이 가능해지면 API가 아직 준비되지 않았어도 다음과 같은 개발 방식을 선택할 수 있습니다.
MSW를 활용한 개발 방식
기획자가 요구 사항을 전달하면, 프론트엔드 개발자와 백엔드 개발자가 API 스펙을 합의하고 백엔드 개발자는 프론트엔드 개발자에게 API의 스펙을 제공합니다. 그 이후, 프론트엔드 개발자는 MSW를 통해 네트워크 레벨에서의 Mocking을 진행한 후, 애플리케이션을 개발하게 됩니다.
API 없이도 프론트엔드 개발자는 높은 완성도를 갖고 있는 수준에서 기획자와 미리 프론트엔드 애플리케이션을 확인하며 피드백을 주고받고, 그 사이 백엔드 개발자는 API 개발을 진행합니다. 이후 백엔드 개발자가 API를 제공하면, 프론트엔드 개발자는 별다른 작업 없이 MSW를 스위치 오프만 하면 Production으로 배포할 수 있는 형태의 개발 과정을 통해 개발을 진행할 수 있습니다.
MSW는 디버깅이 필요한 상황에서도 좋은 시너지를 만들어 낼 수 있습니다.
예를 들어, 특정 API 응답을 기준으로 에러가 발생해 디버깅이 필요한 상황이라면, 기존 서비스 로직을 전혀 건드리지 않고 오로지 MSW에서 Mocking을 만들어 내서 쉽게 디버깅 할 수 있습니다.
더 나아가, 이러한 장점은 기획자 등의 다른 누군가에게 각 화면을 공유하고 피드백을 받아야하는 상황이 발생했을 때에도, 추가적으로 MSW에서 해당 상황을 만들어낼 수 있도록 작업을 해 둔다면 별다른 서비스 로직의 수정 없이도 MSW를 통해 제공이 가능해집니다.
'FrontEnd > React' 카테고리의 다른 글
| React에서 CRA보다 Vite가 좋다고? - 프로덕션 버전으로 빌드하기 (0) | 2022.12.27 |
|---|---|
| MSW로 프론트엔드 개발 생산성 높이기! - MSW 사용하기 (0) | 2022.12.26 |
| MSW로 프론트엔드 개발 생산성 높이기! - Mocking을 해야하는 이유 (0) | 2022.12.23 |
| React에서 CRA보다 Vite가 좋다고? - 에셋 가져오기 (1) | 2022.12.20 |
| React에서 CRA보다 Vite가 좋다고? - 플러그인 사용하기 (0) | 2022.12.20 |