Rest API -> GraphQL, Webpack -> Parcel

from React와 Apollo, Parcel 기반 서비스 개발

Rest API -> GraphQL

서비스를 운영하다 보면 다음과 같은 데이터를 처리해야 할 때가 있다.

• 서비스에서 사용하지 않는 불필요한 데이터
• 외부에 노출하지 말아야 하는 내부(private) 데이터
• API 변경에 따라 새로 추가되는 데이터
• PC 환경과 모바일 환경에 따라 달라지는 데이터

사용자에게 빠른 서비스를 제공하고 네트워크의 사용량을 줄이려면 위와 같은 데이터에서 일부를 삭제해야 한다. 기존에는 다음과 같은 조건을 확인해 데이터를 삭제하는 로직과 RESTful API를 제공했다.

• 데이터 삭제 로직에 사용되는 요청 쿼리의 값
• API 라우팅 경로

하지만 데이터를 삭제하는 로직을 추가하는 방식에는 다음과 같은 단점이 있다.

• 객체가 중첩되어 있으면 복잡한 삭제 로직이 필요하다.
• 조건의 분기가 많아질수록 API 서버의 성능이 저하된다.
• 삭제 로직 개발을 위해 개발자의 리소스가 추가로 소요된다.

이런 단점을 극복할 수 있는 기술이 GraphQL이다.

GraphQL은 SQL처럼 데이터의 집합에서 특정 데이터를 불러오는 데이터 질의 언어(data query language)다. 클라이언트가 미리 선언한 데이터 구조대로 서버에 데이터를 요청하면 서버는 요청받은 구조로 데이터를 반환하는 특징이 있다. 데이터 모델에 따라 GraphQL 스키마(schema)를 선언해 두면 선언한 스키마의 하위 필드에서 원하는 필드만 HTTP 요청의 본문(body)으로 보내고 응답으로 데이터를 받을 수 있다.

예를 들어 다음과 같은 데이터가 있다고 가정하자.

Users = [{  
  firstName: '길동',
  lastName: '홍',
  phoneNumber: '010-1234-5678'
}, {
  firstName: '길리',
  lastName: '홍',
  phoneNumber: '010-1234-5679'
}];

그리고 GraphQL 스키마를 다음과 같이 선언한다.

type user {  
  firstName: String!
  lastName: String!
  phoneNumber: String!
}

firstName 필드의 데이터만 사용하고 싶다면 다음과 같이 데이터를 제공받을 필드의 이름을 HTTP 요청의 본문으로 보낸다.

{
  query user  {
    firstName
  }
}

별다른 삭제 로직을 개발해 적용하지 않아도 다음과 같이 필요한 데이터만 받을 수 있다.

{
  "data": {
    "user": [{
        "firstName": "길동"
      }, {
        "firstName": "길리",
      }]
  }
}

단점

1. 중첩된 객체와 객체 배열에 대해서도 스키마를 정의해야 한다. 만약 정의되지 않은 리소스 타입을 요청하거나 반환하면 오류가 발생한다. 복잡한 모델을 사용할 때에는 스키마를 정의하는 일이 복잡하게 느껴질 수 있다.

Webpack -> Parcel

Parcel은 최근 빠르게 성장하고 있는 번들러다. 빠른 빌드 속도와 쉬운 작동 방법이 장점이다. 간단한 프로젝트에서는 별다른 설정이 필요 없어 각광을 받고 있다.

Parcel을 선택한 이유는 매우 단순하다.

webpack을 사용하면 관리해야 하는 플러그인이 늘어나면서 설정 파일의 내용이 점점 길어진다. 새로 프로젝트에 참여하는 개발자의 학습 시간도 점점 길어진다. Parcel은 zero configuration을 지향해 설정 파일이 필요 없다. 또한 플러그인을 사용하지 않아도 된다. 이런 장점 때문에 Parcel을 선택했다. '불꽃처럼 빠른(Blazing fast)' 빌드 속도라고 홍보할 정도로 빌드 시간이 짧다는 것도 Parcel을 도입하는 데 영향을 준 요인이다.

Parcel의 빌드 속도에 관해서는 GitHub 저장소의 README.md 파일을 참고한다.

단점

1. Parcel은 2017년 12월에 1.0.1 버전으로 출시된 번들러다. 그래서 문서화가 덜 되어 있다. 필요한 기능을 GitHub 저장소의 Issues에서 찾아 적용해야 하는 경우도 있고, 사소한 버그를 해결하기 위해 소소 코드를 봐야 하는 경우도 있다.
2. webpack의 externals 설정과 같은 기능을 지원하지 않아서 번들에서 특정 라이브러리를 제외하기 어렵다.
3. Assets 유형으로 번들을 생성하기 때문에 JavaScript 안에 CSS를 포함하도록 하려면 별도의 컴포넌트를 사용해야 한다.
4. 확장자에 따라 번들을 생성하기 때문에 import css from './style.css'을 선언해도 별도의 .css 파일과 .js 파일을 생성하는 문제도 있다. 인라인 형식으로 만들려면 styled-component와 같은 별도의 라이브러리를 사용한다.