이 글은 Ronak Ganatra님의 GraphQL Vs. REST APIs를 참고해서 쓴 글입니다.
GraphQL vs REST APIs
REST API와 grphaQL의 가장 큰 차이는 graphQL은 query language로서 specification(설계명세서)라고 할수 있고, REST는 네트워크 소프트웨어 설계 컨셉이라고 할 수 있다.
Rest API란?
REST (Representational State Transfer)는 웹 서비스를 만들때 억제를 수행하는 구조적 스타일이다. REST의 장점은 XML포멧에만 한정된게 아니라 JSON, XML, YAML등의 데이터 포멧으로도 확장이 될 수 있다는 것이다.
클라이언트가 REST API를 요청할때, 서버는 리소스를 규격화된 형식으로 변환한다. API는 소스가 요청됬을때, 해석가능한 포멧된 정보를 되돌려주는 방식으로 작동된다.
graphQL API란?
graphQL은 오픈소스 데이터 쿼리로, 기존에 존재하는 데이터에 대한 쿼리를 총괄하는 api다. 특히 트위터, 엑스피디아, 쇼피파이같은 회사에서 굉장히 잘 적용해서 사용되고 있다.
📌 Data Fetching
REST의 가장 큰 한계는 overfetching과 underfetching이다. 이건 클라이언트에서 데이터를 다운받을때, 한개의 엔드포인트를 갖고있기 때문에 발생한다. API를 만들때 서버쪽에서 클라이언트가 필요한 만큼의 데이터만 설계하는것은 매우 어려운일이다.
overfetching은 클라이언트가 필요한 만큼보다 더 많은 정보를 넘겨받는 것인데, 예를들어 햄버거라는 모델의 이름만 필요할 경우, end point에 요청을 보냈을때 이름 이외에 가격, 영양분, 칼로리등의 정보까지 오는것을 말한다.
grahpQL의 장점은 원하는 만큼의 데이터만 요청을 할 수 있다. 예를들어 햄버거 스키마에 패티의 종류, 영양분, 가격을 제외한 정보만 요청이 가능하다.
📌 Schema and Type Safety
graphQL은 강한 typed 시스템을 갖고있다. grahpQL 스키마를 사용할때, 모든 타입은 정의되어 있어야 하고, 그 타입으로만 요청이나 응답이 가능하다. 백엔드 팀에서 api를 front팀에게 어떠한 말 없이 바꾸더라도, front 팀에서는 즉각적인 피드백을 graphQL로부터 받을 수 있다.
📌 Rapid Product Development
공통된 REST API의 구조는 view에 따른 endpoints를 갖고있다( /menu, /prices, /images). 이게 간단하고 좋은 이유는 클라이언트가 모든 정보를 취합 후, 특정 뷰를 만들때 쉽게 매칭할 수 있기 때문이다.
하지만, 앱의 UI가 바뀐 경우엔 더 자세한 데이터가 필요하거나, 해당 데이터가 필요 없어지는 경우가 생길 수 있는데, 그럴때마다 back-end가 새로운 요청에 따른 수정이 필요한데, 효율성 측면에서 앱을 만들때 더 느려진다는 단점이 있다.
GraphQL은 클라이언트가 요청을 조절할 수 있는데, 어떤 데이터가 필요할지, 어떤데이터가 필요 없을지를 생각해서 필요한 만큼의 데이터만 요청할 수 있다. 가장 큰 장점은 이러한 조정이 back-end에 어떠한 행동도 없이 가능하단 점이다.
📌 Schema Stitching
REST와 graphQL의 가장 큰 차이점은 다른 스키마의 데이터를 서로 합칠 수 있단 점이다. 예를들어 버거와 영양소의 서로 다른 모델이 있을때, 두개의 모델을 합쳐서 요청을 할 수 있다는 점이다
{
burgers(where: { name: "cheeseburger"})
# from Menu endpoint
name
description
price
# from Nutrition endpoint
calories
carbohydrates
# from Restaurant endpoint
inStock
}정리하자면
graphQL의 특징
1. data fatching할 때 over-fatching과 under-fatching이 일어나지 않게 조절이 가능하다.
2. typed가 정의된 스키마를 갖고 있어서, 데이터 요청 응답시 맞는 format을 사용해야한다
3. front-end에서 요청을 조절할 수 있어서, 빠르게 변경되는 UI서비스를 하고 있는 서비스에 유리하다
4. 서로다른 스키마라도 합치는게 가능하다
