GraphQL Basic

이지·2021년 1월 18일

⁇ GraphQL 을 사용하는 이유 ⁇

1. graphQL API 는 강력한 스키마 타입을 가지고 있습니다.

GrqphQL 에 스키마 는 모든 GraphQL API 의 중추입니다. 입력 인수 및 가능한 응답을 포함하여 API가 지원 하는 작업 ( 쿼리 , 돌연변이 및 구독 )을 명확하게 정의합니다 .

강력한 유형 시스템 덕분에 개발자는 스키마가 없는 API로는 상상할 수없는 많은 이점을 얻고 있습니다. 예를 들어, 빌드 툴링을 활용하여 API 요청을 확인하고 컴파일 타임에 API와 통신 할 때 발생할 수있는 오류를 확인할 수 있습니다. 또한 편집기에서 API 작업을 자동 완성 ****할 수도 있습니다!

스키마의 또 다른 이점은 개발자가 더 이상 수동으로 API 설명서를 작성할 필요가 없으며 대신 API를 정의하는 스키마를 기반으로 자동 생성 될 수 있다는 것 입니다. 이는 API 개발에 판도을 바꿔 놓았습니다!

2. 더 이상 `overfetching` 과 `underfetching` 은 없습니다.

클라이언트는 API가 반환 한 응답 객체의 형태를 지시 할 수 있습니다.이는 REST API에서 일반적으로 발생하는 두 가지 문제인 overfetching 과 underfetching 를 해결 합니다.

overfetching: 클라이언트가 실제로 페치 할 때 필요하지 않은 데이터를 검색 하는 것을 의미합니다.(더 많은 데이터를 다운로드하고 parsing 하는 데 더 오래 걸리게 됩니다.) 따라서 앱의 성능이 떨어지고 사용자의 데이터 소비 계획도 망가집니다.
underfetching: 오버 페치와 반대이며 API 응답에 충분한 데이터가 포함되어 있지 않음을 의미합니다. 이는 클라이언트가 현재 데이터 요구 사항을 충족시키기 위해 추가 API 요청을해야 합니다. 최악의 경우, 이로 인해 악명 높은 N + 1 요청 문제가 발생합니다. 이것은 클라이언트가 필요로 하는 정보에 대해 n 개의 요청을 필요로 하는 상황입니다. 클라이언트는 필요한 정보를 받아오기 위해 요소 당 하나의 요청을 해야합니다.

3. graphQL 은 빠르게 프로덕트를 개발할 수 있게 합니다.

프론트 엔드 개발자는 GraphQL 클라이언트 라이브러리 (예 : Apollo , Relay 또는 Urql ) 덕분에 기본적으로 chaching , realtime 또는 optimistic UI updates 를 자유롭게 (그래프가 아닌 경우 전체 팀이 작업 해야하는 영역입니다.) 이용할 수 있습니다.

프론트 엔드 개발자의 생산성 향상은 제품 개발 속도를 향상시킵니다. GraphQL을 사용하면 백엔드를 터치하지 않고도 앱의 UI를 완전히 다시 디자인 할 수 있습니다.

4.graphQL API 의 구성 방식

스키마 스티칭 아이디어 는 GraphQL 공간에서 가장 새로운 아이디어 중 하나입니다. 즉, 스키마 스티칭을 사용하면 여러 GraphQL API 를 결합하고 연결 하여 단일 API 로 병합 할 수 있습니다. React 컴포넌트를 기존 컴포넌트로 구성하는 방법과 유사하게 GraphQL API를 기존 GraphQL API로 구성 할 수도 있습니다!

이는 여러 GraphQL 엔드 포인트와 통신해야하는 클라이언트 애플리케이션 (마이크로 서비스 아키텍처에서 발생하거나 GitHub, Yelp 또는 Shopify와 같은 타사 API와 통합 할 때)에 매우 유용합니다. 스키마 스티칭 덕분에 클라이언트는 단일 API 엔드 포인트 만 처리하며 다양한 서비스와의 통신을 조정하는 모든 복잡성은 클라이언트에서 숨겨집니다.

GraphQL 바인딩을 통해 GraphQL API 재사용 및 구성-GraphQL 바인딩하면 기존 GraphQL API를 GraphQL 서버에 내장 할 수 있습니다.

5. 많은 오픈소스 생태계와 놀라운 커뮤니티

오늘 날, GraphQL은 많은 큰 기술 회사의 생산에 사용됩니다. GraphQL 로 구현 할 수있는 다양한 언어 가 존재하고 많은 클라이언트 또한 제공합니다. 또한 Prisma , GraphQL Faker , GraphQL Playground , graphql-config 등과 같은 많은 툴들을 통해서 원활한 워크 플로우를 제공하고 GraphQL API를 빌드 할 때 놀라운 개발자 경험을 제공합니다.

⁉️ 기존 엔드포인트에 graphQL을 적용할 수 있다?

기존 REST로 구현된 API는 GET /contents, POST /contents, DELETE /contents/:contentsId, GET /posts, DELETE /posts/:postId 같은 방식으로 개발되어 있었고, 이 구조를 비슷하게 유지하면서도 GraphQL로 바꿀 수 있을 거라고 생각했다. 물론 그렇게 하는 것이 불가능한 것은 아니다. 하지만 GraphQL은 단일 엔드포인트를 권장하고 있었다. 모든 요청을 /graphql 한 곳에서 처리하는 것이다.

REST가 URL과 Resource를 매칭시키는 개념적 모델을 사용했기 때문에 수많은 엔드포인트를 사용했다면, GraphQL의 개념적 모델은 모든 리소스가 그래프처럼 서로 연결되어있기 때문에 URL을 분리할 필요가 없다. 서버는 리소스를 가져오는 명령어(Query), 혹은 어떤 리소스를 변경하기 위한 명령어(Mutation)만 제공하면 된다. GraphQL에서 필요로 하는 엔드포인트는 Query Language 입력을 받기 위한 하나의 창구로 충분하다. GraphQL의 핵심은, 리소스를 url이 아니라 Query를 통해 표현하는 것이다.

그렇다면 다른 관점에서, 기존에 사용하던 REST와 GraphQL을 같이 사용할 수는 없을까?

아주 간단하다. 기존 REST API는 그대로 놔두고, /graphql 엔드포인트만 새로 만들면 된다.

⁉️ GraphQL은 MySQL과 어울리는가?

GraphQL에서는 MySQL과 은 DB에서 성능의 중요한 키가 되는 JOIN명령어를 거의 사용하지 않기 때문에 성능상의 이득을 얻을 수 없을 것이고, 때문에 RDB와 GraphQL은 어울리지 않을거라고 예상했었다. 차라리 MongoDB같은 NoSQL DB가 GraphQL과 더 어울리는게 아닐까? 사실 GraphQL과 RDB의 관계는 나쁘지 않다. DB에서의 테이블과 같은 표현이 결국 GraphQL의 엔티티로 그대로 매칭될 수 있기 때문이다

GraphQL의 장점은 클라이언트의 요청에 따라 데이터를 더 가져오거나 가져오지 않거나가 결정된다는 점이다. 서버 개발자가 결정하는 것은 엔티티 사이의 관계, 그리고 그 관계에 따라 데이터를 어떻게 가져올 지 뿐이다(같은 댓글 목록을 가져오더라도, post.comments와 user.comments, comments.comments일 때를 각각 구현한다). 만약 REST API에서 같은 리소스를 표현하면서도 성능상의 문제로 JOIN을 많이 하는 API와 덜 하는 API를 나눠서 구현했었다면, GraphQL을 사용한 경우 이런 고민을 서버에서는 더이상 하지 않게 된다. 클라이언트가 각자 자신의 상황에 맞게 (데스크톱/모바일 등) 적절한 Depth로 요청을 끊어서 처리할 수 있게 되었기 때문이다.

(출처: graphql을 오해하다)