API가 없는데요..

Jinux·2022년 9월 6일

Mocking 원티드 프리온보딩 프론트엔드

원티드-프리온보딩-프론트엔드

목록 보기

2/3

프론트엔드 개발 과정

프론트엔드 개발 과정의 가장 이상적인 과정은 아마 기획 → 백엔드 개발 → 프론트엔드 개발

이 순차적으로 진행되는 과정일 것 입니다. 왜냐하면 기획과 개발 과정에서 인터페이스의 변경이 있으면, 단계별 의존성에 따라 다시 작업해야 하는 경우가 생기기 때문입니다.

하지만 현실은 백엔드와 프론트엔드 개발을 동시에 진행하는 경우가 대부분일 것 인데요. 이 때 만약 API에 종속적인 부분이 있다면 프론트엔드는 대기할 수 밖에 없고, 만약 수정사항이 발생해 다시 작업해야 하지만 이 또한 API를 기다려야 하면 비효율적인 과정을 반복할 수 밖에 없을 것 입니다.

이런 대기 시간을 줄이고 백엔드와 최대한 병행해 개발을 하려면 API가 개발되기전에 프론트엔드 개발을 마치기 위해서 도움이 되는 방법이 바로 Mocking하는 것 입니다.

API가 필요해

사실 mocking을 하긴 했었습니다. 다만 더 “잘"하고 싶었는데요. 사건은 프리온보딩 코스를 진행하며 생겼습니다. 기업과제를 진행하는데 API를 따로 주어지지 않고 기능을 개발해야 하는 상황이였습니다.

우선 json파일로 mock 데이터를 생성해 개발을 진행을 했고 마무리했지만 많은 의문점이 생겼습니다. 실제로 api가 추후에 붙는다고 가정한다면 api를 붙이는 과정에서 다시 수정해야 할 것 임이 뻔했고 json 파일로 mock 데이터를 작성하니 get 요청은 가져오지만 post, put, delete 등등은 “했다 치고”가 된 느낌을 지울 수 없었습니다.

저는 그거보단 더 훌륭한 mocking을 사용해 이 느낌을 지우고 싶었습니다.

Mocking 방법

Mocking하는 방법에는 여러 방법이 있겠지만 저는 처음엔 간단하게 json 파일을 사용하여 진행했습니다. 화면에 필요한 데이터를 내부에 작성함으로써 빠르게 적용할 수 있었지만, HTTP 메소드와 네트워크 응답 상태에 따라 대응하기 어려웠습니다.

반대로 Mock 서버를 별도로 만드는 방법도 있습니다. 이 방법은 서비스 로직을 수정하지 않아도 되는 장점이 있지만 Mocking을 하는데 비용이 많이 들어간다고 생각이 됐습니다.

그래서 실제로 API를 사용하는 것처럼 네트워크 수준에서 Mocking을 하고 싶었습니다. 그러던 중 MSW라는 API Mocking 라이브러리를 찾았습니다.

MSW

먼저 MSW를 사용해보기 앞서 동작방식을 간단히 이해해보겠습니다.

MSW 라이브러리는 네트워크 요청을 가로채어 Mocking한 결과를 리턴해줍니다. 어떻게 이런 동작이 가능할까요?

그 이유는 Service Worker를 통해 HTTP 요청을 가로채기 때문입니다.

Service Worker

Service Worker는 웹 어플리케이션의 메인 스레드와 분리된 백그라운드 스레드에서 실행시킬 수 있는 기술 중 하나로 Service Worker 덕분에 UI Block 없이 연산을 처리 할 수 있습니다.

Service Worker를 사용하는 기능들 예시
1. 백그라운드 동기화 기능, 높은 비용의 계산을 처리할때, 푸시 이벤트를 생성
2. 네트워크 요청을 가로채는 행위

즉 MSW는 네트워크 요청을 가로채는 행위를 사용합니다.

다만, 사용이 제한되는 경우도 있는데요. 대부분의 모던 브라우저에서는 지원하고 있으나, IE와 같은 일부 브라우저는 지원하고 있지 않습니다. 또, HTTPS 보안 프로토콜 환경이 필요합니다. Service Worker의 기능 중 네트워크요청을 가로채는 강력한 기능을 갖고 있기 때문이죠.

MSW 사용 방법

CRA환경에서 설명하도록 하겠습니다.

폴더구조

├── public
│   ├── index.html
│   └── mockServiceWorker.js
├── src
│   ├── App.tsx
│   ├── index.tsx
│   └── mocks
│      ├── browser.js
│      └── handlers.js
└── package.json

1. install

npm install msw --save-dev
# or
yarn add msw --dev

2. 서비스 워커 코드 생성하기

npx msw init <PUBLIC_DIR> --save

<PBULIC_DIR> 를 해당 프로젝트의 public directory로 변경해주면 됩니다. 저의 경우엔 react이므로

npx msw init public/ --save

가 되겠네요.

3. 요청 핸들러 작성 및 서비스 워커 생성

mocks/browser.js, mocks/handlers.js 를 작성합니다.

// mocks/handlers.js
import { rest } from 'msw';

export const handlers = [
  rest.get('/todos', (req, res, ctx) => {
    // Check if the user is authenticated in this session
    const isAuthenticated = sessionStorage.getItem('token');
    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: 'jw',
      })
    );
  }),
];

// src/mocks/browser.js
import { setupWorker } from 'msw';
import { handlers } from './handlers';

// This configures a Service Worker with the given request handlers.
export const worker = setupWorker(...handlers);

4. 서비스 워커 삽입

// src/index.js
import React from 'react'
import ReactDOM from 'react-dom'
import App from './App'

if (process.env.NODE_ENV === 'development') {
  const { worker } = require('./mocks/browser')
  worker.start()
}

ReactDOM.render(<App />, document.getElementById('root'))

5. 서비스 워커 테스트

이제 애플리케이션을 구동 후에 브라우저 에서 콘솔을 열면 [MSW] Mocking enabled 가 보이며 활성화되었음을 알 수 있습니다.

저의 경우엔 token이 없는 경우의 todos를 호출하여 403에러가 정상적으로 표현되는 것을 확인할 수 있었습니다.

마무리

프로젝트를 진행함에 있어 협업이 필수인 것 처럼 API를 연결하는 것 또한 기본이라고 생각합니다.

다만 모든 상황이 이상적이지 않기에 여러 상황에 대응할 수 있는 방법을 갖추는 것이 중요한데요. API가 주어지지않은 이번 경우엔 mock 데이터를 MSW를 활용해 처리해보았습니다. 이를 통해 백엔드로부터 실제 API를 기다리지 않고 유연하게 개발을 진행하고 그로 인한 능률적인 코딩 과정을 기대해볼 수 있을 것 같습니다.