• 실습이 필요하려나… 나도 이 정도 공부했다고 해서 바로 쓸 자신은 없다.
• 코테 끝나고 실습까지 추가를 하면서 더 알아야될 부분을 찾아보겠습니다

GraphQL이란?

그 전에 REST API는?

• 엔드포인트를 이용해 호출하면 서버가 정해준 형태로 데이터를 받음

• 클라이언트가 원하는 데이터 구조를 직접 정의해서 요청하는 API 쿼리 언어
• 프론트가 데이터 shape를 설계해서 요청하는 것

• sql과 마찬가지로 쿼리 언어 ⇒ 하지만 차이는 큼
• 그 언어적 구조 차이가 활용 측면에서의 차이를 가져온 것

• SQL: 서버에서 DB에 접근해 데이터를 효율적으로 가져오는 것

SELECT plot_id, species_id, age, weight, ROUND(weight / 1000.0, 2) FROM surveys;

• GQL: 클라이언트에서 서버에 접근해 데이터를 효율적으로 가져오는 것

{
  hero {
    name
    friends {
      name
    }
  }
}

• gql 서버는 gql로 작성된 쿼리를 입력으로 받아 쿼리를 처리한 결과를 다시 클라이언트로 전송
• HTTP API 자체가 특정 데이터베이스나 플렛폼에 종속적이지 않은 것처럼 마찬가지로 gql 역시 어떠한 특정 데이터베이스, 네트워크 방식에도 종속적이지 않음

등장 배경

페이스북이 겪은 문제 (2012년)

• 사용자 정보
• 친구 목록
• 게시글
• 좋아요 수
• 댓글

1. Over-fetching

{
  "id": 1,
  "name": "재영",
  "age" : 26,
  "email" : "cjy3458@naver.com",
}

• 프론트는 name만 필요한데 다 받아옴

1. Under-fetching

{
	"title": "뉴스 제목입니다",
}

{
  "author": "최기자",
}

{
	"comment": {
		"id": 1,
		"content"

• 필요한 데이터가 여러 API에 흩어짐
• 요즘은 이런 일은 없음
• 모바일에서는 요청을 많이 보낼 수록 체감 성능 저하

페이스북의 결론

“서버가 아니라 클라이언트가 데이터 구조를 정의하게 하자”

REST와 GraphQL 차이

• base url, Method를 조합하기 때문에 다양한 endpoint 사용
• endpoint마다 DB를 조회하는 SQL 쿼리가 달라짐

• 단 한개의 endpoint
• gql 스키마의 타입마다 DB를 조회하는 SQL 쿼리가 달라짐

GQL 기본 지식

개념

• Schema: 서버가 제공하는 데이터 구조 계약서(API 명세서)
• Query: 조회(R)
• Mutation: 생성/수정/삭제(CUD)
• Subscription: 실시간(websocket)
• Resolver: 실제 데이터를 가져오는 함수

GQL 구조

• 직관적
• 요청 쿼리문과 응답 구조는 거의 동일

// 쿼리문
{
	camper {
		name
	}
}

// 응답

{
	"data": {
		"camper" : {
			"name" : "Jay"
			

GQL Schema

type Query {
  product(id: ID!): Product
}

type Mutation {
  addProduct(name: String!, price: Int!): Product

• 프론트가 보게될 API 명세서와 같음

Query

query GetProduct {
  product(id: "1") {
    name
    price
  }
}

• Schema를 보고 필요한 데이터를 읽어옴
• name, price 중에 원하는 데이터만 받기도 가능

Mutation

mutation AddProduct {
  addProduct(name: "맥북", price: 2000000) {
    id
    name
  }
}

• Schema를 보고 필요한 데이터를 생성 및 변경
• mutation에서는 “!”가 붙은 모든 값들을 함께 보내야 함