본문 바로가기
  • 분조장의 개발 블로그
GraphQL

GraphQL 사용하면서 느낀 장단점(+ Spring Boot)

by 무아니 2021. 5. 17.

GraphQL이란?

Facebook에서 개발한 Api를 위한 쿼리 언어다. Api에 있는 데이터에 대해 이해하기 쉬운 설명을 제공하고 client에게 필요한 것을 정확하게 요청할 수 있는 기능을 제공한다.

 

장점

  • Rest Api의 단점인 Underfetching, Overfetching 해결 가능
    • Underfetching
      • 기존의 Rest Api에선 다른 두 세개의 api들을 호출해야 얻을 수 있는 정보가 있으면 필요한 만큼 api를 호출하고 추가적으로 가공해야했다.
      • GraphQL에선 한 번의 호출로 원하는 데이터를 얻을 수 있게 된다.
    • Overfetching
      • 기존의 Rest Api에선 api 호출 시 필요 이상의 정보를 전달받는 문제가 있었다.
      • GraphQL은 client에서 필요한 데이터만을 요청하므로 overfetching이 해결 된다.
    • Endpoint
      • Rest Api는 각 api마다 다른 endpoint가 있어서 이름을 짓거나 관련성이 있는 것들끼리 묶는 등의 관리가 어렵다.
      • GraphQL은 단 하나의 endpoint가 있어서 요청 주소가 매우 간단해진다.
    • 여기서 성능적으로 이득을 보려면 가능한 한번에 정보를 다 받아놓고 작업을 수행하는 방식인가?
  • api 요청 데이터 구조 에 대한 문서가 자동으로 시각적으로 만들어지므로 client에서 참고할 수 있다.

 

단점

  • Spring boot와 쓰면 아쉬운 점1 (응답/요청 객체 생성)
    • GraphQL 스키마에서 필드 상속&생략 가능 할 수 있으면 좋을텐데.. dto에선 java로 필드 상속해서 생략해도, Graphql스키마에선 필드 다 적어줘야해서 비효율적이다.
      (GraphQL에 중복되는 필드를 생략할 수 있는 문법은 없다.)
    • 이젠 java로 dto 잘 만들고 + Graphql로 스키마 효율적으로 작성하는 방법까지 생각해야한다.
    • request/response 로 Map, Object을 사용하지 못한다.(Scalar 타입으로 인식하기 때문)
    • 그래서 단 하나의 필드만 담고 있어도 모든 응답을 dto객체로 만들어야한다.
    • 현재 객체를 포함해 필드를 하나 추가할 때 아예 새로운 객체를 만들어줘야한다.(dto 특징)
예시) 모든 dto에 "foo" 필드 하나 추가해달라는 요청사항이 생긴다.
(1) 새로운 dto 객체 만들어서 foo포함한 필드 구성
(2) 스키마에도 새로운 타입 만들어서 -> 쿼리문에 새로운 타입으로 적용
모든 dto에 수작업으로 적용
  • Spring boot와 쓰면 아쉬운 점2 (파일 업로드)
    • 파일 업로드에 사용되는 MultipartFile 객체를 사용하지 못하고(kickstart 라이브러리 필요), 쿼리문 요청 시 variables 문법을 추가 작성해야 한다.
    • kickstart를 사용하면 java소스에선 파일 업로드용 객체 대신 DataFetchingEnvironment 라는 객체를 사용하고 GraphQL 스키마에선 이를 생략하면 돼서 깔끔하지만,  동시에 여전히 사진 등의 파일까지 input 데이터로 스키마에 표시되진 않아 아쉽다. (GraphQL의 장점 하나가 적용되지 않는 부분이다)
  • client 쪽에서 아쉬울 수 있는 점
    • client에서 조회 요청시 필요한 모든 필드를 작성해야 한다. 이게 생각보다 번거롭다.
    • 사용하는 문법이 생각보다 한정적이다.
      (서버가 Spring boot와 같이 쓰여서인지, 아직 스키마 최적화 작업이 이뤄지지 않아서 그런지 모르겠지만... 그런데 스키마에서 interface, type은 분리돼서 보이니까 client팀은 오히려 더 깔끔하게 생각하실지도?)
      • 거의 모든 타입이 Long, Int, String이다.
      • ID, Date(커스터마이징 필요), Enum(문자열로 반환 중), Interface, Union 는 사용하지 않는다.
      • ! 도 사용하긴 하는데 약속하고 사용하진 않는다.
      • 아직은 서버쪽에서 거기까지 생각하기엔 복잡한 것 같다.
    • 요청을 효율적으로 하기위해 client 쪽에서도 GraphQL문법을 공부하고 적절한 방법을 연구해야한다.
      • variable 문법을 사용해서 확장성 있는 쿼리문을 생성한다던지
      • 응답 객체들 중 interface로 묶어줬으면 좋겠는 것이 있다면 서버팀에 요청한다던지..

'GraphQL' 카테고리의 다른 글

Spring Boot서버에서 GraphQL요청 처리하기  (0) 2021.05.17
Spring Boot에서 GraphQLResolver<T> 사용하기  (0) 2021.05.17
GraphQL 명명 Convention  (0) 2021.05.17

댓글