개발을 배운 이래로, 보다 REST에 가까운 url을 작성하고자 많은 시간을 들였다. 내 첫 url은 'localhost:5000/product/main-page' 이었는데, 누가봐도 '아..저게 무슨..' 이라고 생각할 만하다.
REST API는 현재도 가장 보편화된 웹 API 디자인이지만, 원하는 정보가 시시각각으로 바뀌는 요즘 같은 환경에서는 적절하지 못하다는 의견이 꽤 많다. 적절하지 못하다? 그게 뭘까?
사용자의 이름과 나이만 필요한데, 전화번호나 주소까지 다 전달 될 때. 혹은 기껏 필요한 자료만 전달하도록 해놓았더니 다시 '아 미안한데, 핸드폰 번호는 줘' 라고 할 때.. TMI와 TLI를 오가는 경우가 왕왕 발생한다. 오버 페치다.
제품의 세부 정보와, 그 제품을 구입한 사람들의 후기가 필요한 경우, 제품과 후기를 각각 따로 요청해야 한다. 서로 다른 엔드포인트에 (거의) 동시에 접근해야하기 때문이다. 즉, 필요한 정보를 한 번에 충분히 제공하지 못한다는 것을 의미한다. 언더 페치다.
또, 다루는 자료의 depth가 깊어지거나, 복잡해질 경우, url이 계속 길어지는 단점이 생긴다. 이대로 가다간 언젠가는 query string이 지구 끝까지 이어질 것만 같다.
/product/3
/product/3/nutrition
/product/3/allergy
/product/3/allergy?category=3
일반적으로 여러 엔드 포인트에 접근하여 데이터를 가져와야 하는 REST API와 달리 GraphQL에서는 구체적인 데이터 요구 사항이 포함된 단일 쿼리를 GraphQL 서버에 보내기만 하면 된다.
베스킨 라빈스 아이스크림 상품의 이름과 속한 카테고리를 얻고자 한다면, 아래와 같은 request를 프론트엔드로부터 받는다.
query {
Product(id:3) {
name_kr
name_en
category {
name
}
}
}
음, 3번 제품의 정보!
그럼 아래와 같이 전달해주면 된다.
{
"data": {
"Product": {
"name_kr": "초코나무 숲",
"name_en": "CHOCOLATE FOREST",
"category":{
"name": "아이스크림"
}
}
}
}
클라이언트가 GraphQL을 사용하여 쿼리 내부에 필요한 데이터를 정확하게 지정할 수 있다.
REST API의 일반적인 패턴은 앱 내부에있는 뷰에 따라 엔드 포인트를 구성하는 것이다. 프론트엔드가 해당 엔드 포인트에 접근하기만 하면 필요한 모든 정보를 얻을 수 있으므로 편리하다.
하지만 UI가 변경 될 때마다 필요한 자료는 바뀌므로, 새로운 요청을 고려하여 백엔드를 조정해야한다.
GraphQL을 사용하면 이 문제가 해결된다. 서버에서 추가 작업을하지 않고도 클라이언트 측을 변경할 수 있기 때문이다. 프론트 엔드에서 정확한 데이터 요구 사항을 지정할 수 있으므로 백엔드 엔지니어가 조정할 필요가 없다.
또한, 프론트엔드에서부터 데이터 구조에 직접적으로 접근하다고 볼 수 있으므로, 요청을 보내는 클라이언트 쪽에서도 사용 가능한 데이터가 어떻게 구성되어 있는지 보다 깊이 이해하고 있어야 한다.
스키마는 클라이언트와 서버 간의 계약으로 클라이언트가 데이터에 액세스하는 방법을 정히하는 것이다. API에 노출되는 모든 유형은 GraphQL 스키아 정의 언어를 사용하여 스키마에 기록된다. 스키마가 정의되면 해당 팀이 네트워크를 통해 전송되는 데이터의 명확한 구조를 알게되기 때문에 추가 커뮤니케이션 없이도 원활히 작업을 수행할 수 있다 (이론적으로 ㅎ).
스키마에 대해서는 또 추가적으로 알아보도록 하자.
결론. 이제 수많은 엔드포인트 주소를 프론트엔드에게 알려주지 않아도 된다. 프론트님~ 쿼리 잘 짜서 데이터 가져가시면 돼요! 라고 해보자..
구글에서 graphql 찾다가 우연히 들어와 다 읽고 보니 그저 빛..;;