GraphQL

Restful Api history

우리 모두가 Restful Api 구조에 익숙하다. 가장 단순하고 이해하기 좋은 형태로 되어 있어, 나같은 초심자에게 큰 위안을 준다. 하지만 Api가 복잡해 질 수록 몇가지 문제에 직면한다.

• Restful한 요청은 기본적으로 단일 요청 단일 응답으로, 데이터를 통한 UI구현이 필요할 때 계속해서 요청해야 한다.
• 데이터가 필요한 곳에서 계속 요청해야 했던 부분을 해결해왔던 방법은 이하와 같다.
  • React State로 데이터를 담은 뒤 Prop으로 전송. ( 서버 요청을 절약할 수 있지만 여전히 데이터 요청이 수동적이고 리소스를 계속 소모할 수 있는 옵션이다. )
  • Recoil Selector 등을 이용하여 데이터 요청 코드를 한 곳으로 줄이고, 응답된 데이터를 전역화 하여 관리한다. ( 강력한 솔루션이 아니다. 여전한 성능 문제... )
  • React-Query를 이용하여 데이터 캐싱 설정을 활성화 한다. ( 제법 좋은 대안이 된다. GraphQL과 비교해보면 러닝커브가 낮은 편이고, 크고 복잡한 프로덕트가 아니라면 이 정도가 적당할 것 같다.)
  • NextJS의 fetch()를 사용하면 응답받은 데이터의 자동 캐싱이 이루어진다. ( ReactJS를 고집해야 하는 환경이 아니라면 유효하다. )

then... why GraphQL?

1. Restful Api로 서비스를 개발하게 되면, 필연적으로 굉장히 많은 노선을 가진 기차역 선로를 관리하는 것과 아주 똑같은 상황이 된다.
   

2. 물론 여러 옵션을 가용하여 노선이 아주 많은 상태인 기차역의 비용을 줄이고 정상적으로 운행될 수 있도록 설계할 수 있을 것이다.
   2-1. 하지만... GraphQL을 이용한다면? 우리의 기차역은 일종의 자동 효율화 신호등 체계를 도입하게 되고, 반복적인 운행을 하는 노선의 데이터를 static하게 관리할 수도 있을 것이다.

3. GraphQL은 Meta에서 만들어진 일종의 프로그래밍 언어로, 보통 라이브러리를 통해 간결하게 이용되고 있다. 그리고 현재의 1위 주자는 Apollo GraphQL.

그러니까 Apollo.

시작하며...

아직 스스로 개발해 보았던 규모에서는 GraphQL이 필요하진 않았다. React-Query로 리소스가 너무 많이 들어가는 요청 건에 캐싱을 걸어주는 등, 핀 포인트로 리팩토링을 하면 괜찮은 수준이었다고 생각한다. 하지만 만약 내가 개발하는 서비스가 MUSINSA라면? Coupang이라면? 데이터 구조가 엄청나게 복잡하고 데이터베이스의 용량도 가늠하기 어려울 것이며, 일일 MAU만큼 데이터 요청이 있게 될 것이다. 그런 프로젝트에서 캐싱을 제대로 안 하면, 일단 서비스 비용으로 비지니스가 박살이 날 것이고, 서버가 견디지 못 할 수도 있으며, 그 전에 클라이언트에서 끔찍한 UX로 사용자가 이탈될 수도 있을 것이다. 그러니까, GraphQL을 배우는 것은 뻔히 일어날 일을 대비할 수 있는 예방 차원의 일을 하는 것이다. 폭스바겐 골프 중고차를 사면, 구동계를 한 번 예방정비 차원으로 갈아치워야 하는 것처럼...