‘코어 자바스크립트’를 읽던 도중 Redux에서 미들웨어를 정의할 때 ‘Currying’을 사용하고 있다는 것을 발견했다.

const loggerMiddleware = storeAPI => next => action => {
  console.log('dispatching', action)
  let result = next(action)
  console.log('next state', storeAPI.getState())
  return result
}

Redux Fundamentals, Part 4: Store | Redux

오늘은 Redux에서 사용한 Currying’과, ‘Currying’의 핵심이라고 볼 수 있는 ‘Closure’에 대해서 살펴보고자 한다.

1. Currying function

‘Currying function’이란 여러 개의 인자를 받는 함수를 하나의 인자만 받는 함수로 나눠서 순차적으로 호출될 수 있게 체인 형태로 구성한 것을 말한다.

책에 있는 예시를 통해 살펴보자.

const curryingFunc = function (func) {
  return function (a) {
    return function (b) {
      return func(a, b);
    };
  };
};


const getMaxWith10 = curryingFunc(Math.max)(10);
console.log(getMaxWith10(8));     // 10
console.log(getMaxWith10(25));    // 25

• curryingFunc 에 Math.max 함수를 인자로 넘겨 내부 함수를 리턴
• 반환된 함수에 10을 인자로 넘겨 내부 함수를 리턴
• 마지막으로, 10과 비교할 인자를 넘겨 Math.max 함수에 넘겨받은 두개의 수를 인자로 하는 함수 호출값을 리턴

위와 같이 ‘Currying function’을 이용하여 함수를 대기 상태로 가지고 있다가, 마지막 인자가 전달되었을 때 (필요한 인자가 전부 주어졌을 때) 원본 함수가 실행되고 결과값을 받을 수 있다.

잠깐.. 다음으로 넘어가기 전에 위에 코드의 경우 함수를 계속 중첩시켜 가독성이 좋지않으므로 ES6의 화살표 함수를 통해 가독성을 높여보자.

const curryingFunc = func => a => b => func(a, b);

‘Currying function’를 이용하여 우리가 원하는 시점에 최종적으로 함수 실행을 할 수 있는 ‘lazy execution’을 구현할 수 있다.

그럼 이제 이러한 ‘Currying function’ 가능하도록 한 JS의 ‘Closure’에 대해 알아보자.

2. Lexical Scope

먼저, ‘Closure’의 개념을 알기전에 ‘Lexical Scope’ 관한 이해가 필요하다.

‘자바스크립트는 언어 특성상 함수가 정의되는 시점에 상위 스코프가 결정된다.’이 말의 의미를 예시를 통해 살펴보자

function init() {
    var name = "Mozilla";
    function displayName() {
        alert (name);
    }
    displayName();
}

init();

init이라는 외부함수가 존재함고 그 내부에 displayName의 이름을 가지는 내부함수를 '정의'하고 있다.

displayName 함수가 init이라는 함수 내부에서 정의되고 있으므로, init 함수를 상위스코프로 가진다.

이 부분에서 중요한 점은 실행되는 시점이 중요한게 아니라 함수가 정의되는 시점을 봐야하는 것이다.

조사하면서 이해에 도움이 되는 설명이 있었는데 ’자식 함수는 부모 함수를 어휘적으로 묶는 함수라고 부릅니다.’이 설명대로 displayName 자식함수가 init이라는 부모함수를 묶었고, 부모함수에 정의된 name이라는 변수에 접근할 수 있었던 것이다!

사실 ‘Lexical’이라는 단어가 항상 가슴 속 깊이 이해되지 않았다. 하지만 아래 문장을 통해 조금 더 가까워진 느낌이 들었다.

It’s called lexical(or static) because the engine determines (at lexing time) the nesting of scopes just by looking at the JavaScript source code, without executing it.

3. Closure

이제 Lexical Scope와도 친해졌으니 ‘Closure’에 대해 알아보자.

위에 예시를 다시 한번 더 살펴보자.

function init() {
    var name = "Mozilla";
    function displayName() {
        alert (name);
    }
    displayName();
}

init();

displayName 자식 함수가 형성한 ‘Lexical Scope’에 의해 name 이라는 변수에 접근할 수 있었던 건 이제 원래 알던 사실이 되었다.

그렇다면, 부모 함수의 바깥에서 내부함수를 실행한다면 어떻게 될까?

function makeFunc() {
  var name = "Mozilla";
  function displayName() {
    alert(name);
  }
  return displayName;
}

var myFunc = makeFunc();
myFunc();

makeFunc()를 실행하면서 내부함수를 리턴해주면서 외부함수는 실행이 완료되었다. (함수의 생명주기가 끝났다.)

그렇다면 외부함수에 정의된 ‘name’ 변수 생명이 다하여 사용할 수 없을 것이라고 생각하지만 우리가 배우고 있는 이 ‘Closure (myFunc)’ 아이 덕분에 외부함수를 통해 리턴받은 내부함수 (displayName)을 실행했을 때 ‘Mozilla’가 출력되는 것을 확인할 수 있다.

‘Closure’ 통해 ‘Lexical Scope’를 벗어나서도 (외부에서 실행되어도) 정의된 위치에서 변수를 기억하고 있다.

여기까지가 Closure의 기본적인 개념이다.

조금더 자세히 들어가자면, 자바스크립트는 C, C++ 언어와는 다르게 가비지 컬렉팅을 통해 우리가 신경쓰지 않아도 자동적으로 메모리 관리를 해주고 있다.

위의 예시에서 함수의 실행 컨텍스트가 끝났을 때 가비지 컬렉터에 의해 변수가 소멸되어야 하지만, ‘Closure’를 통해 가비지 컬렉터 수집 대상에서 제외된다.

한마디로 함수 내부의 정의된 변수가 가비지 컬렉터에게 “아직 나를 참조하고 있는 친구가 있어 그러니깐 아직 메모리 해제하지 말아줘” 라고 이야기 하는것이라고 생각하면 될 거 같다.

4. 결론

Redux에서는 함수형 프로그래밍을 지향하고 그 결과로 미들웨어를 정의할 때 ‘Currying’을 사용하고 있다.

Design Decisions | Redux

Redux의 logger 미들웨어를 통해 위에서 배운 ‘Closure’를 어떻게 활용하였는지 살펴보자

const loggerMiddleware = storeAPI => next => action => {
  console.log('dispatching', action)
  let result = next(action)
  console.log('next state', storeAPI.getState())
  return result
}

const middlewareEnhancer = applyMiddleware(loggerMiddleware)
const store = createStore(rootReducer, middlewareEnhancer)
const dispatchResult = store.dispatch({type: 'some/action'})
console.log(dispatchResult)

• store는 Redux를 사용할 때 처음 생성되고 이 때 인자로 전달된다
• next인자는 dispatch 의미를 가지는데 store와 비슷하게 생성된 이후로 바뀌지 않는 속성이다.
• 결국, action type에 따라 결과가 매번 달라진다.
• action을 인자로 받아 외부에서 실행되었을 때도 (store.dispatch({type: 'some/action'})) ‘Closure’를 통해 ‘Lexical Scope’에 캡쳐된 store, next에 접근하여 사용할 수 있는것이다.
• 이후에도 다양한 타입의 action만을 인자로 받아서 ‘Currying function’을 실행할 수 있다.

위에 과정을 살펴본대로 ‘Currying’은 ‘Closure’ 덕분에 가능한 것이다.

이렇게 Redux에서는 ‘Clousre’를 활용하는 ‘Currying’를 통해 우리가 원하는 시점에 함수를 실행하는 ‘lazy execution’을 가능하게 하였고, 함수형 프로그래밍의 정수를 보여 주었다.

5. 참고 자료

• A Simple Explanation of JavaScript Closures
• 7 Interview Questions on JavaScript Closures. Can You Answer Them?
• [JS/클로져] 자바스크립트의 Lexical scoping과 Closure (2)

클라이언트와 서버간의 데이터를 주고 받기 위해 비동기 HTTP 통신을 하게 된다. 대표적인 방식으로는 XMLHttpRequest, Fetch API, Axios가 존재한다. 오늘은 이 중에서 Axios와 조금 더 친해져보고 한다.

XMLHttpRequest, Fetch API, Axios에 기본적인 내용들을 아래에 글을 참고하면 좋을 거 같다.

[JS][AJAX] 📚 서버 요청 및 응답 (자바스크립트 fetch API)

[AXIOS] 📚 axios 설치 & 특징 & 문법 💯 정리

Axios API

1. Axios

Axios는 자바스크립트 내장 라이브러리인 ‘Fetch API’보다 조금 더 개발자 편의를 봐주는 다양한 기능을 제공하는 ‘서드파티 라이브러리’이다.

Axios의 주요 기능을 살펴보자

• 브라우저를 위해 XMLHttpRequests 생성
• node.js를 위해 http 요청 생성
• Promise API를 지원
• 요청 및 응답 인터셉트
• 요청 및 응답 데이터 변환
• 요청 취소
• JSON 데이터 자동 변환
• XSRF를 막기위한 클라이언트 사이드 지원

Fetch API와 Axios의 차이를 보여주는 간단한 예시를 살펴보자.

async function executeRequest() {
  const response = await fetch('/movies.json');
  const moviesJson = await response.json();
  console.log(moviesJson);
}
executeRequest(); 
// logs [{ name: 'Heat' }, { name: 'Alien' }]

Fetch API로 요청시 응답이 성공적이다면, 응답을 JSON으로 추출하는 코드를 직접 작성해야 한다.

Axios의 경우 조금 더 단순하게 처리할 수 있다.

async function executeRequest() {
  const moviesJson = await axios('/movies.json');
  console.log(moviesJson);
}
executeRequest(); 
// logs [{ name: 'Heat' }, { name: 'Alien' }]

axios의 응답은 실제 JSON 객체를 반환한다. ‘Fetch API’와는 다르게 JSON으로 추출하는 코드를 명시할 필요가 없어졌다.

또한 타임아웃 기능을 제공한다.

우리가 Exprees에서 작업할 때 특정 endpoint에 응답 관련 로직을 작성하지 않고, 해당 endpoint에 요청을 보내면 서버가 응답을 주기전까지 클라이언트가 무한정으로 대기하고 있는 현상을 볼 수 있을 것이다.

이러한 불필요한 지연을 없애기위해 axios에서는 특정 시간이 경과했을 때 요청을 취소할 수 있다.

const instance = axios.create({
  timeout: 30000,
});

위에 예시와 같이 Axios의 편리한 기능을 제공하는데, 이번 실습에서는 ‘JSON 데이터 자동 변환’, ‘요청 및 응답 인터셉트’ 기능을 활용하였다.

그 중 ‘요청 및 응답 인터셉트’ 기능에 대해 중점적으로 살펴보고자 한다.

2. 실습

Express 서버에 API 요청을 담당하는 axios 코드를 별도의 모듈로 분리하여 관리하였다.

import axios from "axios";

const API = axios.create({ baseURL: "<http://localhost:8000>" });

API.interceptors.request.use((req) => {
  if (localStorage.getItem("profile")) {
    req.headers.Authorization = `Bearer ${
      JSON.parse(localStorage.getItem("profile")).token
    }`;
  }

  return req;
});

API.interceptors.response.use(
  (res) => {
    return res;
  },
  (err) => {
    if (err.response.status === 401) window.location.href = "/login";

    return Promise.reject(err);
  }
);

export const login = (firebaseToken) =>
  API.post(
    "/login",
    {},
    {
      headers: {
        Authorization: firebaseToken,
      },
    }
  );

export const fetchDocs = () => API.get("/docs");
export const fetchDoc = (id) => API.get(`/docs/${id}`);
export const createDoc = (newDoc) => API.post("/docs", { ...newDoc });

• baseURL을 설정하여 모든 요청이 Express 서버를 향하게 해주었다.
• ‘axios’ 인스턴스를 생성

이 부분이 중요하다.

API.interceptors.request.use((req) => {
  if (localStorage.getItem("profile")) {
    req.headers.Authorization = `Bearer ${
      JSON.parse(localStorage.getItem("profile")).token
    }`;
  }

  return req;
});

• 사용자가 이미 서버에 Firebase Token을 이용하여 ‘Authentication(인증)’ 후 JWT 토큰을 발급 받았다면 클라이언트단 로컬스토리지에 해당 JWT 토큰이 보관되어 있다.
• 리액트에서 서버로 보내는 모든 HTTP request를 가로채어 로컬스토리지에 JWT 토큰이 존재한다면, HTTP header(Authorization)에 토큰을 심어준다.
• 서버에서는 리액트단에서 보낸 HTTP request header(Authorization)에 존재하는 JWT 토큰을 이용하여 ‘Authorization(인가)’ 절차를 밟는다.

Bearer

토큰 앞에 붙는 ‘Bearer’는 인증 타입에 관한 명시이다. OAuth를 위해서 고안된 방법이고, RFC 6750에 표준명세서가 존재한다. OAuth 토큰을 위해 고안된 인증 타입이지만, JWT를 위한 인증 타입이 명시적으로 정해지지 않아 JWT을 사용할 때 ‘Bearer’ 인증 타입을 자주 사용한다.

마찬가지로 HTTP response에도 인터셉터 기능을 적용할 수 있다.

만약, 인증되지 않은 사용자가 요청을 보내거나 JWT 토큰에 만료기한이 지났다면 서버에서 클라이언트단에서 보내는 요청을 거부할 수 있다. (401 Status Unauthorized) 이 경우 우리는 사용자가 다시 유효한 JWT 토큰을 발급 발을 수 있도록 로그인 페이지로 리다이렉트 시켜주어야 한다.

먼저 기존의 axios를 이용하여 위의 동작을 구현했을 때 아래와 같은 코드로 가능하다.

const fetchData = async () => {
  try {
    const { data } = await axios.get('protected/endpoint');
    return data;
  } catch (error) {
    console.log(error);
    window.location.href = '/';
  }
}

하지만, 많은 페이지과 존재하고 하나의 페이지에서 여러 요청을 보내야 한다면, 다수의 엔드포인트에 위의 코드를 작성해주어야 한다.

이런 번거로운 작업을 우리 대신 처리해주는 인터셉터를 이용해보자.

API.interceptors.response.use(
  (res) => {
    return res;
  },
  (err) => {
    if (err.response.status === 401) window.location.href = "/login";

    return Promise.reject(err);
  }
);

• 서버에서 해당 HTTP request가 ‘Authorization(인가)’이 실패했다면 401(Unauthorized)로 응답
• /login 페이지로 리다이렉트

또한 클라이언트단 비동기 로직 에러핸들링이 굉장히 중요하다고 생각한다.

서버에서의 에러핸들링도 중요하지만, 우리의 유저에게 보안에 관련된 내용을 빼고 유저가 에러를 인지하는데 필요한 정보만 전달하여 소통하는 것 또한 중요하다고 생각한다. 서버에서 응답한 에러 Status에 따라 클라이언트단에서 어떤 화면 또는 메시지를 유저에게 보여줄지를 결정할 수 있다.

그러한 원할한 소통을 위해서는 클라이언트단 에러핸들링 로직이 잘 관리되어야 하고, axios 인터셉터 기능이 우리에게 에러핸들링 로직이 한곳에 잘 관리될 수 있도록 도와준다.

이번 실습에서는 ‘401’에러에 대해서만 대응했지만, 확장하여 여려 에러에 대응할 수 있을 것이다.

위에서 ‘axios’ 라이브러리를 이용하여 정의한 ‘API 인스턴스’를 이용하여 비동기 요청을 담당하는 ‘redux thunk’에서 성공적으로 API를 호출할 수 있었다.

import * as api from "../api";

export const socialLogin = createAsyncThunk("auth/login", async (user) => {
  const { token } = await user.getIdTokenResult();
  const response = await api.login(token);

  return response.data;
});

export const getDocs = createAsyncThunk("docs/getDocs", async () => {
  const response = await api.fetchDocs();
  return response.data;
});

export const createDoc = createAsyncThunk("docs/addNewDoc", async (newDoc) => {
  const response = await api.createDoc(newDoc);
  return response.data;
});

• API관련 인증 헤더,에러핸들링은 API모듈에서 담당
• 요청을 실행하고 reducer에 응답을 전달하는 로직은 Thunk에서 담당

Axios에서 중요한 점은 HTTP request, response를 인스턴스를 이용하여 하나의 객체처럼 유기적으로 이용할 수 있다는 점이라고 생각한다.

3. 마치며

Fetch API와 Axios를 비교하고, Axios에서 제공하는 다양한 기능들 중에 ‘요청 및 응답 인터셉트’를 중점적으로 이용해보았다.

마무리에 한가지 중요한 사실이 있다.

결과적으로 Axios라는 친구가 Fetch API 보다 더 좋고, 만능처럼 보이지만 결코 그렇지 않다.

• JS 내장 라이브러리인 ‘Fetch API’ 와는 다르게 ‘Axios’는 앱 번들 크기를 늘린다.
• Axios는 서드파티 라이브러리이다.
• 이 말은 아직 해결되지 않은 버그들이 존재할 가능성이 높다는 것이다.

실제로 이전 회사에서 일하던 시절에 C++에서 공식 라이브러리 격인 서드파티 라이브러리 ‘boost’를 사용하면서 라이브러리 버그를 겪은 경험이 존재한다.

MongoDB Server와 Client 사이에 패킷을 분석하여 해당 패킷이 금지된 쿼리 포함하고 있는지 확인하는 기능을 구현할 때 금지된 쿼리(JSON)와 요청 쿼리(JSON) 비교 로직을 boost에서 제공하는 ‘JSON comparison’을 사용했다.

하지만 JSON으로 파싱하는 과정에서 실수인 값(double)에 관해서 부동소수점 오차가 발생하여 같은 값인데 다르다고 판별하는 버그가 발생했다. (18.400000000000002 != 18.399999999999999)

결국, boost 라이브러리를 참고하여 실수(double)를 비교하는 로직에 epsilon(오차 허용 범위)를 지정하여 부동소수점 오차를 보정하도록 커스텀 하였다.

결국 모든 라이브러리가 그러하듯 Axios도 우리를 위한 은총알은 아니다. 상황에 맞게 적절하게 사용해야 한다.

타임아웃, 인터셉터 등 Axios에서 제공하는 기능들을 활용하지 않을 경우 가벼운 Fetch API를 쓰는 것이 적절하고 여러 endpoint가 존재하고 복잡한 인증 인가 절차가 있다면 Axios를 사용하는 것이 적절하지 않을까 생각해본다.

Fetch API를 잘 활용하면 Axios에 주요 기능을 완벽하게 재현할 수 있다고 한다.

아래에 글을 보면, decorator 패턴을 이용하여 Fetch API에서 반복적으로 응답을 JSON으로 변환하지 않고 Axios와 같이 요청시에 JSON 추출하고, 타임아웃을 걸 수 있다는 점을 확인할 수 있다.

How to Greatly Enhance fetch() with the Decorator Pattern

참고자료

• Performing HTTP Requests: Fetch Vs Axios
• Performing HTTP Requests: Fetch Vs Axios
• Axios vs. fetch(): Which is best for making HTTP requests? - LogRocket Blog

개인적으로 어느 프로그램이든 로그를 남겨 보관하는 것은 귀찮지만, 굉장히 중요한 일이라고 생각한다.

로그를 이용하여 실제 서비스를 시작했을 때 이용자들의 행동을 분석하고 서버 트래픽을 분석할 수 있다.

멘토님께서 해주신 이야기인데, 실제로 이러한 로그를 이용하여 고객의 행동을 분석한 사례가 있다.

멘토님께서 “XXX”에서 일하실 때 어떤 고객이 결제를 하였지만 숙박예약이 되지 않았다고 항의 문의가 들어왔다.

CS(Customer Service)팀에서는 실제로 그 고객이 결제를 하였는지 확인하기 위해 개발팀에 ‘로그 분석’을 요청하였다.

또, 로그의 가장 중요한 역할은 서버에 에러가 발생했을 때 에러로그를 남기는 것이다.

로그 시스템이 없는 서버에서 장애가 발생하여 서버가 다운되었을 때, 어떤 이유로 서버가 다운되었는지 분석 하기 굉장히 어렵고 시간이 많이 소모된다. 그것을 분석하기 위해 로그를 남기는 코드를 추가하고, 다시 그 상황을 재현할 수 밖에 없을 것이다.

전에 회사에서 일하는 시절에 서버에 장애가 발생했을 때 로그에 소중함을 느꼈다.

프록시 서버를 담당하는 프로그램이였는데, 통신을 중계해주는 에이전트, 정책 및 개별 DB 프로토콜을 분석하는 에이전트가 분리되어 있어 각각의 에이전트 로그 파일이 따로 존재하였다.

QA(Quality Assurance)팀에서 보내준 장애가 발생했을 때 패킷들과 2개의 로그파일을 이용하여 방대한 코드에서 어떤 부분에서 에러가 발생했는지 수월하게 찾을 수 있었다.

패킷에 HTTP 메시지를 파싱하는 모듈에서 ‘Content-length’를 잘못 계산했고 이로인해 초기화 하지않은 메모리에 접근하는 문제였다.

만약, 로그파일이 존재하지 않아 방대한 코드의 어는 부분에서 에러가 발생했을지 예측하고, 예상되는 부분에 하나하나 콘솔을 찍어가면서 디버깅을 했다면 몇일동안 회사에서 보냈을 시간을 상상하면서 간담이 서늘해진다.

오늘은 이러한 로그시스템을 간단하게 express에서 구축할 수 있는 ‘winston’, ‘morgan’ 라이브러리를 살펴보고, 실제 ‘AWS Elastic Beanstalk’를 이용하여 배포한 서버에 적용시켜보려 한다.

1. Winston

윈스턴은 node에서 가장 인기있는 logging 라이브러리이다.

윈스턴의 주요 기능을 살펴보자

• 로그 파일 관리
• 로그 레벨 관리
• 로그 메시지 포멧 커스텀

우리가 express에서 주로 쓰는 reqest 요청 로깅 미들웨어인 ‘morgan’과는 다르게 ‘winston’은 로그메세지를 별도의 로그 파일에 저장할 수 있다.

먼저 ‘winston’ 라이브러리를 설치해주자.

npm i winston

그리고 winston 구성을 설정해 주어야 하는데 나의 경우에는 /src/loaders/logger.js경로에 해당 코드를 작성했다.

const winston = require("winston");

const levels = {
  error: 0,
  warn: 1,
  info: 2,
  http: 3,
  debug: 4,
};

const level = () => {
  const env = process.env.NODE_ENV || "development";
  const isDevelopment = env === "development";

  return isDevelopment ? "debug" : "warn";
};

const colors = {
  error: "red",
  warn: "yellow",
  info: "green",
  http: "magenta",
  debug: "white",
};

winston.addColors(colors);

const format = winston.format.combine(
  winston.format.timestamp({ format: "YYYY-MM-DD HH:mm:ss:ms" }),
  winston.format.colorize({ all: true }),
  winston.format.printf(
    (info) => `${info.timestamp} [ ${info.level} ]: ${info.message}`
  )
);

const transports = [
  new winston.transports.Console(),
  new winston.transports.File({
    filename: "/tmp/winston/error.log",
    level: "error",
  }),
  new winston.transports.File({ filename: "/tmp/winston/all.log" }),
];

const Logger = winston.createLogger({
  level: level(),
  levels,
  format,
  transports,
});

module.exports = Logger;

• 먼저 레벨을 설정했는데 서버 실행 환경(production, dev)에 따라 출력되는 로그의 레벨을 조정할 수 있다.
• 예를 들어 실제 서비스가 구동되는 ‘production’ 환경에서는 0,1 레벨(error, warn)에 해당하는 로그만 출력한다.
• 이는 필요한 로그에만 집중할 수 있게하여, 로그파일의 용량을 줄일 수 있다.
• 로그가 텍스트로 이루어져 있지만 사용자가 많의 서비스에 경우에는 트래픽이 많아 로그 파일의 크기가 순식간에 증가한다.

Logger.error("에러 메시지");

....

Logger.debug("디버깅 메세지");

• 로깅 레벨을 ‘warn’(1)로 설정했다면 위의 코드에서 error 로그는 남지만 debug 로그는 남지 않을 것이다.
• 더 자세한 로그가 필요할 때 (’dev’ 환경) 로깅 레벨을 올려 모든 로그를 확인할 수 있을 것이다.
• 그리고 각 로그 메시지별 색깔을 지정할 수 있다.

• 위에 코드에서 보는것과 같이 포맷 또한 커스텀이 가능하다.

이 부분이 중요하다.

const transports = [
  new winston.transports.Console(),
  new winston.transports.File({
    filename: "/tmp/winston/error.log",
    level: "error",
  }),
  new winston.transports.File({ filename: "/tmp/winston/all.log" }),
];

• 로그를 어떤 곳에 남길지 정의할 수 있다.
• 먼저, 콘솔에 모든 로그가 나오게 하고 에러로그는 특별하므로 별도의 ‘error.log’파일에 저장한다.
• 그 외에 로그들은 ‘all.log’파일에 저장한다.

이제 ‘winston’을 이용하여 필요한 곳에 로그를 남겨보자!

module.exports = async ({ expressApp }) => {
  await mongooseLoader();
  Logger.info(" ✅  MongoDB loaded and connected!");

  await expressLoader(expressApp);
  Logger.info(" 🟢  Express loaded");
};

exports.errorHandler = (err, req, res, next) => {
  res.locals.message = err.message;
  res.locals.error = req.app.get("env") === "development" ? err : {};

  Logger.error(
    `${err.status || 500} - ${err.message} - ${req.originalUrl} - ${
      req.method
    } - ${req.ip}`
  );

  res.status(err.status || 500);
  res.render("error");
};

‘winston’을 이용하여 서비스 상황에 맞게 로그를 기록하고 자신에게 필요한 정보를 포맷을 커스텀하여 저장할 수 있다.

2. Morgan

Morgan은 익숙할 것이라 예상한다.

‘Morgan’은 reqest 요청 로깅 미들웨어이다.

이 라이브러리를 ‘Winston’과 결합해보자.

미들웨어를 새로 정의해 주었다.

const morgan = require("morgan");
const Logger = require("../../loaders/logger");

const stream = {
  write: (message) => Logger.http(message),
};

const skip = () => {
  const env = process.env.NODE_ENV || "development";

  return env !== "development";
};

const morganMiddleware = morgan(
  ":method :url :status :res[content-length] - :response-time ms",
  { stream, skip }
);

module.exports = morganMiddleware;

• stream 을 보면 우리가 방금 생성한 ‘winston’ 로거에 해당 ‘morgan’ 로그를 http 레벨로 기록하는 것을 볼 수 있다.
• morgan도 요청 메시지 커스텀이 가능하다.

이제 라우터 상위에 ‘morganMiddleware’를 장착함으로써 모든 요청을 콘솔에 나오게 하고, 로그 파일에 저장할 수 있다.

module.exports = () => {
  const app = Router();

  app.use(morganMiddleware);
  app.use(checkLoginState);

  signup(app);
  login(app);
  main(app);
  votings(app);
  myVotings(app);

  return app;
};

3. 서버에 적용

‘AWS Elastic Beanstalk’를 이용하여 서버를 배포하였다.

‘AWS Elastic Beanstalk’에서 어는 정도 로그를 제공해주지만 내가 원하는 포맷이 아니고, 콘솔말고는 별도의 로그 파일을 분리해주지 않는다.

이제 우리가 만든 커스텀 로그 파일을 ‘AWS Elastic Beanstalk’에 로그를 요청해서 받아야한다.

그러기 위해서는 몇가지 작업이 필요하다.

‘AWS Elastic Beanstalk’는 EC2(Linux) 장비를 이용하여 우리의 코드를 웹 애플리케이션으로 배포해주는데, 우리가 만든 로그파일은 위에서 ‘winston’에서 지정한 경로 { filename: "/tmp/winston/all.log" } 로 EC2 서버에 저장될 것이다.

하지만, 로그 요청을 보냈을 때 우리 로그파일은 넘어오지 않을 것이다.

왜냐하면 EC2 장비에서 기본적으로 보내주는 로그 번들에 우리의 로그 파일 경로가 링크 되어있지 않기 때문이다.

리눅스 장비에 이 경로/opt/elasticbeanstalk/task에 우리 로그파일 경로를 링크 걸어주어야 한다.

만약 우리가 리눅스 장비를 직접적으로 운영하고 있다면 터미널에서 명령어를 이용하여 간단하게 해결할 수 있지만, AWS Elastic Beanstalk는 우리가 직접적으로 EC2(Linux) 장비를 건드리지 않고, 간편하게 웹 애플리케이션 배포하기 위한 취지로 만들어져서 EC2 설정을 직접적으로 건드리지 못한다.

그래서 EC2 설정을 바꿀 수 있는 커맨드를 간접적으로 실행시켜주어야 한다. 우리 코드 디렉토리 최상위에 ‘.ebextensions’ 폴더에 .config 파일에 커맨드를 작성하여 서버가 배포될 때 실행시킬 수 있다.

Viewing logs from Amazon EC2 instances in your Elastic Beanstalk environment

이제 링크를 걸어주는 명령어를 작성해보자.

files:
  "/opt/elasticbeanstalk/tasks/taillogs.d/cloud-init.conf" :
    mode: "000755"
    owner: root
    group: root
    content: |
      /tmp/winston/*
  
  "/opt/elasticbeanstalk/tasks/bundlelogs.d/applogs.conf" :
    mode: "000755"
    owner: root
    group: root
    content: |
      /tmp/winston/*

• taillogs 경로 설정파일에 링크를 걸어 ‘마지막100줄 요청’을 보냈을 때 우리의 로그가 포함되게 한다.
• bundlelogs 경로 설정파일에 링크를 걸어 ‘전체 로그 요청’을 보냈을 때 우리의 로그가 포함되게 한다.

이제 로그를 요청하여 우리의 로그를 성공적으로 받아오는지 확인해보자.

100줄 로그, 전체 로그에서 우리 로그 파일이 포함되어 있는것을 확인할 수 있다.

4. 마치며

node에서 제공해주는 고마운 로깅 라이브러리 ‘winston’, ‘morgan’를 이용하여 로그 시스템을 구축해보았다.

그리고 ‘AWS Elastic Beanstalk’ 배포한 서버에서 우리 로그 시스템을 적용할 수 있도록 해보았다.

이제 필요에 따라 로그 포맷을 확장하고, 필요한 정보를 우리 입맛에 맞게 저장할 수 있게되었다.

그리고 로그 시스템에서 또 중요한 고민사항이 있는데 바로 ‘Log Rotation’ 이다.

만약 실서비스 하는 서버에서 로그를 계속 쌓아두고 있다면 언젠가 서버의 용량이 가득 찰 것이다.

이는 서버 성능 저하를 유발하고, 나아가 서버가 다운될 수 있는 위험이 존재한다.

그래서 우리는 로그가 꽉 차지 않도록, 과거에 로그를 주기적으로 지워주어야 한다.

하지만, ‘AWS Elastic Beanstalk’ 우리를 위하여 Log Rotation을 해준다.

Log rotation settings on Linux

On Linux platforms, Elastic Beanstalk uses logrotate to rotate logs periodically. If configured, after a log is rotated locally, the log rotation task picks it up and uploads it to Amazon S3. Logs that are rotated locally don't appear in tail or bundle logs by default.

로그 시스템의 중요성은 우리가 운전할 때 블랙박스가 없다고 생각하면 와닿을거라 생각한다…!

참고자료

• How To Use Winston to Log Node.js Applications on Ubuntu 16.04 | DigitalOcean
• [node.js express] winston으로 node console log 관리하기. winston 사용 설정 자세한 설명!!
• Elastic Beanstalk에서 로그 파일 사용자 지정

평소에 이런 컨퍼런스를 영상으로만 봐서 현장 분위기가 어떨지 또 어떻게 진행되는지 굉장히 궁금했습니다. 그런데 이번에 운 좋게도 각국에서 펼쳐지는 JSConf라는 큰 행사에 참여할 수 있게 되었습니다! 작년에는 코로나 때문에 온라인으로 진행되었는데 이번에는 다행히도 오프라인으로 진행하였습니다.

자바스크립트를 좋아하고 관심이 많은 분이 모이기 때문에 그분들과 커뮤니케이션 할 수 있는 기회가 주어진다는 것에 굉장히 설레었습니다.

16일(금), 17일(토) 이틀에 걸쳐 진행하였고, 메인 발표가 진행되는 다목적 홀, 워크샵과 후원사 발표가 진행되는 2개의 세미나실로 구성되었습니다. 오프라인으로 진행되는 만큼 주최 측에서 스탬프 찍기, 배지 만들기 등 여러 이벤트를 준비하였는데 나중에 글에서 하나하나씩 소개해 드리겠습니다.

Opening 👋

참가자 등록하고 다목적 홀에서 오프닝 공연과 이번에 JSConf Korea 후원사를 소개하면서 시작했습니다.

메인홀 뒤쪽에는 후원사별로 부스가 있었고, 각 회사에 대한 소개와 채용 과정에 대해 들을 수 있었습니다. 그리고 JS 문법 관련 퀴즈를 풀고 경품을 받거나, 응모 뒤에 경품 추첨 등 세심하게 신경 쓴 부분들이 많았습니다.

그리고 드디어 본격적으로 발표가 시작되었습니다. 발표자와 발표 내용에 대한 간단한 소개를 아래에서 확인할 수 있습니다.

프로그램 | JSConf Korea 2022 🌈

발표 🖥

이번 JSConf 발표는 주제가 다채로웠고 모든 발표가 배울 점이 있었습니다. 그중 가장 기억에 남는 발표 3가지를 선정하여 간단하게 정리해 공유하고자 합니다.

React로 영수증 출력해보기: 자바스크립트로 POS를 만든다고? — 나석주

이번 컨퍼런스에서 가장 좋았던 세션입니다.

자바스크립트로 인쇄에 필요한 바이트 데이터를 다루고 JSX 문법을 활용하는 React를 통해 선언적으로 그리고 React스럽게 POS기 코드를 작성한 방법에 대한 세션입니다.

JS에서도 바이너리 데이터를 다루기 위한 Buffer를 만들 수 있지 않을까? 라는 생각은 평소에 있었지만 직접 구현해보지 못했습니다. 이 발표에서 JS TypedArray인 Uint8Array을 활용하여 POS기로 인쇄할 데이터, 인쇄 관련 명령어 들을 Buffer에 쌓을 방법에 대해 알게 되었습니다. 거기에 쌓인 Buffer를 JSX 문법과 React 컴포넌트를 활용하여 선언적으로 코드를 작성할 수 있도록 한 부분이 인상 깊게 다가왔습니다. 특히, JSX 코드를 재귀적으로 돌며 Uint8Array를 반환하는 render 함수를 커스텀 한 부분을 듣고 입을 다물지 못했습니다…

발표를 다 듣고 가장 먼저 든 생각은 개인 프로젝트에서 이런 아이디어를 생각해서 진행했으면 정말 좋았겠다고 느꼈습니다. React와 JSX 문법을 깊게 공부할 수 있고 render 함수, JS로 바이너리 데이터를 다루는 방법까지 여러 방면에서 교훈을 얻을 수 있는 프로젝트가 아니었을까 생각해보게 되었습니다.

이것을 확장하여 오프라인에 영수증이 출력되기 전에 웹 브라우저에서 사용자가 인생네컷과 같은 스티커 사진처럼 다양하게 커스텀 할 수 있는 기능을 제공해주면 좋겠다고도 생각해 보았습니다.

제가 작성한 발표에 대한 설명은 간략한 설명이었고, 디테일 한 설명과 코드를 보실 분들은 아래 링크를 통해 지식을 얻을 수 있습니다.

GitHub - seokju-na/react-thermal-printer: React for thermal printing

성공적으로 실패하는 방법 — 엘리노어 럼지

개발자로 지내면서 바보처럼 보일까 봐 질문을 꺼리고 내가 생각하거나 이전의 성과가 실패로 밝혀지는 것에 두려움을 느끼는 가면 증후군에 관한 세션입니다.

개발자로 일할 때 모르는 부분이 생겨 막히는 상황이 발생할 수 있고, 커뮤니케이션할 때 모르는 단어가 들릴 때가 종종 있었을 것입니다. 발표에서는 이러한 상황에서 “I don’t know”라고 말할 수 있는 용기가 중요하다고 이야기합니다. 또한 모르는 것을 인정하지 않고 도움을 요청하는 것에 두려움을 오래 느낄수록 가면 증후군에 걸릴 가능성이 커진다고 이야기합니다. 발표에서 특히 공감 가는 사례가 있었는데요 발표자분의 인턴 생활 때 API 응답을 캐싱 관련한 궁금증이 생겼지만, 혹시 본인이 틀렸을 가능성 때문에 쉽게 다른 사람에게 자신의 의견을 말할 수 없었다고 하였습니다. 하지만 용기를 내서 그 의견을 말했을 때 알고 보니 팀에 동료들이 놓치고 있는 부분이었다는 것입니다. 내 의견이 항상 옳은 게 아닌 것처럼 다른 사람의 의견이 항상 옳다고 가정하여 내 의견을 말하지 않는 것을 지양해야 한다고 느꼈습니다.

발표를 듣고 내가 모르는 것이나 실수를 밝히는 게 최악의 상황이 아니라 실수를 인정하지 않고 그대로 넘어가는 것이 최악의 상황이라고 생각하였습니다. 또한 실수를 인정했을 때 그것을 보완하여 성장할 기회가 생긴다는 말에 공감이 갔습니다.

이 발표가 기술적인 내용은 아니지만 기억에 남았던 이유는 최근에 제가 이런 가면 증후군에 걸린 것은 아닐까 고민해본 적이 있어서입니다. 😭 제가 모르는 것을 다른 사람들에게 밝히는 것이 두렵고 부끄러운 적이 많았습니다. 하지만 이 발표를 듣고 지금 제가 모르는 것을 인정하고 조사 후에 알려드린다고 말하는 것이 저와 우리 팀을 위한 효율적인 방향이라고 생각해보았습니다.

발표 PDF는 아래 링크를 통해 볼 수 있습니다.

GitHub - eleanorRumsey/jsConfKorea2022: Content from my presentation in Seoul on September 16, 2022

스타트업 개발팀에서 협업하기 — 홍석주

초기 스타트업 aaant팀의 PM팀, 개발팀 그리고 디자인팀의 협업 방식에 대한 고민을 엿볼 수 있는 세션입니다.

개발자로 일을 하시는 분들이시라면 애자일 방법론에 대해 들어본 적이 있으실 겁니다. 하지만, 항상 개념적으로만 들어왔고 실무에서는 어떤 방식으로 진행할까 라는 궁금증이 항상 존재했습니다. 이 발표에서 aaant팀이 스쿼드를 이루어서 기획부터 QA를 거쳐 프러덕트에 들어가기까지 과정인 스프린트 방식을 간단하게 소개해 주셨습니다. 소개해주신 여러 방식 중에 중요하다고 생각한 부분은 바로 스쿼드 또는 개발팀 내부에서 Sync를 맞추는 것이였습니다. 그러기 위해 스쿼드에서 이틀에 한 번 개발팀 내부에서는 데일리로 짧고 잦은 미팅을 지향한다고 하셨습니다. 팀 프로젝트를 진행하면서 구성원들끼리 데일리로 지금 하는 일, 블로킹 된 부분을 공유하면서 Sync를 맞추었던 경험이 있어 매우 공감 가는 방법이었습니다.

개발팀 협업 방식에서도 지금까지는 몰랐던 방법이 있었는데 Github Issue에 개발 전에 테스크에 대한 백그라운드나 설명에 관련된 글을 작성하여 팀원들과 공유하는 것입니다. 항상 Github Issue는 버그에 관련된 내용만 작성한다고 생각했는데 이렇게도 활용할 수 있다는 것이 신기하였습니다.

마지막으로 발표에서 기억에 남았던 내용은 개발팀에서의 개발 명세서를 보고 기능을 구현하는 것이 근본 역할이지만 프로덕트 자체에 관심을 가지고 개발해야한다는 점이었습니다.

발표를 듣고 느낀 점은 협업에 관한 방법론은 앞으로도 꾸준히 발전하겠다고 생각하는데 제가 속한 팀에서 저도 협업을 더 애자일하고 효율적으로 진행할 수 있도록 고민하고 또 고민해야겠다고 생각하였습니다.

제가 작성한 글에서는 간략하게 설명드렸는데 아래에 링크에서 더 자세히 aaant팀의 협업 방식을 확인할 수 있습니다.

Working in a Startup

그리고 불변적인 새로운 원시 타입을 소개하는 자바스크립트에 그들이 온다: 기대되는 다음 피쳐 Records 와 Tuples 발표가 있었는데 해당 발표에 관련된 내용은 더 조사하여 따로 글을 작성할 계획입니다 🖋

이벤트 🚥

이번 JSConf Korea 2022에서는 다양한 이벤트들이 즐비하였습니다.

🧐 PopupQuiz

발표 시작 전에 간단하게 발표자분을 알아갈 수 있는 시간이 있었는데요. 4개의 보기 중에 False인 보기를 고르는 문제였습니다. (처음에 True인 보기를 고르는 것으로 이해하여 당황했습니다 🙄)

문제를 맞힌 사람에게는 소정의 상품이 지급되었는데 운이 좋게도 한 문제를 맞혀 재미있어(?) 보이는 책을 받았습니다

🎖 배지 만들기

메인홀 뒤쪽 그리고 야외 부스에서 개발 관련 용어들이 적혀있는 종이를 잘라 배지를 만들 수 있었습니다.

기계에 종이와 코딩용지 그리고 클립을 넣고 펀치 하듯이 꾸욱 누르면 완성되는 배지였는데 생각보다 손기술을 요구하였습니다 🦾 잘못하면 코딩지가 떠버리는 현상이…

🎫 티겟 만들기

앞에서 소개해드린 React로 영수증 출력해보기 발표의 실제 제품을 체험할 수 있는 부스였습니다.

맥북에 영수증에 출력하고 싶은 이름과 내용을 적고 카메라에 환하게 웃고 사진을 찍으면 POS기에서 영수증이 나왔습니다!

짠! 📮

💎 경품 추첨

후원사 부스별로 경품 추첨을 진행하였는데 키보드, 에어팟 맥스 등 탐나는 경품들이 많았습니다.

카페에서 컨퍼런스에 참여한 분들과 커피챗을 하던 도중 1등에 당첨되었다는 전화를 받았습니다… 😆 1등 경품으로 레오폴드 키보드를 받았습니다! 감사합니다 잘 쓰겠습니다 🙏

마치며 🌇

생애 첫 번째 컨퍼런스로 JSConf를 갈 수 있게 되어 영광이었던 이틀이었습니다. 영어 울렁증이 있어 외국에서 온 개발자분들과 소통하지 못한 점과 제가 먼저 다른 분들에게 다가가 말을 건네지 못한 아쉬움이 있었지만, 개발자로서 관심을 가지고 조사해 볼 수 있는 주제를 알게 되었던 훌륭한 발표들과 개발의 진심인 사람들과 커뮤니케이션 할 수 있는 기회를 얻을 수 있었습니다. 다음에 참여하는 컨퍼런스에서는 더 적극적으로 소통할 수 있도록 노력하겠습니다 🙋‍♂️

그럼 이만 글을 줄이겠습니다.

다음 컨퍼런스는 10월 8일에 열리는 FEConf에 참여할 계획입니다.

FECONF 2022

JSConf Korea 2022 후기- 생애 첫 컨퍼런스 was originally published in aaant on Medium, where people are continuing the conversation by highlighting and responding to this story.

오늘은 지금까지 배웠던 지식들을 활용하여 Node(Express)와 React를 합쳐보았다.

그리고 리액트 코드에서 ‘fetch’ API를 이용하여 Express에 요청하고 Express에서 mongoDB에 저장된 데이터를 가지고 와 화면에 보여주는 과정을 구현해보았다.

최종적으로 두개의 환경을 합쳤을 때 실제로 배포가 되는것까지 확인하기 위해 Heroku를 통해 배포해 보았다.

1. 개발 환경

먼저 client 디렉토리에는 리액트를, server 디렉토리에는 node + express 환경을 설정해주었다.

그 후, client 에는 CRA(Create-react-app), server에는 express-generator를 이용하여 손쉽게 개발 환경을 구성하였다.

npm install -g create-react-app

create-react-app client

npm install -g express-generator

express server

그리고 client 폴더에 있는 리액트 코드를 빌드하여 빌드된 파일을 server 폴더에 위치시켜줄 것이다.

그 후 Express에서 ‘build’ 폴더를 정적 디렉토리로 지정하여 리액트 ‘index.html’을 사용할 것이다.

‘build’ 폴더 내부에 있든 JS파일을 이용하여 리액트가 우리의 화면을 그려줄 것이다.

즉, 리액트와 Express가 하나의 서버에 존재하는 것이다.

그럼 이제부터 생각하는 것을 이루어내기 위해 Server, Client 각각의 과정을 살펴보자.

2. Server (Express)

서버 쪽 코드는 이미 express-generator를 통하여 서버를 실행시키는데 필요한 기본적인 것들이 갖추여져 있다.

const createError = require("http-errors");
const express = require("express");

const app = express();

app.set("views", path.join(__dirname, "views"));
app.set("view engine", "jade");

app.use(express.json());
app.use(express.urlencoded({ extended: false }));
app.use(express.static(path.join(__dirname, "public")));
...

첫페이지는 서버에서 렌더링 된 html을 응답으로 주도록 하였다. (Sever Side Rendring)

app.get("/", (req, res) => {
  res.render("index");
});

그 후 ‘/react’ 경로에는 리액트 앱을 사용한다. (리액트를 사용하는 경로라는 걸 명시하기 위해 사용한 url)

아래의 코드를 통해 리액트에서 빌드된 코드를 사용할 수 있게된다.

app.use("/react", express.static(path.join(__dirname, "build")));

그 후 ‘/react’ 경로에 접근하였을 때 ‘index.html’파일을 응답해준다.

app.use("/react", reactRouter);

reactRouter.get("/", function (req, res, next) {
  res.sendFile(path.join(__dirname, "./build/index.html"));
});

• index.html을 보내주면 해당 파일에서 리액트 JS 파일을 요청한다.
• 그 후에는 우리가 알고있는 리액트처럼 JS파일을 이용해서 화면을 그린다.

그리고 서버 ‘/users’에 요청하면 MongoDB에 저장되어 있는 User 정보를 ‘JSON’으로 응답해주게 하였다.

app.use("/users", usersRouter);

usersRouter.get("/", async (req, res, next) => {
  try {
    const users = await User.find().lean();

    return res.json(users);
  } catch (error) {
    next(createError(500));
  }
});

2. Client (React)

클라이언트 쪽도 CRA 명령어를 통해 이미 기본적인것들이 갖추어진 상태이다.

여기에 ‘react-router-dom’을 이용하여 기본적인 리액트 앱을 구성해보자.

import { BrowserRouter } from "react-router-dom";

const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(
  <BrowserRouter basename="/react">
    <App />
  </BrowserRouter>
);

• 리액트 최상위 라우터의 기본 경로를 ‘/react’로 설정

import React from "react";
import { Link, Route, Routes } from "react-router-dom";
import Home from "./Home";
import Users from "./Users";

function App() {
  return (
    <div>
      <Link to="/">
        Home
      </Link>
      <Link to="/users">
        User
      </Link>
      <Routes>
        <Route path="/" element={<Home />}></Route>
        <Route path="/users" element={<Users />}></Route>
      </Routes>
    </div>
  );
}

export default App;

그리고 ‘Users’ 컴포넌트에서 서버에 요청하여 DB에 저장되어 있는 유저 정보를 보여준다.

import React, { useEffect, useState } from "react";

function Users() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    const getUsers = async () => {
      const response = await fetch("/users");

      if (!response.ok) {
        const message = `An error has occured: ${response.status}`;
        throw new Error(message);
      }

      const users = await response.json();

      return users;
    };

    getUsers().then((data) => setUsers((prev) => prev.concat(data)));
  }, []);

  return (
    <>
      <ul>
        {users.map((user) => (
          <li>{user.name}</li>
        ))}
      </ul>
    </>
  );
}

• fetch("/users") 를 통해 Express서버에 요청 (경로를 주목할 필요가 있다)
• 리액트 ‘users’ state 갱신
• 화면에 리스트로 출력

그리고 리액트 ‘package.json’에서 기본 홈페이지 경로를 ‘/react’로 설정해 주었다.

3. 합체

지금부터 리액트와 Express를 합치기 위해 리액트에서 ‘build’ 스크립트를 통해 빌드된 폴더를 ‘server’ 폴더로 옮길것이다.

그리고 ‘Heroku’배포를 위해 필요한 명령어들을 정의해 주어야 한다.

그러기 위해서는 client, server 전체를 아우르는 ‘package.json’이 필요하다.

{
  "name": "express-react-project",
  "version": "1.0.0",
  "description": "배포시 필요한 스크립트 정의",
  "scripts": {
		...
  },
  "author": "",
  "license": "ISC"
}

이제 이 ‘package.json’파일을 통해 우리가 해야하는 일을 정의해보자.

1. clinet 폴더로 이동
2. npm ci (clinet에서 필요한 node module를 설치하기 위해)
3. client (리액트) 빌드 (npm run build)
4. 빌드된 폴더를 ‘server/build’로 옮겨주기
5. server 폴더로 이동
6. npm ci (server에서 필요한 node module를 설치하기 위해)
7. npm run start (node ./bin/www)

위 과정을 명령어 스크립트로 정리해보자.

{
  "name": "express-react-project",
  "version": "1.0.0",
  "description": "배포시 필요한 스크립트 정의",
  "scripts": {
    "client-build": "cd client && npm ci && npm run build cd ../",
    "server-build": "cd server && npm ci && cd ../",
    "heroku-prebuild": "npm run client-build && npm run server-build && mv ./client/build ./server/build",
    "start": "cd server && npm run start"
  },
  "author": "June",
}

• heroku가 우리의 코드를 빌드할 때 ‘start’ 명령어를 실행하는데 이 때 60초가 초과되면 안된다.
• heroku-prebuild 명령어를 통해 ‘start’ 명령어를 실행하기전 필요한 환경을 세팅해준다.

그럼 이제 Heroku 명령어를 통해 배포를 진행해보자.

성공적으로 배포가 된것을 확인할 수 있다.

이것은 Express

서버에 데이터 흐름을 이해하기 쉽게 draw.io를 이용하여 그려보았다.

4. 마치며

하나의 서버에서 Express, react가 구동되는 템플릿을 만들어 보았다.

두 가지를 따로 두고 구현했다면 CORS 정책을 신경써야 했지만 같은 ‘Origin’이기 때문에 리액트에서 Express에 요청을 보내는 것이 간단해졌다.

CORS란 무엇일까?

그리고 웹에서 첫페이지는 화면을 사용자에게 빠르게 보여주고, SEO에 강점이 있는 ‘SSR’, 그리고 내부에서는 페이지 새로고침이 없어 사용자 경험을 개선할 수 있는 ‘CSR’을 도입해 보았다.

CSR vs SSR

그리고 만약 우리가 위에서 설정한 환경에서 클라이언트 리액트 코드를 개발할 때 리액트 ‘package.json’에 proxy 값을 Express 서버로 설정해 둔다면 문제없이 라이브 코딩이 가능할 것이다.

오늘 자료를 구성하면서 크게 느낀 부분은 JS언어 만으로도 풀스택 개발이 가능하다는 점이다.

다만, Express의 경우 유연하고 진입장벽이 낮은 장점은 있지만 서버 보안, 예외 처리 등을 위한 규칙이 존재하지 않는다고 느꼈다.

규칙이 없다는 것은 좋을 때도 있지만 서버와 같이 안전성을 위해 보수적으로 코드를 짜야하는 경우에는 규칙과 템플릿이 존재하는 것이 좋다고 생각한다. (Ex: Java Spring, Python django)

우리가 하고 있는 작은 프로젝트에서는 괜찮을 수도 있지만 실제 제품과 같은 큰 서버에서는 틀이 없다는 것은 단점으로 적용할 수도 있을 거 같다.

그래서 찾아보니 이미 NestJS 라는 대체제가 존재한다고 한다!

Documentation | NestJS - A progressive Node.js framework

앞으로의 개발에서 오늘 만든 Express + React 템플릿을 자주 사용할 수 있을 거 같다.

4.1 참고 자료

• [Node.js] Express를 backend로 하는 Create-react-app 시작하기
• Create React App with an Express Backend

1. SSR (Server Side Rendring)

서버로 부터 완전하게 만들어진 html파일을 받아와 페이지 전체를 렌더링 하는 방식이다.

1.1 과정

• 유저가 웹사이트에 요청을 보낸다.
• 서버는 필요하다면 데이터베이스에서 데이터를 가지고 오고, 페이지를 렌더링하는데 필요한 작업을 수행한 HTML 파일을 만든다.
• 유저는 이제 서버가 렌더링 해준 HTML을 이용하여 콘텐츠를 볼 수 있다. (Time to view)
• 하지만 아직 페이지에서 상호작용을 할 수 있는 JS파일이 존재하지 않기 때문에 페이지에서 클릭했을 때 반응이 일어나지 않는 부분이 존재한다.
• 브라우저에서 필요한 상호작용에 필요한 JS 파일을 서버로 부터 받는다.
• JS 파일을 브라우저에서 컴파일 후 인터랙티브한 페이지가 완성되었다. (Time To Interact)

1.2 장점

• HTML 컨텐츠가 이미 담겨져 있기에 SEO(Search Engine Optimizaion)에 좋다.
• 사용자에게 첫 콘텐츠를 빨리 보여줄 수 있는 장점이 존재한다.

1.3 단점

• 매번 페이지를 요청할 때마다 새로고침 되는 치명적인 단점이 존재한다.
• TTV(Time To View)와 TTI(Time To Interact)의 공백이 발생한다.
• 페이지를 구성하는 모든 리소스를 서버에서 처리하므로 요청이 많아질 때 서버 부담이 증가한다.

중요한 부분은 렌더링 주체가 ‘서버’ 라는 점이다.

2. CSR (Client Side rendring)

CSR은 페이지를 브라우저에서 서버로 부터 받은 JS 파일을 이용하여 직접 렌더링 하는 것을 의미한다.

2.1 과정

• 유저가 웹사이트에 요청을 보낸다.
• 브라우저는 링크를 이용하여 화면을 그리는데 필요한 HTML, JS 파일을 다운받는다.
• 브라우저는 JS 코드를 실행하여 리액트를 구동한다.
• 이 때 API를 통해 데이터베이스에 존재하는 데이터를 사용할 경우 API를 호출한다.
• 서버에서 데이터베이스에서 조회한 데이터를 응답한다.
• API로 부터 받은 데이터를 채워준 뒤 리액트가 VirtualDOM에 콘텐츠를 렌더링 한다.
• VirtualDOM이 구성이 완료되면 이를 브라우저 DOM 붙힌다.

2.2 장점

• 렌더링이 필요한 부분만 바꾸기 때문에 페이지 새로고침이 발생하지 않는다.
• 렌더링 주체가 브라우저 이므로 서버에 부하를 줄일 수 있다.

2.3 단점

• JS 파일을 번들링해서 한번에 받기 때문에 초기 유저가 콘텐츠를 보기까지의 속도가 느리다.
• 기본 HTML이 비어있어 SEO(Search Engine Optimizaion)에 최적화 되어 있지 않다.

중요한 부분은 렌더링 주체가 ‘브라우저’ 라는 점이다.

3. 실습

리액트로 구성된 CSR을 사용하는 프로젝트 페이지에서의 네트워크 탭을 통하여 파일을 어떻게 로드하고 있는지 살펴보자.

처음으로 HTML 파일을 로드 하는 부분이다.

<!DOCTYPE html>
<html lang="ko">
  <head>
    <meta charset="utf-8" />
    <link rel="shortcut icon" href="%PUBLIC_URL%/favicon.ico" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1, shrink-to-fit=no"
    />
    <meta name="theme-color" content="#000000" />
    <title>Chatting</title>
  </head>
  <body>
    <noscript> You need to enable JavaScript to run this app. </noscript>
    <div id="root"></div>
  </body>
</html>

• 실제 네트워크 탭에서 받은 응답이다.
• 위에서 보는것과 같이 HTML에 파일에 ‘root’태그를 제외한 페이지를 구성하는 어떠한 태그들이 존재하지 않는 것을 볼 수 있다.

그 후 리액트 관련 JS파일과 UI를 구현하고 상호작용에 필요한 JS파일을 다운받아 오는 것을 볼 수 있다.

mainJS 파일은 Minfy, Uglify 되어 알아볼 수 없는 코드로 구성되어 있는 것을 확인할 수 있다.

/*! For license information please see main.37b3cf38.js.LICENSE.txt */
function(){var e={892:function(e){e.exports=function(){"use strict";var e=1e3,t=6e4,n=36e5,r="millisecond",o="second",i="minute",a="hour",u="day",l="week",c="month",s="quarter",f="year",d="date",p="Invalid Date",h=/^(\\d{4})[-/]?(\\d{1,2})?[-/]?(\\d{0,2})[Tt\\s]*(\\d{1,2})?:?(\\d{1,2})?:?(\\d{1,2})?[.:]?(\\d+)?$/,v=/\\[([^\\]]+)]|Y{1,4}|M{1,4}|D{1,2}|d{1,4}|H{1,2}|h{1,2}|a|A|m{1,2}|s{1,2}|Z{1,2}|SSS/
...

JS 코드를 이용하여 페이지에 필요한 콘텐츠를 동적으로 구성한다.

그 후 탭을 눌러 페이지를 이동하여도 필요한 데이터가 없다면 더 이상 서버에 HTML 파일을 요청하지 않는 것을 확인하였다.

그럼 이제 node + Express로 구성된 SSR을 사용하는 프로젝트 페이지를 살펴보자.

<!DOCTYPE html>
<html>
  <head>
    <link rel="stylesheet" href="/codemirror/lib/codemirror.css">
    <link rel="stylesheet" href="/codemirror/theme/midnight.css">
    <script src="/codemirror/lib/codemirror.js"></script>
    <script src="/codemirror/mode/javascript/javascript.js"></script>
    <script src="/codemirror/addon/edit/matchbrackets.js"></script>
    <script src="/codemirror/addon/edit/closebrackets.js"></script>
    <script src="/codemirror/addon/hint/show-hint.js"></script>
    <script src="/codemirror/addon/hint/javascript-hint.js"></script>
    <script src="/codemirror/addon/selection/active-line.js""></script>

    <title>CodeWars</title>
  </head>
  <body>
    <h2>피보나치 수열</h2>
    <h4>정답자: 15명</h4>
    <h4>난이도: Level 1</h4>
    <div>설명: 피보나치 수는 F(0) = 0, F(1) = 1일 때, 1 이상의 n에 대하여 F(n) = F(n-1) + F(n-2) 가 적용되는 수 입니다.</div>

    <form action="/problems/627904cdd626d53e513898aa" method="post">
      <textarea id="code" name="code"></textarea>
      <button type="submit" class="submitButton">submit</button>
    </form>

    <script >
      CodeMirror.fromTextArea(document.getElementById("code"), {
        lint: true,
        lineNumbers: true,
        tabSize: 2,
        styleActiveLine: true,
        mode:  "text/javascript",
        matchBrackets: true,
        autofocus: true,
        autoCloseBrackets: true,
        theme: "midnight",
      }).setValue("function solution(arg) {\\n  // here!\\n}");
    </script>
  </body>
</html>

• CSR 방식과 다르게 이미 데이터베이스를 조회를 이용하여 구성한 정보를 포함하여 페이지 콘텐츠를 포함하고 있는 HTML 인것을 볼 수 있다.
• 이 경우 CSR 방식보다는 SEO에 장점을 가질 것이라는 예상을 할 수 있다. (페이지 콘텐츠가 많아 시맨틱 태그를 포함하고 있다면 더욱 그럴것이다.)

그 후 필요한 JS 파일을 다운받는다.

• 위에서 빨간줄을 이용해 표현한 구간이 SSR의 단점 TTV(Time to view), TTI (Time to Interact) 간극에 포함된다. (HTML 파싱하여 DOM 트리를 구성하는 시간까지 고려하면 더 정확한 시간을 구할 수 있다.)
• HTML을 서버쪽에서 렌더링하여 보내주어 빠르게 유저가 해당 페이지를 볼 수 있지만, 유저의 이벤트에 따른 상호작용에 필요한 JS 파일을 다운받고 실행시키는데 까지 잠깐의 시간이지만 공백이 발생한다.

그리고 마지막으로 CSR과 SSR의 로드한 파일의 크기를 비교해보자.

• 위에 CSR 방식의 JS 파일은 크기의 단의가 KB이고, 아래 SSR 방식은 Byte단위 크기이다.
• 정확한 비교를 위해서는 같은 페이지를 렌더링해야 하지만, 다른 페이지라고 하여도 한번에 불러오는 파일의 크기가 명확하게 차이가 나는 것을 볼 수 있다.
• 이는 CSR의 경우 한번에 요청으로 번들된 파일을 다운받아 오기 때문이다.
• 그리고 이것은 초기 진입속도가 SSR 비해 느려지는 이유중의 하나이다. (CSR의 단점)

4. 정리

CSR과 SSR의 기본 개념과 각각의 장단점을 살펴보았다.

조사하고 느낀점은 어떤 방식이 더 우월하다는 것이 없다라고 느꼈다.

페이지 이동이 많고 유저와 상호작용이 많은 넷플릭스의 경우 CSR을 적극적으로 활용하고, 페이지 이동이 적고 SEO를 최적하여 검색 결과 상위에 위치해야 하는 회사 홈페이지의 경우 SSR이 적절할 것이다.

서비스의 성격에 따라 적절한 방식을 채용하고, 또 필요에 따라서 두가지를 섞는 방법도 고려해야 할 것이다.

그리고 이번 주제를 조사하면서 CSR과 SSR를 적절하게 섞을 수 있는 리액트 프레임워크인 ‘NextJS’ 에도 눈길이 갔다.

Next.js by Vercel - The React Framework

다음 조사 주제로 좋은 재료인 거 같다.

4.1 참고 자료

• A Deep Dive into Server-Side Rendering (SSR) in JavaScript
• Rendering on the Web
• NAVER D2

Express를 이용하여 응답을 보낼 때 ‘response’ 객체에 여러 메서드들이 존재한다. 만약 ‘JSON’형식으로 응답을 한다면 send(), json() 두 개의 메서드가 가능하다.

app.get('/', function(req, res){
    res.json({ user: 'geek' });
});

app.get('/', function(req, res){
    res.send({ user: 'geek' });
});

오늘은 GitHub에 올려진 ‘Express’ 프레임워크 오픈소스 코드를 이용하여 두 가지 메서드가 내부에서 어떻게 동작하는지 알아보고자 한다.

express/response.js at master · expressjs/express

1. res.send()

먼저 소스에 보면 간략하게 파라미터에 대한 설명이 주석으로 되어 있다.

/**
 * Send a response.
 *
 * Examples:
 *
 *     res.send(Buffer.from('wahoo'));
 *     res.send({ some: 'json' });
 *     res.send('<p>some html</p>');
 *
 * @param {string|number|boolean|object|Buffer} body
 * @public
 */

• response를 보내는 메서드이다.
• 인자로 string, number 등 기본 데이터 타입을 넣을 수 있다.

아래부터 코드에 나오는 ‘this’는 res.send() Dot notation으로 호출하였으므로 ‘res’ 객체다.

그리고 코드를 보고 send에 대해서 새롭게 안 사실인데, 인자에 순서 상관없이 ‘stauts’를 넣을 수 있다.

// allow status / body
  if (arguments.length === 2) {
    // res.send(body, status) backwards compat
    if (typeof arguments[0] !== 'number' && typeof arguments[1] === 'number') {
      deprecate('res.send(body, status): Use res.status(status).send(body) instead');
      this.statusCode = arguments[1];
    } else {
      deprecate('res.send(status, body): Use      res.status(status).send(body) instead');
      this.statusCode = arguments[0];
      chunk = arguments[1];
    }
  }

• 첫번째 인자가 ‘number’ 타입이면 그것을 ‘statusCode’로 이용한다.
• 두번째 인자가 ‘number’ 타입이면 그것을 ‘statusCode’로 이용한다.
• 인자 순서도 상관없이 알아서해주는 너무나도 친철한 Express이다.

이제 중요한 body의 타입 관련 로직이 나온다.

switch (typeof chunk) {
    // string defaulting to html
    case 'string':
      if (!this.get('Content-Type')) {
        this.type('html');
      }
      break;
    case 'boolean':
    case 'number':
    case 'object':
      if (chunk === null) {
        chunk = '';
      } else if (Buffer.isBuffer(chunk)) {
        if (!this.get('Content-Type')) {
          this.type('bin');
        }
      } else {
        return this.json(chunk);
      }
      break;
  }

• 여기서 chunk는 우리가 인자로 넘겨준 body({ user: ‘geek’ })이다.
• 타입이 string일 때 우리가 send()를 호출 전 직접적으로 Content-Type 명시하지 않았다면 ‘html’타입으로 설정된다.
• object일 경우가 중요한데 우리가 body에 json을 넘기게 되면 위에 코드에 나와 있듯이 json()을 호출하는 것을 볼 수 있다.

그럼 우리가 res.send({ user: 'geek' })를 호출하면 send 메서드 내부에서 type을 확인하고 ‘object’이니 res.json({ user: 'geek' })을 호출한다.

이제 마지막 부분이다.

if (req.method === 'HEAD') {
    // skip body for HEAD
    this.end();
  } else {
    // respond
    this.end(chunk, encoding);
  }

• end 메서드를 통해 최종적으로 응답을 보내는 걸 확인할 수 있다.

2. res.json()

send메서드와 마찬가지로 간략하게 파라미터에 대한 설명이 주석으로 되어 있다.

/**
 * Send JSON response.
 *
 * Examples:
 *
 *     res.json(null);
 *     res.json({ user: 'tj' });
 *
 * @param {string|number|boolean|object} obj
 * @public
 */

• JSON response를 보내는 메서드이다.
• 인자로 string, number 등 기본 데이터 타입을 넣을 수 있다.

아래부터 코드에 나오는 ‘this’는 res.json() Dot notation으로 호출하였으므로 ‘res’ 객체다.

send와 마찬가지로 json메서드에서도 인자에 순서 상관없이 ‘stauts’를 넣을 수 있다.

// allow status / body
  if (arguments.length === 2) {
    // res.json(body, status) backwards compat
    if (typeof arguments[1] === 'number') {
      deprecate('res.json(obj, status): Use res.status(status).json(obj) instead');
      this.statusCode = arguments[1];
    } else {
      deprecate('res.json(status, obj): Use res.status(status).json(obj) instead');
      this.statusCode = arguments[0];
      val = arguments[1];
    }
  }

그리고 인자로 넣어준 데이터를 JSON 문자열로 변환하여 body에 담게된다.

var body = stringify(val, replacer, spaces, escape)

이 부분이 중요하다.

// content-type
  if (!this.get('Content-Type')) {
    this.set('Content-Type', 'application/json');
  }

return this.send(body);

• 여기서 Content-Type 헤더가 세팅되지 않았을 경우 Content-Type을 application/json 을 세팅한다.
• 그리고 마지막으로 res.send(body)를 호출한다.

하지만 이 때 body는 stringify 메서드를 통해 반환된 ‘string’ 타입이다.

3. 실행 흐름

두개의 메서드가 연결되어 있는 것을 보았다.

그럼 이제 res.json({ user: 'geek' }), res.send({ user: 'geek' } 를 호출했을 때 각각의 실행흐름을 살펴보자.

3.1 res.send({ user: 'geek' })

1. res.send(object)
2. object type 이니 분기로직에 의해 res.json() 호출
3. res.json(object)
4. object를 stringify메서드로 string으로 변경
5. Content-Type을 application/json으로 명시
6. res.send(string)
7. res.end(string) 호출하여 최종적으로 응답

3.2 res.json({ user: 'geek' })

1. res.json(object)
2. object를 stringify메서드로 string으로 변경
3. Content-Type을 application/json으로 명시
4. res.send(string)
5. res.end(string) 호출하여 최종적으로 응답

4. 정리

각각의 메서드를 직접 오프소스를 확인하여 어떻게 동작하는지 살펴보았다.

실행 흐름을 보아서 알겠지만, send()는 범용적으로 다양한 데이터 type에 대응하는 것을 볼 수 있고, json()은 JSON 데이터 type에 특화되어 있는 걸 볼 수 있다.

또 두 개의 메서드는 유기적으로 연결되어 있다.

만약 내가 응답으로 보내고 싶은 데이터가 ‘JSON’이 확실하다면 불필요하게 함수를 한번 더 호출하는 send() 보다는 json()이 적절할 거 같다!

VAC (View Asset Component)는 렌더링에 필요한 JSX와 스타일을 관리하는 컴포넌트를 의미한다.

VAC 패턴은 View 컴포넌트에서 JSX 영역을 Props Object로 추상화하고, JSX를 VAC로 분리해서 개발하는 설계 방법이다.

이런 설계는 비즈니스 로직 뿐만 아니라 UI 기능 같은 View 로직에서도 렌더링 관심사를 분리하는데 목적이 있다.

VAC Container을 JSX, Style을 제외한 비지니스 로직, 상태관리 등을 맡고 VAC에서는 JSX, Style을 관리하여 렌더링을 담당한다.

결국, VAC 패턴은 기존의 컴포넌트에서 JSX 영역을 별도로 분리하여 협업시 충돌을 최소화하고, 컴포넌트의 역할을 확실하게 분리하는 것을 목적으로 한다.

2. 적용

이번 개인 프로젝트에서 VAC 패턴이 필요로 하는 부분에 적재적소에 적용시켰다.

VAC Container

function Search() {
  const { hideModal } = useModal();
  const [filter, setFilter] = useState("");
  const [debouncedFilter] = useDebounce(filter, 500);
  const { data } = useQuery(
    ["getPhotos", debouncedFilter],
    () => getPhotos(debouncedFilter),
    {
      enabled: Boolean(debouncedFilter),
      refetchOnWindowFocus: false,
    },
  );

  const SearchProps = {
    photos: data,
    onInputChange: e => setFilter(e.target.value),
    onPhotoClick: () => hideModal(),
  };

  return <SearchView {...SearchProps} />;
}

• Fetching, CustomHook, state 등 비지니스 로직 상태 관련 코드 담당
• ‘Props Object’ 를 통해 VAC 컴포넌트에 전달
• JSX 로직이 분리되어 있어 비즈니스 로직에 집중할 수 있었고 ‘VAC Debugger’을 통해 테스트를 진행

VAC

function SearchView({ photos, onInputChange, onPhotoClick }) {
  return (
    <SearchBarWrapper>
      <SearchBar
        type="text"
        placeholder="Search using tags related to photos."
        onChange={onInputChange}
      />
      <SearchIcon />
    </SearchBarWrapper>
    <PhotosWrapper>
      {photos?.map(photo => (
        <Link key={photo._id} to={`/${photo._id}`} onClick={onPhotoClick}>
          <PhotoEntry {...photo} />
        </Link>
      ))}
    </PhotosWrapper>
  );
}

SearchView.propTypes = {
  photos: PropTypes.array.isRequired,
  onInputChange: PropTypes.func.isRequired,
  onPhotoClick: PropTypes.func.isRequired,
};

const SearchBarWrapper = styled.div`
  display: flex;
  margin-top: 2rem;
  border: 0.3rem solid #265d6e;
  border-radius: 40px;
  justify-content: space-around;
  align-items: center;
  padding: 0.3rem 2rem;
`;

...

• JSX 로직과 , Style 관련 코드를 담당
• ‘Container’에서 넘겨준 ‘Props Object’를 통해 이벤트 바인딩
• ‘propTypes’을 통해 타입 검사

3. 소감

결과적으로 이 패턴은 이번 프로젝트 나아가 나에게 잘 맞는 패턴이였다.

JSX 코드를 담당하는 컴포넌트, 비지니스 로직, State를 관리하는 컴포넌트가 구분이 되어 관심사 분리가 확실하게 되는 것을 느꼈다.

또한, 이번 프로젝트는 나혼자 진행하였지만 협업시에는 아직 View (JSX) Component가 없어도 VAC 개발툴을 이용하여 비지니스 로직을 작성할 수 있는 점이 더 큰 장점으로 다가올 거라 생각한다.

리액트는 웹 개발 특성상 ‘Agile’하게 개발을 진행하여야 된다고 생각한다. 그러한 생각으로 먼저 코드를 작성한 후 분리, 모듈화가 필요하다고 생각되면 그 상황에 최선의 구조를 적용하는 리팩토링 과정을 선호한다.

VAC 패턴은 다른 패턴(Presentational, 아토믹 디자인)과는 다르게 제약이 많지 않고, 설계에 과도하게 오랜시간을 가지지 않도록하여 내게 좋은 개발 경험을 안겨주었다.

4. 참고자료

• React에서 View의 렌더링 관심사 분리를 위한 VAC 패턴 소개 | WIT블로그
• React VAC Pattern - View 로직과 JSX의 의존성을 최소화 하자!
• [리액트] VAC 패턴 적용 후기 및 장단점

SOLID는 로버트 마틴이 주장한 유지보수가 쉽고 확장이 용이한 코드를 만들 때 적용하면 좋은 객제 지향 프로그래밍 원칙이다.

주로 객체 지향 언어(C++, Java)에 많이 사용되지만 언어에 상관없이 적용할 수 있는 훌륭한 개발 방법론이고, 객체 지향 설계의 정수라고 할 수 있다.

• SRP(Single Responsibility Principle): 단일 책임 원칙
• OCP(Open Closed Priciple): 개방 폐쇄 원칙
• LSP(Listov Substitution Priciple): 리스코프 치환 원칙
• ISP(Interface Segregation Principle): 인터페이스 분리 원칙
• DIP(Dependency Inversion Principle): 의존 역전 원칙

원칙들에 대해서 이해를 돕기 위해 아래의 글을 읽는 것을 추천한다.

객체 지향 설계 5원칙 — SOLID

JS에서는 인터페이스 개념이 존재하지 않고, 리액트에서는 함수형 프로그래밍을 강조하여 조금의 어색한 부분이 있을 수 있지만 이번 프로젝트에서 리액트에 SOLID원칙을 적용시켜 보았다.

1. 단일 책임 원칙(Single responsibility principle)

올바른 객체지향 설계를 위한 원칙 중 하나인 단일 책임 원칙은 모든 클래스는 하나의 책임만 가져야 한다라고 강조한다.

‘책임’ 기준의 상당히 모호하고 사람마다 다르게 생각될 수 있다. SOLID 원칙 창시자의 말을 빌리면

같이 수정해야될 것들은 묶고 따로 수정해야될 것들은 분리하는 것

이러한 클래스의 단일 책임 기준을 리액트에서 ‘컴포넌트’에 적용시킬 수 있다. 즉, 컴포넌트는 한 가지 일을 하는게 이상적이라는 원칙을 가지고 설계를 진행할 수 있다.

이번 프로젝트에서 단일 책임 원칙 테크닉을 이용하여 컴포넌트 계층 구조를 나누어 보았다.

이번 개인 프로젝트에서 단일 책임 원칙을 강조하는 리액트에서 추천하는 설계 가이드 ‘React로 사고하기’ 과정을 따라 페이지 및 컴포넌트를 설계하였다.

React로 사고하기 - React

메인 페이지 목업

1단계: UI를 컴포넌트 계층 구조로 나누기

• MainPage: 전체페이지
• PhtotView: 사진을 보여준다.
• Header: 페이지 헤더 ( 사진 작성자, 나라, 도시 정보를 보여준다.)
• AsideButtons: 해당 관심사의 맞는 모달을 띄우는 버튼들의 집합
• BottomButtons: 페이지 아래에 배치되어 있는 버튼들의 집합

하나의 컴포넌트가 커지게 되었을 때 컴포넌트들의 집합으로 묶고 하나의 일을 담당하는 하위 컴포넌트를 배치하였다.

위의 설계 구조에 따라 실제 개발 시 ‘MainPage’ 컴포넌트 배치이다.

<PhotoWrapper>
    <PhotoView />
    <MainPageHeader />
    <AsideButtons />
    <BottomButtons />
</PhotoWrapper>

그리고, ‘AsideButtons’ 컴포넌트들의 집합을 하나의 동작을 담당하는 하위 컴포넌트로 분리하였다.

<Wrapper>
    <ProfileIcon />
    <UploadIcon />
    <BookmarkIcon />
    <SearchIcon />
</Wrapper>

마찬가지로, ‘BottomButtons’ 컴포넌트들의 집합을 하나의 동작을 담당하는 하위 컴포넌트로 분리하였다.

그 후 ‘React로 사고하기’ 가이드에 따라 State를 배치(Recoil을 이용하여 전역으로 관리) 하고, 역방향 데이터 흐름을 추가하였다.

리액트를 초기에 학습할 때 부터 ‘React로 사고하기’ 절차를 밝고 개발을 진행하였다.

이 절차에서 컴포넌트 게층 구조를 나눌 때 기준을 ‘단일 책임 원칙’으로 잡았을 때 유지보수에 확실한 장점을 보인다는 것을 느꼈다.

개발을 하는 도중 어떤 기능에 문제가 생긴다면 그 기능을 담당하고 있는 컴포넌트에만 관심을 가지고 수정하면 되기 때문에 커플링을 줄이고, 효율적으로 개발할 수 있었다.

예를 들어 위에 예시에서 제가 개발한 서비스에서 사진을 보여주는 기능에 문제가 생겼을 때 저는 주저하지 않고 ‘PhotoView’ 컴포넌트 코드를 확인하고 이 컴포넌트를 수정할 것이다.

또 하나, 단일 책임 원칙을 잘 나타내는 단어가 있다. 바로 ‘모듈화’ 이다. 컴포넌트에 존재하는 큰 덩어리 코드들을 각자에 역할에 따라 분리하는 것이다.

이번 프로젝트에서 GraphQL을 이용하였다. REST API를 사용하였을 때 ‘Axios’ 객체를 이용하여 모듈화를 하였듯이 ‘graphql-request’ 객체를 이용하여 모듈화를 진행하였다.

import { GraphQLClient } from "graphql-request";

const endpoint = process.env.REACT_APP_API_SERVER_URL;
const API = new GraphQLClient(endpoint);

export const getRandomPhotoAndBookmarks = async (exceptionId, userId) => {
  const { randomPhoto: photo, user } = await API.request(
    GET_RANDOM_PHOTO_WITH_BOOKMARKS,
    {
      photoId: exceptionId,
      userId,
    },
  );

  return { photo, user };
};

export const getUserBookmarks = async userId => {
  const { user } = await API.request(
    GET_USER_BOOKMARKS,
    {
      userId,
    },
    {
      authorization: `Bearer ${
        JSON.parse(localStorage.getItem("loginData")).accessToken
      }`,
    },
  );

  return user;
};

...

위와 같이 API 통신을 담당하는 모듈을 만들었다.

북마크 컴포넌트에서는 위의 API 모듈과 ‘React Query’를 이용하여 특정 유저의 북마크 리스트를 보여줄 수 있었다.

function Bookmarks() {
  const userData = useRecoilValue(loginState);
  const { data } = useQuery(
    ["getBookmarks", userData._id],
    () => getUserBookmarks(userData._id),
    {
      refetchOnWindowFocus: false,
    },
  );

  return (
    <>
      {data.bookmarks.map(bookmark => (
        <PhotoEntry key={bookmark._id} {...bookmark} />
      ))}
    </>
  );
}

컴포넌트에서는 ‘엔드포인트 설정‘, ‘authorization 설정’ 등 API 관련 추가 조작 없이 데이터를 페칭한 다음 렌더링하고만 있다. 이것은 API 로직, 렌더링 로직을 책임을 분리하였기 때문에 가능한 일이다. 그 결과 코드가 직관적여지고 보다 쉽게 유지 관리할 수 있게 되었다.

(조금 더 개선할 수 있는 여지는 ‘React Query’ 관련 로직도 커스텀 훅으로 분리하여 캡슐화 할 수 있다.)

결과적으로, ‘단일 책임 원칙’은 좋은 설계의 이점을 여과없이 보여주는 테크닉이였다.

2. 개방-폐쇄 원칙 (Open-closed principle, OCP)

개방-폐쇄 원칙은 소프트웨어 구성요소(컴포넌트,클래스,모듈,함수)는 확장을 위해 열려야 하지만 수정을 위해 닫혀 있어야 한다 라고 강조한다.

프로젝트에서 컴포넌트 내부의 코드를 변경하지 않고 확장할 수 있는 방식으로 구조화 시켜보았다.

사실 이 원칙은 ‘컴포넌트의 재사용성’을 생각하면 쉽게 이해할 수 있을 것이다.

거창하게 적용시키지 않고, 우리가 자주쓰는 모달에 이 원칙을 적용시켜 보았다.

먼저, 원칙을 적용시키지 않고 모달을 설계해보자.

export default function Modal({ title, type}) {
  const { hideModal } = useModal();

  return ReactDom.createPortal(
    <ModalOverlay onClick={hideModal}>
      <ModalContainer onClick={e => e.stopPropagation()}>
        <ModalTitle>{title}</ModalTitle>
        {type === "LoginModal" && <LoginView />}
        {type === "UploadModal" && <UploadView />}
				...
      </ModalContainer>
    </ModalOverlay>,
    document.getElementById("portal"),
  );
}

위에 구조에서 아래와 같은 단점이 존재한다.

• 새로운 모달 타입이 생길 때 마다 Modal 컴포넌트로 돌아가서 조건부 렌더링 로직을 수정해야 한다.
• 확정성이 고려되지 않았고, 개방-폐쇄 원칙에 위배된다.

이 문제를 해결하기 위해 컴포넌트 합성을 사용할 수 있다. children prop를 사용해서 Modal을 사용할 컴포넌트에게 이 책임을 위임할 수 있다. 그렇다면 더 이상 Modal 컴포넌트는 다른 타입의 모달이 생겨도 수정에는 닫힌 구조를 가질 수 있다.

export default function Modal({ children, title }) {
  const { hideModal } = useModal();

  return ReactDom.createPortal(
    <ModalOverlay onClick={hideModal}>
      <ModalContainer onClick={e => e.stopPropagation()}>
        <ModalTitle>{title}</ModalTitle>
          {children}
      </ModalContainer>
    </ModalOverlay>,
    document.getElementById("portal"),
  );
}

위에 구조에서 Recoil을 이용하여 전역적으로 모달창을 띄우는 상태와 타입을 함께 관리하는 GlobalModal을 통해 확장하였다.

function GlobalModal() {
  const { modalType, modalProps } = useRecoilValue(modalState) || {};

  if (modalType === "LoginModal") {
    return (
      <Modal {...modalProps}>
        <Login />
      </Modal>
    );
  }

  if (modalType === "UploadModal") {
    return (
      <Modal {...modalProps}>
        <Upload />
      </Modal>
    );
  }

	...
}

이제 Modal 컴포넌트 자체를 수정하지 않고도 합성을 사용하여 확장에는 열려있는 구조가 완성되었다.

리액트에서 이 원칙을 잘 활용하면 컴포넌트의 확장성과 재사용성을 높일 수 있는 기회가 될 수 있을것이라 생각한다.

3. 리스코프 치환 원칙 (Liskov substitution principle)

이 원칙은 자식 클래스는 부모 클래스에서 가능한 행위를 수행해야한다는 원칙이다. 쉽게 말해 하위 타입 객체가 상위 타입 객체를 대체할 수 있다는 뜻이다.

함수형 컴포넌트 구조로 가고있는 리액트에서는 거의 적용할 수 없는 규칙이다 게다가, 공식문서에서 이 원칙에서 불가피한 ‘상속’ 대신 위에서 사용한 ‘합성’을 강력하게 추천하고 있다.

Composition vs Inheritance - React

(’아티클 지니’를 통해 공유하고자 하는 문단을 하이라이트 하였습니다.)

4. 인터페이스 분리 원칙 (Interface segregation principle)

인터페이스 분리 원칙은 하나의 클래스는 자신이 이용하지 않는 인터페이스는 의존하지 말아야 한다는 원칙이다. 이것을 리액트에서는 컴포넌트에 사용하지 않는 props에 의존하지 말아야 한다로 해석할 수 있다.

사실 이 원칙을 리액트에서 잘 적용하기 위해서는 타입스크립트를 사용하여야 된다고 생각한다. 그럼에도 불구하고 이번 프로젝트에서 불필요한 props를 넘겨주지 않는다라는 것에 집중하겨 적용시켜 보았다.

먼저 원칙을 적용시키기 전에는 ‘photo’ 객체를 자식 컴포넌트에 모두 전달하여 특정 프러퍼티를 사용하였다.

function MainPage() {
	const userData = useRecoilValue(loginState);
	const { data, refetch } = useQuery(
	    ["randomPhoto", userData?._id],
	    () => getRandomPhotoAndBookmarks(currentPhotoId,        
                                             userData?._id),
	    {
	      refetchOnWindowFocus: false,
	    },
	  );
	
	return (
        <PhotoWrapper>
	    <PhotoView photo={data.photo}/>
	    <MainPageHeader />
	    <AsideButtons />
	    <BottomButtons />
	</PhotoWrapper>
);
}

function PhotoView({ photo }) {
	return <img src={photo.imageUrl} />;

PhotoView.propTypes = {
  photo: PropTypes.shape({
		imageUrl: PropTypes.string,
	  country: PropTypes.string,
	  city: PropTypes.string,
	  tags: PropTypes.array,
  })
};

이 경우, 사용하지 않는 props에 의존하고 있어 재사용성이 낮아지는 결과를 초래할 수 있다.

예를 들어 이번에 오버패칭을 방지하는 GraphQL을 이용하여 내가 필요로 하는 데이터만 들고와여 정제하지 않고도, 바로 사용할 수 있도록 하였다. 그렇기 때문에 ‘photo’ 데이터가 각 컴포넌트에서 ‘tags’ 프러퍼티가 없는 등 다른 형태의 객체일 수 있다. 이 때 propTypes 검사를 통해 리액트에서 ‘Warning’을 뱉을 것이다. (타입스크립트의 경우 에러이다.)

그럼 이 문제를 해결해보자.

function MainPage() {
	const userData = useRecoilValue(loginState);
	const { data, refetch } = useQuery(
	    ["randomPhoto", userData?._id],
	    () => getRandomPhotoAndBookmarks(currentPhotoId, userData?._id),
	    {
	      refetchOnWindowFocus: false,
	    },
	  );
	
	return (
		<PhotoWrapper>
		  <PhotoView photo={data.photo.imageUrl}/>
	    <MainPageHeader />
	    <AsideButtons />
	    <BottomButtons />
		</PhotoWrapper>
         );
}

function PhotoView({ imageUrl }) {
	return <img src={imageUrl} />;

PhotoView.propTypes = {
	imageUrl: PropTypes.string.isRequired,
};

필요한 props에만 의존하도록 PhotoView 컴포넌트를 리팩토링하여, 다른 데이터 객체, 컴포넌트에서도 대응할 수 있게 되었다.

인터페이스 분리 원칙을 통해 컴포넌트들 간의 의존성을 낮추고, 재사용성을 높일 수 있다.

5. 의존관계 역전 원칙 (Dependency inversion principle)

SOLID 원칙 중 가장 이해가 쉽지 않은 부분이다.

한마디로, 객체는 직접적으로 저수준 모듈(객체, 클래스) 보다는 추상화 된 인터페이스와 같은 고수준 모듈에 외존해야 한다는 것이다.

왜 그럴까? 스택오버플로우에서 깔끔하게 설명한 부분이 있다.

What is the dependency inversion principle and why is it important?

(’아티클 지니’를 통해 공유하고자 하는 문단을 하이라이트 하였습니다.)

궁극적으로는 각 객체간의 관계를 최대한 느슨하게 유지하기 위한 것이다.

이것을 리액트에 적용하면 한 컴포넌트가 다른 컴포넌트에 직접적으로 의존해서는 안되며, 둘 다 공통된 추상화에 의존해야 한다.

이 원칙이 적용된 예시를 통해 살펴보자.

이번 프로젝트에서 VAC(View Asset Component) 패턴을 사용하였는데 이 패턴을 통해 의존관계 역전 원칙을 일부 따를 수 있었다.

구글 로그인 버튼을 이용하여 ‘login’ API 요청을 보내는 Login 컴포넌트이다.

import { login } from "../../api";

function Login() {
  const loginMutation = useMutation(login);
  const handleLogin = async credentialResponse => {
    const profileObj = jwtDecode(credentialResponse.credential);

    const { name, email } = profileObj;
    loginMutation.mutate(
      { name, email },
      {
        onSuccess: response => {
          localStorage.setItem("loginData", JSON.stringify(response));
        },
      },
    );
  };

  const LoginProps = {
    onLoginButtonClick: handleLogin,
  };

  return <LoginView {...LoginProps} />;
}

function LoginView({ onLoginButtonClick }) {
  return (
    <Wrapper>
      <Description>
        Fall into the beautiful landscape and the sound of your imagination.
      </Description>
      <GoogleLogin
        onSuccess={onLoginButtonClick}
        onError={() => {
          console.log("Login Failed");
        }}
      />
    </Wrapper>
  );
}

LoginView.propTypes = {
  onLoginButtonClick: PropTypes.func.isRequired,
};

LoginView 컴포넌트는 직접적으로 api 모듈에 직접 의존하지 않고, Login 컴포넌트에서 props로 주입받은 함수를 통해 추상화되었다.

로그인 로직을 구체적인 구현은 LoginView 컴포넌트의 상위 컴포넌트의 Login 컴포넌트의 책임이 되었다. (로그인 로직은 ‘React Query Mutation’을 통해 구현하였다.)

Login 컴포넌트 api 모듈과 LoginView 컴포넌트 사이에 추상화된 인터페이스 역활을 하며 컴포넌트와 모듈간의 직접적인 의존을 부섰다.

하지만, VAC 패턴으로는 완벽하게 의존성을 없애는데에 한계가 존재했고 presentational container pattern을 적용하면 조금 더 객체 지향적으로 이 원칙을 따를 수 있을거라 예상한다.

6. 결론

완벽하지 않지만, SOLID를 원칙을 이번 프로젝트를 기회삼아 리액트에 적용해 보았다.

필자는 아직 실력있는 시니어 개발자들처럼 개발전 아키텍처를 설계하는 능력이 부족하다. 그래서 설계를 완벽하게 하고 개발을 시작하는 것이 아니라 ‘리액트로 사고하기’와 같이 간략한 구조 설계 후 개발을 일단 시작한다. 그 다음 하나의 컴포넌트에 ‘monolithic’ 코드 덩어리를 작성한 후 SOLID원칙에 따라 모듈화 또는 분리를 진행하였다.

객체 지향 원칙이 리액트에서도 적용된다는 부분이 신기하였고, 객체 지향 원칙이 정말 잘 만들어진 구조이기 때문에 이렇게 범용적으로 적용할 수 있다 생각하였다. 결과적으로 이 원칙은 나에게 좋은 개발 경험을 안겨주었다.

하지만, 기존의 설계 패턴이나 소프트웨어 구조 원칙이 그러하듯이 이것을 맹신하여 상황에 맞지 않게 원칙을 지키려고 한다면 코드는 더 복잡해지고 오히려 유지보수가 어려워 질 수도 있다라고 느꼈다.

앞으로 이런 좋은 원칙이나 설계 패턴을 참고하여 팀과 프로젝트 상황에 맞게 적재적소에 적용할 수 있는 능력을 길러야 겠다라고 생각하였다.

7. 참고자료

• Applying SOLID principles in React
• The S.O.L.I.D Principles in Pictures
• 창시자 앨런 케이가 말하는, 객체 지향 프로그래밍의 본질

RESTFul API에 대해서 알아보던 중 궁금한 점이 생겼다.

진정한 RESTFul 의미는 무엇일까?

나의 백엔드 서버는 ‘RESTFul‘ 한가?

그래서 RESTFul API에 대해 조사해보고, 실제로 그것을 만들기 위해 노력해보았다.

1. API(Application Programming Interface) 란?

REST API를 알기전에 API의 정의를 먼저 살펴보자.

API는 컴퓨터나 컴퓨터 프로그램사이의 연결이다. 일종의 소프트웨어 인터페이스이며 다른 종류의 소프트웨어에 서비스를 제공한다.

- wikipedia

전혀 무슨말인지 모르겠다.

그럼 조금 더 쉽게 API에 대해서 알아보자.

우리가 식당에 갔을 때 요리사에게 바로 주문을 하는 것이 아니라, 점원에게 요청을 하고 점원이 다시 우리의 주문을 요리사에게 요청하고 만들어진 요리를 점원이 가져다준다. (요리사에게 바로 요청하지 않는 이유는 쉽게 떠오를 수 있다)

즉, 보통에 웹에서 클라이언트(손님), DB(서버) 사이에서 API가 점원의 역활을 해준다.

1.1 API의 역활

• 서버와 DB 대한 출입구 역활

만약 API가 없다면 우리는 DB에 접근할 수 있는 권한을 얻어 직접 쿼리를 날려 우리가 원하는 데이터를 가지고 와야한다.

SELECT * FROM inventory WHERE status = "A" AND qty < 30

db.inventory.find( { status: "A", qty: { $lt: 30 } } )

API가 대신 접근권한도 관리하고, 우리 대신 효율적인 쿼리를 만들어 데이터를 가지고와 필요하다면 가공시켜 우리에게 응답을 줄 것이다.

• 모든 접속을 표준화한다.

기계/운영체제에 상관없이 동일한 요청에 대해서는 동일한 결과를 주도록 ‘표준화’ 시킨다.

2. REST (Representaional State Transfer)?

REST는 HTTP 프로토콜을 그대로 활용하여 웹의 장점을 최대한 활용할 수 있는 아키텍처 원칙 세트이다.

리소스를 이름으로 구분하여 해당 리소스의 정보를 주고 받는 모든 것을 의미한다.

2.1 왜 등장했을까?

위에 분 로이필딩께서 ‘REST’를 제안하셨다.

로이필딩은 박사논문으로 ‘REST’를 발표했다. 그는 논문에서 ‘REST’를 만들게 된 이유로 아래와 같이 설명했다.

“웹의 구조를 서술하는 비공식 문서들과 두 개의 소개 형식의 논문 등이 있었지만 실제 웹 구현이 너무 빨라 이미 시대에 뒤떨어진(out-dated) 경우가 많았다” 또 “그 당시 이미 캐시와 프록시 등이 웹에는 존재했지만 이에 대해 인식하는 표준은 없다시피 했다.“

그렇기에 웹에 대한 새로운 표준, 또는 표준의 확장이 꼭 필요했다.

또, 로이필딩은 웹의 최대 장정 중 하나인 ‘하위호환성’에 대해서도 고민하였다. 기존에 웹에서도 동작하고 ‘HTTP’ 프로토콜 기능을 증가시킬 방법으로 ‘REST’를 고안한 것이다.

2.2 REST 구성요소

• 자원(Resource): URI
• 행위(Verb): HTTP Method
• 표현(Representation of Resource)

2.3 REST의 특징

• Server-Client (서버-클라이언트 구조)
• Stateless (무상태)
• Cacheable (캐시 처리 가능)
• Layered System (계층화)
• Code-On-Demand (optional)
• Uniform Interface (인터페이스 일관성)

REST의 구체적인 특징을 자세하게 보고싶다면 아래에 글을 추천한다.

[Network] REST란? REST API란? RESTful이란? - Heee's Development Blog

REST라는 말이 어려워 보이지만 결국 권위있는 사람이 제시하는 HTTP를 사용하는 웹과 관련된 애플리케이션의 일관성을 위한 가이드 라인이다.

3. REST API?

그렇다면 이제 위에 개념을 합쳐보자.

‘Rest API’는 REST 가이드라인을 기반으로 API를 설계한 것을 ‘REST API’라고 한다.

하지만, 실무에서 쓰이는 이 ‘REST API’라는 말이 로이필딩의 의도와는 다르게 변질된 거 같다.

왜냐하면 2016년에 Microsoft에서 Microsoft REST API Guidelines를 발표했지만 로이필딩은 그것은 REST API가 아니라 그냥 HTTP API라고 해야한다고 말했다.

api-guidelines/Guidelines.md at vNext · microsoft/api-guidelines

대부분의 REST API라고 지칭하는 것들은 REST 가이드라인을 완벽하게 지키지 않았다.

특히, ‘Uniform Interface’의 제약 조건 중 ‘Self-descriptive messages’(메시지가 스스로 설명해야 한다. 즉, 메세지만 보고 무슨 뜻을 의미하는지 알아야한다.) ‘HATEOAS’ (애플리케이션의 상태는 HyperLink를 이용해서 전이되어야 한다.)를 거의 지키지 못하고 있다.

이에 대한 설명은 아래에 영상을 보기를 추천한다. REST API에 대한 근본적인 설명과 함께 웹의 특징을 잘 설명해주셔서 이해하기가 좋았다.

그리고 실무에서 REST API라고 지칭하지만, 사용자 ‘Authorization’ 방식으로 쿠키, 세션을 사용한다.

이것은 REST 규칙중 하나인 ‘Stateless (무상태)’를 이미 위반한 것이다.

그러니깐 구글링 하였을 때 나오는 대부분의 ‘REST API’ 관련 블로그 글들은 로이필딩이 말하는 전통적인 ‘REST API’ 보다는 ‘Microsoft REST API Guidelines’, 또는 실무에서 주로 쓰이는 API 설계 방식이라고 보는게 맞을 꺼 같다.

REST API를 설계할 때 대표적인 방식을 살펴보면 ‘URI는 동사보다는 명사, 대문자보다는 소문자를 사용하여야 한다’

HTTP GET <http://www.appdomain.com/users/123>
HTTP GET <http://www.appdomain.com/users/123/address>

또 REST API 설계 방식 중 하나인 ‘리소스에 대한 행위는 적절한 ‘HTTP Method (GET, PUT, POST, DELETE)’로 표현해야 한다’에 대해 살펴보자

위에서 대표적인 CRUD에 대해 어떤 Method를 사용해야하는지 설명하고 있다.

그 중 PUT과 PATCH를 살펴보자.

• PUT: 해당되는 경우 객체를 바꾸거간 명명된 객체를 만든다.
• PATCH: 객체에 대한 부분 업데이트 적용

RFC문서에서도 PUT과 PATCH 역활을 위와 비슷하게 설명하고 있다.

• HTTP/1.1: Method Definitions
• RFC 5789: PATCH Method for HTTP

오늘은 이 규칙을 중점적으로 나의 API 서버는 과연 이것을 잘 지키고 있는가를 살펴보고자 한다.

4. 실습

‘Express’를 이용한 서버에서 ‘Mongoose’를 통해 MonogDB에 기본적인 CRUD를 담당한다.

그 중 ‘UPDATE’에 주목해보자.

exports.update = asyncHandler(async (req, res, next) => {
  const updatedArticle = await Article.findByIdAndUpdate(
    req.params.article_id,
    req.body,
    { new: true }
  );

  res.json({ result: "ok", article: updatedArticle });
});

router.put(
  "/:article_id",
  verifyToken,
  verifyArticleId,
  articlesController.update
);

만약 클라이언트가 아래와 같이 요청을 보낸다면

HTTPRequest
PUT `/articles/${articleId}`
{
  title: "Hello World"
}

아래와 같이 MongoDB에 저장된 데이터가 업데이트 되어야 한다.

{
  _id: "627620efd2a10c5dd2d0cabd"
  title: "Hello World"
}

하지만, 내가 사용한 ‘findByIdAndUpdate’는 전체 데이터를 ‘replace’ 하는것이 아니라 클라이언트가 보낸 데이터를 이용하여 이미 존재하는 아이템에 해당 속성(’title’)을 업데이트 할 것이다.

Mongoose v6.5.2:

위에 ‘Microsoft REST API Guidelines’에 따르면 PUT Method은 전체 요청으로 받은 객체를 통채로 교체할 때 (replace) 때 사용해야 하지만 코드에서는 그러고 있지 않다.

그럼 이것을 조금더 REST스럽게 바꿔보자. PUT과 PATCH에 대한 동작을 각각 정의해주었다.

exports.replace = asyncHandler(async (req, res, next) => {
  const replacedArticle = await Article.findOneAndReplace(
    req.params.article_id,
    req.body,
    {
      upsert: false,
      new: true,
    }
  );

  res.json({ result: "ok", article: replacedArticle });
});

exports.update = asyncHandler(async (req, res, next) => {
  const updatedArticle = await Article.findByIdAndUpdate(
    req.params.article_id,
    req.body,
    { new: true }
  );

  res.json({ result: "ok", article: updatedArticle });
});

router.put(
  "/:article_id",
  verifyToken,
  verifyArticleId,
  articlesController.replace
);

router.patch(
  "/:article_id",
  verifyToken,
  verifyArticleId,
  articlesController.update
);

replace를 관련 로직은 ‘mongoose’에 ‘findOneAndReplace’ 메서드를 사용하였다.

Mongoose v6.5.2: API docs

이제 ‘PUT’ Method에 대해서 적절한 방식으로 동작하고 클라이언트가 보낸 데이터를 이용하여 ‘replace’, ‘update’가 가능해졌다.

포스트맨을 활용하여 API가 제대로 확인해보자.

위에서 보는것과 같이 REST API를 규칙을 따르려고 한 의도대로 PUT은 ‘replace’ PATCH는 ‘update’ 동작하고 있는 것을 볼 수 있다.

5. 정리

API와 REST에 대한 간단한 개념을 살펴보고 REST API에 대한 오해와 대표적인 규칙들에 대해 살펴보았다.

그리고 직접 그 규칙을 따르기 위해 노력해보았다.

직접 실습해 본 결과 내가 한 부분이 굉장히 작은 부분임에도 불구하고 규칙을 전부 따르기가 굉장히 어렵다는 것을 느꼈다.

그리고 진정 REST 규칙을 전부 지켜서 설계한 API를 RESTFul API라 지칭한다.

그럼 우리 전부 RESTFul API를 향해 가야할까?

“REST emphasizes evolvability sustain on uncontrollable system. If you think you have control over the system or aren’t interested in evolvability, don’t waste your time arguing about REST . — Roy T. Fielding

로이필딩은 시스템 전체를 통제할 수 있다면 그리고 진화에 관심이 없다면(🥲 ) REST에 대해 따지느라 시간을 허비하지 말라고 한다.

내가 생각하기에는 REST를 지키기 위해 노력하는 것도 중요하지만, 실무에서 클라이언트, 서버 단 개발자들 끼리의 소통과 사내에서 약속된 문서를 통해 효율적인 API 설계도 중요하지 않을까 생각해본다.

하지만 마지막으로 진정 중요한 것은…!

로이필딩이 말한 REST 규칙을 모두 지키지 않고 ‘RESTFul API’라고 지칭하지 말자.

이분이 화내신다.

5.1 참고자료

• 그런 REST API로 괜찮은가?
• REST API(RESTful API, 레스트풀 API)란 - 서버, 구현, 사용법
• 논문을 통한 REST에 대한 고찰