GraphQL을 알아보자

보람찬하루·2024년 4월 23일

graphql

GraphQL

목록 보기

1/1

Intro

나는 Spring을 배우면서 REST API를 설계하고 개발해왔다. 왜 REST API냐 하면 제일 많이 사용되니까? 라고 답했지만 나도 흠..왜 REST API를 사용할까? 하는 생각은 지울 수 없었다.

그런 나에게 기회가 되어 SOPT에서 GraphQL 스터디가 열려서 참여하게 되었다! 이름도 처음 들어봤지만 차근차근 알아보도록 하자!

GraphQL이란?

페이스북에서 REST API의 한계를 극복하기 위해 만든 API 를 위한 쿼리 언어라고 할 수 있다.

왜 만들었을까요?

REST API의 한계를 극복하기 위해서 만들었는데 어떤 한계를 어떻게 극복했는지 알아보자.

✔️ Overfetching

REST API는 일부 데이터만 필요하다고 해도 resource의 전체 데이터를 불러와야하고, 프로젝트의 규모가 커지고 방대한 데이터를 다루게 되면 성능 이슈가 발생할 수 있다.

GQL을 사용하면 필요한 필드만 명시적으로 요청할 수 있기 때문에 HTTP 응답 사이즈를 최소화해서 모바일 환경에서의 부담을 줄일 수 있습니다.

✔️ Underfetching

REST API에서는 특정 데이터를 얻기 위해 여러 개의 엔드포인트를 통해 데이터를 요청 해야하는 상황이 있는데 (실제로 내가 진행하는 프로젝트에서도 한 뷰 안에서 여러 api가 호출된다) 네트워크가 좋지 않은 환경에서 여러 개의 API를 호출하게 되면 느려질 수 있고 이는 사용자에게 안좋은 인상을 줄 수 있다.

GQL에서는 필요한 데이터 구조를 정의할 수 있기 때문에 하나의 쿼리로 원하는 여러 데이터들을 한 번에 불러올 수 있다

✔️ 고정 구조 데이터 교환

REST API는 클라이언트 요청이 고정된 구조를 따라야 리소스를 수신할 수 있다. 이 엄격한 구조는 사용하기 쉽지만 필요한 데이터를 교환하는데 가장 효율적인 방법은 아니다. 밑에서 더 자세히 알아보자.

뭐가 다를까요?

vs SQL

우선 쿼리 언어하면 제일 먼저 떠오르는 SQL과 비교를 해보자. 둘은 목적에서부터 차이가 존재한다. GQL은 웹 클라이언트가 데이터를 서버로부터 효율적으로 가져오는 것이 목적인 쿼리 언어이고,

SQL 은 데이터베이스 시스템에 저장된 데이터를 효율적으로 가져오는 것이 목적인 쿼리 언어이다. 또한 GQL은 타입 시스템을 사용하여 쿼리를 실행하는 서버사이드 런타임이고 특정 DB나 플랫폼에 종속적이지 않다.

vs REST API

Method와 End Point

Rest API는 HTTP 요청방식 (GET, POST, PUT DELETE 등)을 사용하여 데이터를 요청하고 응답받는 상황에 따라 다른 Method를 사용해야하고 api별로 각각의 end point를 갖는다.

GQL은 동일하게 HTTP 요청방식을 사용하지만 POST만 사용하고 단일 end point(/graphql)를 사용하며 요청 시 body에 Schema에 맞춰 Query를 사용하여 요청하기 때문에 일관성 있는 통신이 가능하다.
Response데이터

Rest API의 경우 return 되는 response 데이터가 정해져 있다. 그렇게 때문에 API 응답에 다른 컬럼들이 추가되면 해당 파일을 계속 수정해줘야하고 DTO를 각각 만들어줘야한다. ~~실제로 지금 진행하는 프로젝트에서 점점 response에 하나씩 값이 추가되고 있어서 중복 코드가 포함된 DTO가 늘어나고 있다…~~

GQL 쿼리로 요청하기 때문에 클라이언트가 원하는 데이터를 뽑아 커스터마이징 해서 사용이 가능하다.
```
Rest API

class BookDTO {
	Long id;
    String title;
}

class BookDTO2 {
	Long id;
    String title;
    String content;
}
```
```
GraphQL

query {
  getBook(id: "1") {
    title
    content
  }
}
```

GraphQL 무조건 사용해야하나요?

Rest API의 단점과 능동적인 개발이 가능한 GraphQL을 생각해보면 도입 시 훨씬 효율적으로 개발이 가능하다고 느껴질 수 있지만 GraphQL의 도입 여부는 신중하게 검토해야 한다. GQL 또한 단점이 존재하기 때문이다.

GraphGQL의 단점

요청이 3천건이 넘어가면 REST보다 성능이 떨어진다.
단일 End Point와 공개된 스키마로 인한 보안의 위협이 존재한다.
HTTP 내장 캐시 기능을 활용하기 어렵다

도입 전 고민해볼 체크 리스트

우리가 만드는 서비스는 얼마나 크고 복잡한가?
요청하는 데이터의 형태가 얼마나 다양한가?
데이터 요청 횟수는 얼마나 많은가?
우리의 서버 아키텍처는 GraphQL을 도입하기 적절한가?
만들고자 하는 서비스가 자원 통신에 집중해야 하는 것이 아닌 화면 구현에 집중해야하는가?
- 자원 통신에 집중하는 서비스 : UI를 그릴 필요가 없는경우 ex) 구글맵 연동..
- 화면 구현에 집중하는 서비스 : 화면을 그리는데 많은 데이터들을 필요로 하는 서비스