#주저리주저리
백엔드 입장에서 REST API를 사용하다보면 정~~~말 비슷비슷한 작업을 수행하는데도 불구하고, 각 플랫폼별로 디자인이 다르고, 같은 플랫폼내에서도 유사한 화면이 많기 때문에 매번 별도의 API로 생성해야하는 일이 다분하다.
이럴때마다 "그냥 프론트에서 필요한 데이터를 가져가면 안되나?"라는 생각이 들었는데, 그게 graphql로 가능하다고 한다!
따라서 이번에는 graphql과 REST API가 어떤 점이 다르기 때문에 이게 가능한건지 기본적인 개념부터 한번 알아보려 한다.
Graphql이란?
Graphql에서 기본적인 개념을 알아보기 위해서는 우선 graphql에서 ql이 무엇인지를 알아야 한다.
REST API에서는 API를 통해 클라이언트와 서버간의 통신을 다루는 반면, graphql에서는 Query Language로 소통한다.
백엔드 개발자라면 다들 알다시피 RDB에 대해 SQL ( Structed Query Language )을 통해 데이터를 조작한다. 이를 프론트엔드, 즉 클라이언트 측에서 query를 날려 DB를 조작하는 개념으로 이해하면 좋을 것 같다.
단, 여기서 gql은 DB에 직접 연결해서 조작하는 것이 아니라, 서버 단의 gql 애플리케이션이 gql을 받아 해당 쿼리문에 해당하는 내용을 처리한 뒤 클라이언트에 반환해주는 형태로 구성된다.
즉, graphql은 API Endpoint로 처리되는 것이 아니기 때문에, gql 애플리케이션에 해당하는 Endpoint 하나로 통일되며 각 데이터 혹은 처리 방식은 Endpoint가 아닌 query에 의해 결정된다.
여기서 발생하는 추가적인 장점은 크게 두가지가 있다.
첫번째, Endpoint는 하나로 관리되고, 서버에 정의된 스키마의 실시간 정보를 공유받을 수 있는 인트로스펙션이 graphql에서 제공되기 때문에 별도로 API 명세서를 최신화하고 요구할 필요가 없으며 오히려 신뢰성 높은 정보를 얻을 수 있다.
두번째, 하나의 Endpoint에서 쿼리로 처리되기 때문에 여러 데이터에 대해 조작이나 조회가 필요할 경우, 한번의 네트워크 호출로 전부 처리가 가능하다. REST API의 경우에는 /posts/1 :GET, /users/1 :GET, /posts/1/comments :GET 과 같은 형태로 여러번의 네트워크 호출이 필요했지만, graphql에서는 쿼리로 이 모든 데이터 요청을 한번에 전달할 수 있는 것이다.
graphql vs REST API
그럼 이제 위의 내용을 정리하고 추가적인 특징을 기반으로 graphql과 REST API의 장단점을 비교해보자
graphql
장점
- 한번의 네트워크 호출로 여러 데이터에 대한 조작이 가능하다. ( Under-Fetching )
- 별도의 API 명세서 작성이 필요없이 인트로스펙션으로 해결이 가능하다. 그에 따라 클라이언트 측에서는 더욱 신뢰도 높은 정보를 얻을 수 있다.
- 최신화가 안돼있나? 잘못된 response 데이터가 적혀있나? 등의 고민이 필요없음 - 백엔드 측에서 프론트엔드에서 필요한 데이터를 예측하거나 추가해서 제공해줄 필요없이, 프론트엔드에서 직접 쿼리로 필요한 데이터를 그때그때 추가하고 빼서 받아오거나 조작할 수 있다. ( Over-Fetching )
- 필요한 만큼만 받아오고, 조작할 수 있어서 불필요한 cost가 줄어든다
단점
- HTTP의 장점을 활용하기 힘들다.
- 엔드포인트가 하나이기 때문에 HTTP 캐싱이 불가능하다. - Response 형태는 JSON만 지원한다.
- 재귀적 쿼리로 인한 성능 저하
- 잘못 요청하거나, 스키마를 잘못 구성하면 재귀적으로 쿼리를 요청하여 성능상의 문제가 발생한다.
REST API
장점
- 별도의 인프라 구축없이 사용이 가능하며, HTTP의 특징을 그대로 끌어다 사용할 수 있다.
- 구조가 명확한 경우 요청에 대한 cost가 graphql에 비해 비교적 적다
- Response 형태가 자유롭다.
단점
- 각 데이터에 대한 CRUD마다 각각의 네트워크 호출이 필요하다.
- 유사한 데이터 조작이 많이 필요한 경우, 별도로 API를 설계하거나 다른 경우에는 불필요한 데이터 및 액션이 추가되어야 한다.
- Swagger 등, 별도의 API 명세서가 필요하다.
마치며
graphql이 뚜렷한 장점이 있긴하지만, graphql에서 분명 처리하기 힘든 부분들도 존재하고 이 부분들을 REST API에서 적절하게 커버할 수 있다는 것을 알 수 있었다.
또한, 두가지 방식 모두 뚜렷한 표준이 없기 때문에 제대로된 개념을 확립하고 서비스에 도입하여야 해당 방식의 장점을 100% 뽑아낼 수 있을 것이다.
