쌀 팔다 개발자

기본적 정의 : 

GraphQL은 페이스북에서 만든 데이터 질의어이며, 'gql'이라고 한다. gql은 서버에 작성된 쿼리를 통해 데이터를 조회하는 방식이 아니라, 클라이언트에서 쿼리를 작성하여 필요한 데이터만 조회하는 방식을 제공한다. 또한, 하나의 EndPoint를 가지기 때문에 개발 규모에 따라 EndPoint의 복잡도가 증가하는 REST API보다 개발이 간편하다. 여러 데이터 집합에서 데이터를 조회하는 경우 gql은 하나의 쿼리로 조회가 가능하지만, REST API는 Request를 여러번 시도해야 한다. REST API도 한번의 Request로 처리가 가능하지만, 매번 여러개의 데이터 집합을 조회하기 때문에 자원의 낭비를 초래한다.

 GraphQL은 데이터의 구조를 정의하는 스키마(Schema)와 데이터 조회를 위한 쿼리(Query), 데이터 위한 뮤테이션(Mutation), 조회 결과에 대한 구현을 위한 리졸버(Resolver)로 구성되며, 이 외에 API명세서의 기능을 하는 인스로펙션(Instropection)으로 구성된다.

혼자서 공부하며 내린 정의 :

기존 rest api에서 발생하는 문제는  크게 2가지 였습니다.

overfetch와 underfetch

그 중 overfetch는

user의 정보를 요청하는 api를 보냈을 때, 내가 필요한 정보보다 훨씬 많은 정보들이 넘어오는 것이었습니다.

보통 프론트에서는 현재 user의 name만 필요로 하겠지만, 보통 rest api에서 고객 정보를 요청하면 해당 고객의 모든 정보를  보내주도록 구현되어 있어서, 더 많은 리소스 낭비로 이어졌습니다.

그리고 underfetch의 경우, 

만약 고객의 장바구니 정보, 혹시 좋아요한 물품 정보를 모두 함께 보고 싶다고 했을 경우,

user/cart/ 뿐만 아니라 user/wish/ 등 여러가지 api를 요청해야 하는 이슈가 있습니다. 무엇보다 중요한 것은 이게 점점 서비스의 규모가 커져감에 따라서 관리해야 하는 endpoint들이 기하급수적으로 늘어날 수 있다는 것입니다. 이는 개발자나 클라이언트에게 부담이 될 수 있습니다.

GRAPHQL은 위에서 설명한 것처럼 REST API의 한계를 극복하기 위해 나왔습니다.

endpoint는 통상 1개만 생성하고, 클라이언트에서 필요한 데이터는 클라이언트에서 직접 쿼리를 작성하여 호출 반환하도록 합니다.

위의 overfetch문제를 graphql에서는 간단하게 해결 가능합니다.

query {

    user(id:1){

        name

    }

}



{

    "data" : {

        "user":{

            "name" : 'byeonguk'

        }

    }

위의 underfetch 문제도 graphql에서는 간단하게 해결 가능합니다.

query {

    user(id:1){

        name

        cart {

            product_name,

            product_price

        }

        wish {

            product_name,

            product_price

        }

    }

와 같이 해결 할 수 있습니다.

물론 장단점이 있습니다.

장점으로는

• 클라이언트가 필요한 데이터만 반환할 수 있고

• 1번의 호출로 원하는 데이터를 한번에 가져올 수 있습니다. (REST API의 N+1 problem을 해결할 수 있습니다.)

• 확장이 용이합니다.

단점은

• 러닝커브

• 캐싱 기능 구현이 어려움( 대부분의 언어에서 라이브러리로 직접 구현)