'Graphql'을 선택한 이유

이번 프로젝트를 시작하기에 앞서 graphql에 접하게 되었다.

하는방법이나 연습은 Nomad Coders와 howtographql를 통해 쉽게 접할 수 있었다.

 

지금까지 REST API로 작업하면서 느꼈던 불편함들을 graphql을 통해 해소할 수 있었으며,

코드의 간결함, 보기쉽고 백과 프론트가 주고받기 쉬움 등 여러 장점이 있었다.

내가 느낀 장점과 해외사이트에서 소개한 장점들을 설명하면서

Graphql이 왜 주목을 받는지 정리를 해볼 예정이다.

---

일단 'Graphql'은 Fackbook에서 만든 오픈소스 쿼리언어입니다.

현재 전 세계에 있는 대기업 및 개인커뮤니티에서 관리를 하며 빠른 성장세를 유지하고 있습니다.

오랫동안 유지해오던 REST API의 대안으로 나온 Graphql이 이토록 무서운 성장을 할 수 있던 이유는 

REST API가 가지고 있던 여러 불편함들을 해소시켜주기 때문입니다.

REST를 설계방식에서 어려움을 겪고 있는 요소 3가지를 말씀드리겠습니다.

 

1. 모바일 사용량이 증가함에 따라 효율적인 데이터 로드가 필요합니다.

Facebook은 모바일 사용자가 증가함에 따라 네트워크를 통해 전송이 되는 테이더의 양을 최소화하여

REST보다 훨씬 효율적인 방법을 모색했습니다.

 

2. 다양한 Front End frameworks 및 플랫폼

클라이언트 애플리케이션을 실행하는 프론트엔드 프레임워크 및 플랫폼이 다양함에 따라

모든 요구 사항에 맞는 하나의 API를 구축하고유지 및 관리하기란 쉽지 않습니다.

GraphQL을 통해 각 클라이언트는 필요한 데이터에 정확하게 액세스 할 수 있습니다.

 

 

3. 빠른 기능 개발을위한 빠른 개발 및 기대

빠르고, 지속적으로 사이트를 업데이트하고, 배포하는 것은 필수적인 사항입니다.

REST API를 사용하면 클라이언트 측의 특정 요구 사항 및 설계 변경을 고려하여

서버에서 데이터를 노출하는 방식을 수정해야하는 경우가 많습니다.

이는 빠른 개발과 업데이트를 방해합니다.

 

---

Graphql의 장점을 하나하나씩 알아보겠습니다.

 

1. overfetching과 underfetching 방지

 

REST API를 활용하면 여러 엔드포인트가 발생할 수 있습니다.

인스타그램을 예로 들어 본인페이지에서 불러오는 것들을 간단하게 설명하겠습니다.

 

하나. /user/id 를 통해 본인의 개인정보를 가져와야합니다.

둘.   /user/id/posts 를 통해 자신의 게시물들을 가져와야합니다.

셋.   /user/id/followers 를 통해 사용자의 팔로워수 및 정보를 가져와야합니다.

 

벌써 3 곳의 엔드포인트를 통해서 많은 데이터들을 가져오게 됩니다. (underfetching 발생)

또한, 위 엔드포인트들을 통해 불필요한 많은 정보들도 포함되어 가져오게 됩니다. (overfetching 발생)

 

아래 그림들로 비교를 해보겠습니다.

REST API를 통한 통신

Graphql을 통한 통신

위처럼 Graphql는 구체적인 요구사항을 포함시킨 하나의 쿼리를 Graphql 서버로 보내기만 하면 됩니다.

그렇게 되면, 서버에선 그에 맞는 데이터들을 JSON 형식으로 전달해주게 됩니다.

 

이건 개발할 때에 엄청난 효율성을 보장하는 동시에 클라이언트에서도 원하는 정보들만을

받을 수 있기 때문에 네트워크의 지연이 현저히 적어지게 됩니다.

 

2. 프론트엔드 개발자 환경 업그레이드

Graphql 프론트엔드 라이브러리를 통해 캐싱, 실시간, ui업데이트와 같은 기능들을

기본적으로 무료로 쉽게 이용할 수 있게 되었습니다.

또한 Graphql의 유연성 덕분에 서버에 대한 추가 작업을 진행하지 않고서,

클라이언트에서 변경이 가능하게 되었습니다.

클라이언트는 정확한 데이터 요구 사항을 지정할 수 있으므로 프론트 엔드에서

설계 및 데이터가 변경 될 때에 백엔드 개발자가 조정할 필요가 없게 되었습니다.

 

3. 스키마 정의

개발을 하기에 앞서 graphql 스키마를 작성하게 될 것입니다.

스키마를 작성해두게 되면, 이는 기존 API문서와 같은 역할을 하게 됩니다.

이렇게 작성된 스키마를 보게 되면 백엔드 개발자는 어떤 정보를 전해주어야 하는지

프론트엔드 개발자는 어떤 정보를 인터페이스에 정의를 할 것인지 파악하기에 아주 유용합니다.

이 덕분에 둘간의 소통이 더욱 원활하게 될 것이며 서로를 파악하는 시간이 많이 단축이 될 것입니다.

---

아직 연습만 해보고 직접 프로젝트에 적용하기도 전이지만, REST API의 단점을 보안한 것들이 많이 보였습니다.

물론, Graphql의 단점들도 있지만 일단은 현재 주목을 받고 있는 graphql을 해보면서 장점들을 위주로

파악을 하고, 불편한 점들은 따로 배우고 정리할 예정입니다.

 

이와 같이 사용하기 좋은 prisma orm에 대해서도 현재 알아보고 있는 중이며,

최대한 같이 활용해서 사용해보는 쪽으로 프로젝트를 진행해보겠습니다.

 

 

참고사이트1

참고사이트2