Introduction

GraphQL을 쓰는 이유

데이터 정규화는 힘들다.
데이터 정규화: 중복되는 데이터 제거
- JSON 응답이 도착하면, 응답 내 특정 모델 을 찾아내 정규화하는 과정이 필요하다.
- 적은 리소스를 효율적으로 사용해야 한다.
[ 규칙성 이용 ⇒ 자동화를 통해 ]
- 약속을 정한다 (약속 = 언어) ⇒ GraphQL
- 약속을 통한 쉬운 정규화
- 더 쉬운 상태 관리
⇒ 1. 타입 시스템을 통한 자연스러운 데이터 정규화: 스키마 이용
- 모델 타입을 정의함으로써
⇒ 2. ID 값을 통해 자동적으로 데이터/ 뷰 일관성 달성하기
- id 필드를 통해 GraphQL 클라이언트가 자동으로 상태 관리
- 데이터/ 뷰 일관성을 위해 따로 리소스 필요 x
컴포넌트에 데이터 의존성 정의
- 컴포넌트는 선언한 props에 직접적으로 의존 하지만, 대부분 그리고자 하는 모델에도 간접적으로 의존한다.
- 결국 상위 모델이 바뀐다면, 이를 간접적으로 의존하고 있는 하위 컴포넌트들도 확인이 필요한 side effect가 존재한다.
- fetch on render ⇒ fetch then render

컴포넌트는 모델에 포함된 값을 필요로 한다.

프래그먼트를 통해 모델의 의존 관계를 잘 나타낼 수 있음.

# Article 모델의 title 필드가 필요
fragment FragmentName on Article {
    title
}

해결해야 할 문제: 쿼리 선언(정의)와 서브컴포넌트 간의 불명확한 의존성

1) 모든 데이터를 하나의 큰 쿼리로 패칭

2) 각각의 컴포넌트는 의존 관계를 가진 데이터를 컴포넌트 안에서 정의 (colocating)

👇

relay의 compilation(편집) 단계 : 모든 변화는 컴포넌트 데이터 의존성을 수정한다.
- 하나의 큰 쿼리를 매번 모든 컴포넌트에서 작성할 필요 없이, 각각의 컴포넌트 안에서 독립적으로 필요한 데이터만 패칭할 수 있게 프래그먼트를 사용
- fragment reference: reference 값에서 데이터 읽기
- 독립된 데이터 의존성은 의도치 않은 데이터 업데이트를 방지한다.
선언적인 GraphQL 문법 사용: not HOW, but WHAT

GraphQL을 사용해 여러 서비스의 모델들을 단일 스키마로 표현: 여러 REST API 서비스를 하나의 GraphQL 스키마로 병합하기
- e.g. 동네 업체/ 구인구직/ 부동산/ 지역광고
  ⇒ 오로지 클라이언트의 요구에 따라 추가적인 서버 스택을 이용하는 것은 부담... ⇒
클라이언트 스키마: GraphQL 서버를 클라이언트에서 작성하기
[isomorphic schema] REST API: DB DB: 클라이언트에서 구현
- 서버 레이어를 증가시키면, 네트워크 지연시간/ 디버깅 등의 어려움 등 다양한 문제 발생
- 클라이언트 스키마: GraphQL 서버 코드를 클라이언트 내에 포함하기

[단점]

워크플로우가 복잡해짐
- graphQL 스키마 수정 → TS 타입 생성 (graphQL code generator) → graphQL 리졸버 수정 → 컴포넌트 수정 → 릴레이 컴파일 → 결과
타입 선언을 이중으로 해주어야 함
번들 사이즈 증가

[장점]

프래그먼트 코로케이션을 통해 유지보수성이 높아짐
데이터를 어떻게 처리하느냐 → 어떻게 선언하느냐
컴파일 타임에 오류를 미리 알 수 있음
데이터 관련한 버그가 현저히 줄어듦
- 이상한 동작을 릴레이가 전부 잡아줌
- e.g. 페이지네이션 결과에서 같은 아이템이 중복해서 내려온다면, 중복된 아이템을 릴레이가 자동으로 삭제해 줌

Relay는 컴포넌트마다 필요한 데이터를 근처에 선언하기 위해 만들어졌습니다. 이것은 어떻게 데이터를 가져올지에 대한 걱정을 하지 않고 각 컴포넌트마다 어떤 데이터가 필요한지만 선언하는 방식을 말합니다.

how는 Relay가 알아서 맡을테니, 우리는 what을 선언적으로 모아서 관리해야 한다.