GraphQL을 사용하는 이유를 물으면 Under-Fetching과 Over-Fetching 문제를 해결할 수 있다는 점을 들 수 있습니다.

REST-API의 문제점

Over-Fetching

필요한 것보다 많은 데이터를 서버에서 받아오는 것을 말합니다.

예를 들어 게시판 목록 화면에 제목, 내용, 날짜, 작성자만 보여 준다면

  "data": {
    "fetchLists": [
      {
        "_id": "202202161136190074",
        "title": "제목이에요.",
        "contetns": "내용입니다~",
        "regDt": "2022-02-16 11:41:39.0",
        "likecnt": 3, // 필요하지 않은 데이터
        "writer": "쎄오",
        "commentCount": "1", // 필요하지 않은 데이터
        "files": [ // 필요하지 않은 데이터
          {
            "fileId": "FILE_202202161141390217",
            "orignlFileNm": "사진.jpg",
            "fileSize": "68945",
            "fileExt": "jpg",
            "fileKnd": "attach"
          }
        ]
      },
      {
        "_id": "202202161136190075",
        "title": "제목이에요.",
        "contetns": "내용입니다~",
        "regDt": "2022-02-16 11:42:39.0",
        "likecnt": 1, // 필요하지 않은 데이터
        "writer": "짱구",
        "commentCount": "1", // 필요하지 않은 데이터
        "files": [ // 필요하지 않은 데이터
          {
            "fileId": "FILE_202202161141390219",
            "orignlFileNm": "사진.jpg",
            "fileSize": "68945",
            "fileExt": "jpg",
            "fileKnd": "attach"
          }
        ]
      }]
	}
}

필요하지 않은 데이터까지 함께 받아오기 때문에 서버와 네트워크 자원이 불필요하게 사용됩니다.

Under-Fetching

한 번의 요청으로 필요한 데이터를 모두 받지 못해 여러 번 요청하는 것을 말합니다.

예를 들어 마이페이지에서 내 정보와 함께 찜한 목록도 보여 주도록 기능이 확장되었다면 내 정보와 찜한 목록을 함께 보여 줘야 하는데, API가 GET /users/{id}(내 정보)와 GET /users/{id}/favorite(찜한 목록)으로 나뉘어 있으면 두 번 호출해야 합니다. 그만큼 네트워크 부담이 늘고, 사용자는 느린 속도를 체감할 수 있습니다.

GraphQL도 사실은 HTTP 요청

GraphQL은 REST API의 불편함을 개선하기 위해 나왔지만, 내부적으로는 HTTP 요청으로 동작합니다.

GraphQL API는 대부분의 경우 상태 코드가 200으로 오기 때문에, 에러는 응답 바디의 errors를 확인해야 합니다.

GraphQL을 Postman으로 호출해 보기

GraphQL query를 Postman으로 호출

GraphQL mutation을 Postman으로 호출