GraphQL?

pengooseDev·2023년 5월 8일
0
post-thumbnail

REST API

우리는 API와 관련된 작업을 수행하며, 아래와 같은 API 명세서를 마주하게 된다.

사용자가 영화 정보를 요청할 때, 아래의 API 명세서에 따라 처리해 주세요! :)

method: GET
endpoint: /api/movie/{id}
res: // res

위의 방식은 REST API이다. 해당 방식은 보편적으로 사용되는 방식이지만, 몇 가지 문제점을 가지고 있다.


OverFetching / UnderFetching

OverFetching : 필요한 정보보다 많은 정보가 서버로부터 도착한 경우.
UnderFetching : 필요한 정보보다 적은 정보가 서버로부터 도착한 경우.

예를 들어, 최근 개봉한 영화의 리스트를 렌더링하는 컴포넌트를 구현한다고 가정하자.

프론트엔드에서 필요한 정보

{
  "movieId" : 1,
  "title": "영화 제목",
  "releaseDate": "개봉일",
  "thumbnail": "영화 썸네일 url",
}

현재 구현되어 있는 API는 아래와 같은 정보를 전달한다.

백엔드에서 보내주는 정보

{
  "movieId" : 1,	  
  "title": "영화 제목",
}

원하는 기능을 구현하기엔 데이터가 부족하다. 이것이 underFetching이다. 다른 API에 추가적인 요청을 보내 아래의 데이터를 얻었다고 가정하자.

{
  "releaseDate": "개봉일",
  "director": "감독",
  "actors": "배우 목록"
  "thumbnail": "영화 썸네일 url",
  // ... 여러 데이터들
}

원하는 데이터를 전부 얻었지만, 필요한 데이터보다 많은 데이터를 얻게 되었다. 이러한 현상은 DB에 불필요한 방문을 발생시키며, 과도하게 많은 HTTP 통신이 발생한다는 비효율이 발생한다.

물론, 프론트엔드에서 사용할 기능들에 따라 모든 API를 만드는 것을 고려할 수 있겠지만, 그러한 의사결정엔 아래와 같은 문제가 발생할 수 있다.

  1. 모든 기능 하나하나에 API를 작성한다는 것은 리소스적으로 비효율적이며 확장성 및 유지보수에 지속적인 비용이 발생한다는 문제가 있다.
  2. 늘어나는 API에 대해 관리하기 어려워진다.
  3. API에 대해 프론트엔드와 백엔드의 강한 결합이 발생하여 유지보수나 확장에 유연성이 떨어진다.

GraphQL

프론트엔드에서 필요한 정보를 GrapgQL을 이용해 요청해보자.
GraphQL은 BE에서 작성된 Schema를 기반으로 원하는 데이터를 직접 입력해, 백엔드에 요청할 수 있다.

프론트엔드에서 요청한 값

query {
  movie(id: 1) {
    movieId
    title
    releaseDate
    thumbnail
  }
}

백엔드에서 보내주는 정보

{
  "movieId" : 1,
  "title": "영화 제목",
  "releaseDate": "개봉일",
  "thumbnail": "영화 썸네일 url",
}

위와 같은 방식을 채택할 경우, FE의 컴포넌트에 특정한 API에 대한 의존성이 발생하지 않아 확장성유지보수에 큰 이점을 취할 수 있다.
또한, DB에 불필요한 데이터의 요청이 사라지기 때문에 상대적으로 리소스를 아낄 수 있다는 장점이 존재한다.

0개의 댓글