Unit6 회고

[API]GraphQL

🔆 GraphQL

GraphQL📈
: 페이스북에서 개발해 오픈 소스로 제공된 쿼리 언어

• Server API를 통해 정보를 주고받기 위해 사용하는 Query Language
  → API를 위한 쿼리 언어
• 트리 구조로 쿼리 결과를 받기 위해 그래프를 탐색하는 언어

• GraphQL의 전제
  • 모든 데이터가 그래프 형태로 연결되어 있다
    • 일대일로 연결된 관계나 여러 계층으로 이루어진 트리 관계도 모두 포함
      (트리와 그래프 모두 노드와 노드를 연결하는 간선으로 구성된 자료구조이기 때문!)
      → GraphQL은 클라이언트 요청에 따라 유연하게 트리 구조의 JSON 데이터를 응답으로 전송
• GraphQL의 특징
  • HTTP를 통해 API 서버로 요청을 보내고 응답을 받음
  • 응답을 받을 시, 데이터 결과를 JSON 형식으로 받음
  • 서버 개발자가 작성한 각 필드에 대응하는 resolver 함수로 각 필드의 데이터를 조회할 수 있음
  • GraphQL 라이브러리가 조회 대상 schema가 유효한지 검사

💡 GraphQL vs REST API

Rest API의 한계🧐

• Overmatch: 필요 없는 데이터까지 제공
  • 어떠한 데이터를 요청 시 하나의 덩어리로 받아야 됨
• Underfetch: endpoint가 필요한 정보를 충분히 제공하지 못함
  • 여러 resource에 접근 시 각기 다른 엔드포인트에 모두 요청을 보내야 함
• 클라이언트 구조 변경 시 엔트포인트 변경 또는 데이터 수정이 필요
  • 자원의 크기와 형태를 서버에서 결정하기 때문에 클라이언트가 직접 데이터의 형태 결정 불가

Rest API와 GraphQL의 차이점

	Rest API	GraphQL
Resource에 대한 형태 정의와 데이터 요청 방법 연결 여부	연결	분리
Resource의 크기와 형태 결정	서버	서버: Resource에 대한 정보 정의 클라이언트: 요청 시 필요한 크기와 형태 결정
Resource와 작업 유형 결정 방법	Resource: URI 작업의 유형: Method	Resource: GraphQL Schema 작업의 유형: Query, Mutation 타입
여러 Resource에 접근 시 요청 횟수	여러 번의 요청 필요	한 번의 요청 필요
작업 처리 방식	해당 endpoint에 정의된 핸들링 함수를 호출	요청 받은 각 필드에 대한 resolver를 호출

GraphQL의 장단점

• GraphQL의 장점😎
  • 하나의 endpoint 요청
    • /graphql이라는 하나의 endpoint로 요청을 받고 요청에 따라 query, mutation을 resolver함수로 전달하여 요청에 응답
      • 모든 클라이언트 요청은 POST 메소드 사용
  • under&overfetching❌
    • 하나의 endpoint에서 쿼리를 이용해 원하는 데이터를 API에 요청&응답 가능
  • 강력한 playground
    • graphql 서버 실행 시, playground라는 GUI를 이용해 resolver와 schema를 한 눈에 보고 테스트 가능
  • 클라이언트 구조 변경에도 서버에 지장 없음
• GraphQL의 단점😅
  • REST API에 친숙한 개발자는 학습하는 데 시간이 필요
  • 캐싱이 REST보다 훨씬 복잡
    • 각 메소드에 따른 캐싱을 지원받을 수 없음
      → 이를 보완하기 위해 Apollo 엔진의 캐싱과 영속 쿼리 등이 등장
    • 고정된 응답만 필요할 경우 Query로 인해 요청의 크기가 커짐

🔆 GraphQL

GraphQL Keywords

• Query
  : 저장된 데이터 가져오기(REST API의 GET과 유사)
• Mutation
  : 저장된 데이터 수정하기
  • Create: 새로운 데이터 생성
  • Update: 새로운 데이터 수정
  • Delete: 기존의 데이터 삭제
• Subscription
  : 특정 이벤트 발생 시 서버가 대응하는 데이터를 실시간으로 클라이언트에게 전송
  • 발행/구독 모델을 따름
    • 이벤트 구독 시, 클라이언트는 서버와 WebSocket을 기반으로 지속적인 연결을 형성하고 유지
      → 그 후 특정 이벤트 발생 시 서버는 대응하는 데이터를 클라이언트에 푸시

쿼리(query, 데이터 조회)

• 필드(Riled): 가져오고자 하는 데이터의 스키마와 정보가 들어감
• 전달인자(Arguments): 필드에 인수 전달 시, 쿼리의 필드 및 중첩 객체에 전달하여 원하는 데이터만 받아올 수 있음
• 별명(Aliases): 필드 이름 중복 사용 시, 별명을 붙여 쿼리
• 오퍼레이션 네임(Operation name): 오퍼레이션 타입에 맞는 이름으로 작성하는 것이 적합
  • 오퍼레이션 타입: query, mutation, subscription, describes 등
• 변수(Varibles): 인수들을 동적으로 받고 싶을 때 사용
  • 오퍼레이션 네임 옆에 $변수 이름: 타입 형태로 정의
  • !은 optional한 사항으로 변수 이름은 반드시 타입 형태여야 한다는 의미

뮤테이션(mutation, 데이터 수정)

• 서버 측 데이터 수정 시 사용
• mutation이라는 키워드를 사용하여 수정

스키마/타입(Schema/Type)

• 스카마의 기본 구성 요소
  • 서비스에서 가져올 수 있는 객체의 종류
  • 포함하는 필드를 나타내는 객체 유형

리졸버(Resolver)

• 요청에 대한 응답을 결정해 주는 함수
• Query, Mutation, Subscription과 같은 타입의 실제 일하는 방식(로직)을 작성
  • 스키마 정의 시 스키마 필드에서 사용되는 함수의 실제 행동을 Resolver에서 정의

<오늘의 일기>
모든 일이 그렇지만(...ㅎ) 서버 측에서 정보를 가져오는 작업은 특히 긴장되는 일인 것 같다,,, 이번 유닛 역시 여러 시행착오 끝에 GraphQL로 github 서버에서 일부 데이터를 가져오는 작업을 수행했는데 가져오는 것에는 성공했지만 받아온 데이터를 활용해보는 것은 실패했다. 데이터를 어떻게 사용할 지에 대한 연습은 여러 방면으로 시도해보는 것이 필요할 것 같다!