GraphQL VS REST

bbio3o·2021년 5월 31일
1

GraphQL

목록 보기
1/1

GraphQL

Graph Query Language
GraphQL 은 단하나의 Endpoint 가 존재합니다.
또한 , gql API 에서는 불러오는 데이터의 종류를 쿼리 조합을 통해서 결정합니다.

Endpoint 는 1개만 생성하고 클라이언트에게 필요한 데이터는 클라이언트가 직접 쿼리작성 , 호출하여 반환받습니다.

✨ 장점

  • No over/under fetching 오버패칭, 언더패칭 해결
    필요한 정보보다 더 많은 데이터 전달받는 것, 불필요한 리소스 낭비 발생, 필요한 정보만 골라내는 추가 작업 발생(오버 패칭)
    필요한 데이터를 만들기 위해 여러 번의 호출이 필요, 추가적인 리소스 요청이 발생, 여러 요청을 통해 전달 받은 정보를 조합하는 추가 작업이 발생(언더 패칭)
  • Don't have to version an api 버전 신경 쓸 필요 없음
    -> api.example.com/v1/posts
    api.example.com/v2/posts(REST api에서는 이런식으로 버전을 따로 다루었음)
    GraphQL을 이용하면 이전 버전을 사용하는 클라이언트에게 영향가지 않고, 새버전 손쉽게 업데이트 가능
  • It's a type system
    -> self documenting, caches silly error, tooling 등을 통해 시간절약 가능
  • REST의 엔드포인트 관리 어려움 해결
    클라이언트에 변경 사항이 생기면 매번 새로운 endpoint를 만들어야 하는 비유연성을 해결

💩 단점

  • 데이터를 효율적으로 fetch하기 어려움
    dataloader 같은 도구의 도움 필요할 수 있음
    prisma/hasura/postgraphille/appsync/etc
    GraphQL의 요청은 복잡하지만 응답받은 데이터는 효율적
    Rest의 경우 요청은 간단하지만 응답받은 데이터가 비효율적
  • Harder to cache and rate limit
  • 모니터링 어려움
    -> 하나의 endpoint를 가지고 있는 graphql에서는 resolver가 중첩된 형태로 존재하기에 어떤 데이터 쿼리가 가져 오는데 오래걸리는지 등의 모니터링이 어려울 수 있다. Apollo engine, tracing 등을 사용할 수 있지만 성능 문제 있을 수 있음
  • 프론트엔드에서 graphql을 사용함으로써 많은 시간을 줄일 수 있었지만, 백엔드 설정이 어렵다.(백엔드에 능숙하지 않다면 툴의 도움을 받을 수 있다.)
  • 파일 업로드 문제

출처1 출처2 출처3

graphql과 apollo를 통해 flux 아키텍쳐(vuex, redux) 대체가능한가?

Redux는 REST API를 사용하기 때문에 리소스의 크기가 서버에서 결정된다. 데이터 교환이 복잡하게 이루어지고, 엔드포인트 증가 및 overfetching과 underfetching 등의 문제점을 가지고 있다. 반면에 Apollo Client는 GraphQL을 기반으로 한다. 서버에서는 어떠한 자원을 사용할 수 있는지 정의하고, 클라이언트에서 렌더링에 필요한 데이터를 요청하는 방식이다. 꼭 필요한 데이터 교환이 이루어지기 때문에 매우 깔끔하며 효과적이다.

하지만 두 방법 중 어느 것이 더 좋다고 단정 지어 말하기는 어렵다. 최신 기술을 적용하기 전에 서비스의 방향성 및 개발 환경에 따라 어느 한쪽 또는 양쪽 모두를 사용할 수 있기 때문이다.

GraphQL의 Operation Type

  • Query -> 데이터 조회
    쿼리 한번에 여러 종류의 데이터를 받아올 수 있음
query lifts {
  allLifts {
    name
    status
  }
}

query trails {
  allTrails {
    name
    difficulty
  }
}


// 한번에 모두 받아오기
query liftsAndTrails {
 liftCount(status: OPEN)
  allLifts {
    name,
    status
  }
  allTrails {
    name, 
    difficulty
  }
}

  • Mutation -> 데이터 수정
// 데이터 생성
mutation createSong {
  addSong(title:"No Scrubs", numberOne: true, performerName: "TLC") {
    id
    title
    numberOne
  }
}

// 데이터 변경
mutation closeLift {
  setLiftStatus(id: "jazz-cat", status: CLOSED) {
    name,
    status
  }
}

  • Subscription -> 주로 실시간 애플리케이션 구현을 위해 사용 ex) 실시간 좋아요 수 업데이트
subscription {
  liftStatusChange {
      name,
      capacity,
      status
   }
}

// 아래 뮤테이션으로 리프트 상태를 바꾸면 서브스크립션에서 대상 데이터의 변경내용을 포착함
mutation closeLift {
  setLiftStatus(id: "astra-express", ststus: HOLD) {
    name
    status
  }
}
profile
그림도 그리는 개발자 🎨👩‍💻

0개의 댓글