GraphQL을 다들 쓰길래 제가 한번 알아봤습니다...

2019. 11. 16. 23:47Web

 

 

이 글은 제가 GraphQL을 사용해보고자 며칠 간의 삽질 결과 내린 결론을 정리해보고자 하는 글입니다.

 

GraphQL을 시작할 때 많이들 사용되는 Back-End 단 프레임워크로 Apollo와 Yoga 그리고 Prisma가 많이 언급됩니다.

오늘은 GraphQL에 대해서만 언급하고 ApolloYoga 그리고 최종적으로 Prisma까지 언급해볼 예정입니다.

왜냐면 제가 Prisma를 사용하니까요...

 

 

 

 

 

GraphQL?


GraphQLAPI를 위한 쿼리 언어이며 이미 존재하는 데이터로 쿼리를 수행하기 위한 런타임입니다. GraphQL은 API에 있는 데이터에 대한 완벽하고 이해하기 쉬운 설명을 제공하고 클라이언트에게 필요한 것을 정확하게 요청할 수 있는 기능을 제공하며 시간이 지남에 따라 API를 쉽게 진화시키고 강력한 개발자 도구를 지원합니다.

 

라고 공식 홈페이지에 작성되어 있습니다. 더 자연스럽게 표현을 해보자면

Database Scheme를 알고 있다는 전제하에, JSON으로 데이터를 요청하면 JSON으로 결과를 반환해줍니다.

 

공식 페이지를 인용해서 더 쉽게 표현을 해보자면 클라이언트가

* GraphQL을 사용하면

GraphQL KR(https://graphql-kr.github.io/)

 

* SQL을 사용하면

# Requests
select tagline from Project where name='GraphQL';


# Result:
"A query language for APIS"

??? 사실 이것만 보면 저는 도대체 GraphQL을 왜 써야 하나 싶었습니다.

 

 

ql(query language)은 사용(데이터를 요청)하는 측면이 다르다고 하는데,

 

기존 Database에서 SQL 요청은 Back-End에서 처리하는 역할이었으니,

Front-end에서 GraphQL Client를 사용하여 GraphQL Server에 요청을 해야 하는 과정이 발생합니다.

이로 인해 러닝 커브(학습 시간/비용)가 발생되죠.

 

 

 

 

장점


그래서 GraphQL의 장점이 뭘까? 라고 생각이 들더군요.

 

 

 

 

REST API를 사용할 때 정의되던, 각 CRUD에 요청이 GraphQL에서는 단 하나의 EndPoint에서 일어납니다.

 

(https://devopedia.org/graphql)

Rest API의 경우 각 URL별 행위가 다르며, Method 마다도 행위가 다릅니다.

반면에 GraphQL은 하나의 Endpoint를 통해 요청하는 쿼리로 결과가 달라집니다.

 

그 외에도 네트워킹 퍼포먼스에서도 우위를 점하고 있고

요즘에는 둘을 같이 쓰는 혼종 방법도 존재하는데 제가 아직 그 단계는 흠흠..

 

또한 Query에 요청에따라 결과가 달라지니 더이상 API에대한 Version 관리가 필요없어집니다.

이점이 가장 맘에드네요

 

 

단점


그럼 마찬가지로 단점은 뭘까?!

하고 찾아보았는데 의외로 단순했습니다.

 

 

  • 쿼리의 복잡성
    (
        SQL의 퍼포먼스와 같습니다.
        병목현상과, 퍼포먼스 그리고 재귀적 호출 등은 과도한 트래픽 유발 문제가 될 수 있습니다.
    )
  • 트래픽 과부하 방지
    (
        Rest API를 제공하여 수입을 내는 회사나 여타 회사들은 과도한 요청으로 인해 발생되는 트래픽이나 요금을
        마냥 좋아하지 않습니다. 낭비가 될 터이니 이러한 누수방지를 위해 요청의 따른 제한을 둬야 하며
        대표적으로 인스타그램은 200번의 요청을 제한으로 두고 있습니다.
    )
  • 캐싱
    (
        Rest API는 특정 URL을 기준으로 쉽게 캐싱을 제공할 수 있는 반면,
        GraphQL은 한 가지의 EndPoint를 통해 요청 쿼리에 따른 다른 결과를 반환하여, 캐싱이 복잡합니다.
    )

각 모든 단점들은 서로 얽혀있는 문제이며, 캐싱의 경우 Apollo 등의 서비스를 이용하여 해결할 수 있습니다.

 

 

 

 

 

도입부


GraphQL을 도입하면 Front-end 개발자는 다음 기술이 필수적 이게 되며,

  • Database Scheme
  • GraphQL (Client)

 

Back-End 개발자 또한 다음 기술이 필수적이 됩니다.

  • GraphQL (Server)
  • Resolver
  • Database Scheme
  • Mutation
  • Subscription

 

 

 

 

공통적으로 Database Scheme는 Kakao Tech에서는 다음과 같이 정의합니다.

 

Kakao Tech - GraphQL(https://tech.kakao.com/2019/08/01/graphql-basic/)

 

 

 

 

Scheme를 이론적으로 살펴보면 뭐... 외부, 내부, 개념 등 복잡하게 이해에 어려움을 주는 경우가 많은데

진짜 간단하게 이해를 위해서는 nittaku님의 게시글을 참고하시면 이해가 쉽습니다.

https://nittaku.tistory.com/384

 

3. MySQL의 구조 / 접속 / schema 사용 / table 생성 / 비밀번호 변경 / datatype 일부설명

MySQL 구조 SQL은 최종적으로는 table가 완성된다. 댓글, 게시판 등등 다양한 table가 완성된다. 연관된 table를 모은 것이 database = schema이다. 연관된 table을 모은 schema를, 모은 것이 database server이다..

nittaku.tistory.com

 

 

GraphQL이 도입되면 Front-End는 Back-End에게 스키마 정보만 알아내면

 

Back-End에서 GraphQL-Server를 배포하여

Front-End에서 직접 GraphQL 쿼리를 GraphQL-Server로 요청해서

데이터를 직접 읽고(Read) 추가(Create)하고 수정(Update)하고 삭제(Delete)를 모두 할 수 있게 됩니다.

 

 

 

결론


 - SQL은 서버 측 요청인 반면, GQL은 클라이언트(프런트엔드)가 요청
 - GraphQL Server와 Client에 관련한 러닝 커브가 존재

 - 요청하는 쿼리에 따라 결과가 달라지며, 하나의 EndPoint(요청 URL)을 가짐
 - 퍼포먼스는 좋으나 배보다 배꼽이 더 커지진 않을까?