[Refactor] WEVOTE - 데이터 Mocking (with MSW)

 

 

본 포스팅은 msw(v0.42.3)을 사용합니다

 

 

 

1. 구동중인 서버가 없는데, API 없이 프론트엔드 리팩토링을 어떻게 하지?

이전 프로젝트를 혼자 리팩토링 하기로 결정하고 코드를 다시 확인하는데, 서버가 닫혀있으니 당연하게도 API 통신이 되지 않았다. 프로젝트 진행 당시에는 백엔드 개발자와 첫 협업이라 전체적인 업무 프로세스에 대한 이해가 부족했기 때문에 처음 나온 계획은 다음과 같았다.

 

1) 전체 팀원들과 회의를 통해 기능 기획 및 API 명세를 정함

 

2) 디자이너 : 기능을 디자인해서 FE에 전달

    백엔드 : API 명세로 API 개발하여 FE에 전달

    프론트엔드 : 디자인과 API를 통해 개발

 

3) 완성

 

문제는 위의 경우 업무의 흐름이 동기적이기 때문에 상당히 비효율적이라는 것이다. 실제 업무에서는 디자이너, 백엔드 개발자가 일할 동안 프론트엔드는 놀고 있을 수 없지 않은가. (물론, API 없이 개발할 수 있는 영역에 한해서는 프론트엔드도 작업할 수 있겠지만)

 

그래서 당시 나는 API 명세를 보고 json 파일을 만들어 dummy data를 만들고 원하는 곳에서 import하여 데이터를 사용할 수 있도록 했다.

그렇게 모아진 dummy data

당시에는 '어떻게 일할 것인지' 고민하는 것보다 '어떻게 구현을 해야할 것'인지에만 신경이 집중됐을 때라 불편함이 있음에도 그냥 진행했지만, 이 방식은 dummy data를 사용할 때와 실제 API를 사용할 때 코드를 직접 수정해야한다는 큰 비효율의 문제를 가지고 있다. 그리고 데이터만 사용할 수 있지 HTTP 메서드와 응답 상태에 따른 loading, error 처리 등 실제 개발에서 신경써야할 다른 부분에는 대응하기가 어렵다는 단점도 있다.

// Notice 컴포넌트 예시


// dummy data 사용을 위해 json 파일 import
import data from '@dummyData/NoticeData.json';


function Notice(props){
	// 실제 API를 통해 불러오는 data
	const {loading, data, error} = useFetch('/api/v1/main/notice');
    
    
    // 위의 data 변수 중 하나는 주석처리하고 사용해야한다
}

 

 

별도의 dummy data 파일이 아닌, API처럼 사용하는 mocking system은 없을까?

결국 백엔드에서 API가 완성되지 않아도 프론트엔드에서 API가 있는 것처럼 원활하게 개발할 수 있는 환경이 주어진다면 더 좋은 효율을 이끌어낼 수 있을 것이다. 그리고, dummy data와 같이 별도의 파일을 불러오는 방식이 아닌 API 호출과 동일하게 data를 사용할 수 있는 방식이면 더 좋을 것이다. 이를 가능하게 하는 것이 msw를 활용한 mocking system이다.

 

Mock Service Worker

 

---

MSW(Mock Service Worker)는 무엇인가?

간단하게 말하자면, HTTP 요청을 가로채서 mock data를 대신 전송해주는 mocking library다.

프론트엔드 개발 단계에서 필요로하는 것은 http request, http response, http 메서드, http 상태코드 등 네트워크 통신과 결과물이다. msw가 서비스 워커를 통해 네트워크 요청을 가로채서 미리 정의한 메서드나 상태코드에 따라 reponse하는 방식으로 동작하기 때문에 개발자가 작성할 코드는 실제 API 요청과 동일하게 작성할 수 있는 것이다.

 

 

Service Worker란 무엇인가?

msw 공식문서 발췌

 

서비스 워커는 웹 애플리케이션의 메인 스레드와 분리된 별도의 백그라운드 스레드에서 실행시킬 수 있는 기술로, 스레드가 다르기 때문에 서비스 워커가 실행되더라도 애플리케이션의 블록킹 발생 없이 동작할 수 있다. 웹 서비스와 브라우저 및 네트워크 사이에서 프록시 서버의 역할을 하며, 오프라인에서도 서비스를 사용할 수 있도록 한다. 서비스워커는 프론트엔드 개발자들이 수년간 어려움을 겪었던 문제들을 해결했는데, 웹 사이트 자원 캐싱이나 알림 처리 등 많을 것을 할 수 있게 되었다. 서비스 워커는 매우 강력하기 때문에 안전한 컨텍스트(HTTPS)에서만 실행된다.

 

 

msw는 어떻게 사용하는가?

공식문서 example이 친절한 편이라 사용 방법은 가이드만 따라도 이해할 수 있는 수준이다.

 

1) mockServiceWorker.js를 public에 설치한다. (주의. index.html을 통해 실행되는 파일이 아니다. 서비스워커다.)

 

2) 개발환경에서만 사용할 것이기 때문에 development 환경에서만 실행되도록 entry파일에서 작성한다.(msw가 정상 동작한다면, [MSW] Mocking enabled라는 메시지가 브라우저 콘솔에 뜬다)

 

3) mocks/browser를 통해 작성한 mock handler의 worker를 실행한다.

 

4) 각 컴포넌트에서 명세에 맞는 API 요청을 사용하며 테스트한다.

 

msw가 development 환경에서만, 먼저 실행되도록 index.js에서 실행

 

나는 express로 API 개발을 해본 경험이 있어서 크게 낯설지는 않았지만, 자세한 내용은 msw 공식문서의 가이드를 따라 직접 사용해보면 쉽게 이해할 수 있을 것이다. 아래의 코드는 공식 문서에서 소개하는 예시인데, HTTP 메서드를 구분하여 작성할 수 있고, HTTP status 코드에 따른 대응이나 스토리지를 사용할 수도 있다. (프론트엔드도 분명 서버 개발 경험이 있으면 좋다.)

// src/mocks/handlers.js
import { rest } from 'msw'
export const handlers = [
  rest.post('/login', (req, res, ctx) => {
    // Persist user's authentication in the session
    sessionStorage.setItem('is-authenticated', 'true')
    return res(
      // Respond with a 200 status code
      ctx.status(200),
    )
  }),
  rest.get('/user', (req, res, ctx) => {
    // Check if the user is authenticated in this session
    const isAuthenticated = sessionStorage.getItem('is-authenticated')
    if (!isAuthenticated) {
      // If not authenticated, respond with a 403 error
      return res(
        ctx.status(403),
        ctx.json({
          errorMessage: 'Not authorized',
        }),
      )
    }
    // If authenticated, return a mocked user details
    return res(
      ctx.status(200),
      ctx.json({
        username: 'admin',
      }),
    )
  }),
]

 

+추가

msw 공식문서에서는 React 프로젝트 예시에서 CRA를 사용한 코드를 제공했는데, 나처럼 CRA를 사용하지 않고 직접 webpack을 설정하며 프로젝트를 구성한 사람들을 위해 내가 경험했던 이슈 경험을 공유한다.

2022.07.15 - [Development/Issue] - [Issue] msw + webpack-dev-server 동작 이슈

[Issue] msw + webpack-dev-server 동작 이슈

 

 

---

마무리

  리팩토링을 진행하기에 앞서 mocking 시스템을 바꿨는데, msw를 통해 한결 수월해졌다. 유지보수성에 한 몫을 하는 것은 수정이 덜 발생하게 혹은 수정이 쉽도록 코드를 작성하는 것이 아닐까 생각이 든다. 그리고 msw를 통해 service worker을 알게 되었는데, 꽤 활용 가능성이 많은 기술인 것 같아 앞으로 유심히 살펴봐야겠다.

 

  몇 년 전까지 프론트엔드 개발자의 영역은 단순 퍼블리싱에 가까웠다고 한다. 하지만, 기술이 발전하며 서비스가 고도화되고, 더 많은 사용자와 더 좋은 UX를 위해 프론트엔드 개발자의 역할도 중요해지고 더 많아진 것으로 보인다. 더 나은 퍼포먼스를 위해 SPA가 등장하고, 다시 더 나은 퍼포먼스를 위해 SSR 기반의 Next.js 같은 기술들이 등장하며 프론트엔드에서 사용하는 기술도 갈수록 전문적이 되어가고 있다. msw나 graphql처럼 API를 다루는 영역에도 조금씩 관여하고 있는 프론트엔드는 앞으로 더 다양해질지 모른다는 생각이 든다. 그렇기 때문에 프론트엔드 개발자는 지금의 나의 역할을 프레임화하여 생각하기 보다는 소프트웨어 전체적으로 어떤 문제들을 어떻게 해결할 것인가에 집중하는 자세가 필요하지 않을까. (업무 흐름의 문제를 해결하기 위한 msw 처럼..)

 

 

 

---

참고자료

https://tech.kakao.com/2021/09/29/mocking-fe/

Mocking으로 생산성까지 챙기는 FE 개발

https://so-so.dev/web/service-worker/

ServiceWorker 이모저모 이야기