GraphQL 은 문제가 있다... 마음에 들지 않는다...

GraphQL 이 유명세를 타면서 이를 실제로 상업적인 서비스에 적용하는 경우가 많은 것으로 보인다.

그런데 이를 사용하면서 뭐가 이상하게 찜찜하게 이건 아닌데... 하는 생각이 든다.

왜지?

 

...

 

우선 과거의 rest api 와 rest 스러운 api 를 사용하는 경우와 프론트엔드 측인 mobile application 의 모델의 경우를 보자.

이는 GraphQL 과 Rest api 의 장단점에 대한 것은 아니고 과거 관계형 DB 를 사용하는 경우의 rest api 의 응답을 프론트엔드 측의 모델에 어떻게 서로 간의 규약을 정하여 프론트엔드와 백엔드가 각각 최대한 덜 의존적으로 작업을 지속적으로 할 수 있는가에 대한 고찰을 우선적으로 함으로서 주어진 문제에 대해 접근해 나가기 위함이다.

 

만약 rest 스러운 api 를 사용한다면 swagger 를 사용할 것이고 GraphQL 을 사용한다면 Hasura 나 AWS 의 AppSync 같은 솔루션을 사용할 것이다. GraphQL 과 rest 스러운 api 의 실질적 사용성에 대한 고찰을 하게 된 이유는 여러가지를 모두 다 하는 것은 매우 어렵기 때문에 한개만 선택해서 사용하고 싶어서이다.

 

rest 스러운 api 라고 표현하는 이유는 우선적으로 거의 완전한 rest 규약을 따르는 rest api 의 경우 비현실적인 듯 보이고 개발 편의성도 떨어지는 것으로 보여서 기본적인 rest 규약을 베이스로 한 좀 더 자유도 있는 rest 스러운 api 를 선호하기 때문이다. 많은 상업적 서비스에서도 rest 스러운 api 를 사용하고 있다. 대표적으로 dropbox? twitter 도?

 

프론트엔드의 모델은 백엔드의 http request, api enpoint, response 값 등을 swagger 와 같은 서비스를 사용하여 문서화 하여 제공해주면 그 response 의 형태에 따라 정형화 하여 만들어주면 된다. 백엔드 응답의 스네이크 케이스 나 모바일의 파스칼 케이스 필드명을 파싱하거나 nested 된 그리고 동일한 형태를 nesting 하는 경우 등을 고려하여 모델을 구성해주면 된다. 즉, 디자인과 기획이 진행되고 그에 따라 백엔드 측의 DB 설계 및 API 설계가 이루어진 뒤 문서화 하여 프론트엔드에 제공하면 프론트엔드는 그 API 의 응답 형태에 따른 설계를 하면 된다. 과거 nested 되는 형태의 응답을 어떻게 처리해야 하는가에 대한 해법을 명확히 찾지 못하여 고민한 적이 있었다.

 

AWS AppSync 소개 설명글을 가져와 보면 다음과 같다.

조직이 GraphQL 을 사용하여 API 를 구축하는 이유는 프론트엔드 개발자가 단일 GraphQL 엔드포인트로 다수의 데이터베이스 마이크로서비스 및 API 를 쿼리하여 애플리케이션을 더 빠르게 개발할 수 있기 때문입니다.

AWS AppSync 는 AWS DynamoDB, Lambda 및 기타 데이터 원본에 안전하게 연결하는 힘든 작업을 처리하여 GraphQL API 개발을 용이하게 하는 완전관리형 서비스입니다. 성능 개선을 위해 캐시를 추가하는 작업, 실시간 업데이트를 지원하기 위한 구독, 오프라인 클라이언트를 동기화 상태로 유지하는 클라이언트 측 데이터 스토어가 간편하게 처리됩니다. 배포된 후에는 AWS AppSync 가 API 요청 볼륨에 따라 GraphQL API 실행 엔진을 자동으로 확장하고 축소합니다.

 

대표적으로 Query, Mutation, Subscription 세부분의 요청 방식이 있고 WebSocket 과 같은 Subscription 기능까지 기본적으로 제공한다. 또한 응답을 rest api 형식으로 노출시켜줄 수도 있다.

 

rest api 형식으로 노출시켜줄 수 있다는 부분에 대하여 생각해보면 GraphQL 은 관계형 데이터베이스의 관계 정보를 자동적으로 고려하여 기본적인 api 를 만들어주고 또한 커스텀 api 도 만들어 줄 수 있다. 관계형 데이터베이스의 관계 정보 등을 고려하여 정형적인 엄격한 rest api 와 유사하게 엔터티(테이블) 의 관계에 따른 기본적인 GraphQL api 를 제공해준다. 그렇기 때문에 데이터베이스 모델링 된 형태 그 자체로 엔터티(테이블) 와 관계를 바탕으로 도메인이 정의된다. 어떻게 보면 백엔드에 Service 레이어가 없는 형태라고 볼 수 있다. 물론 커스텀한 api 를 만들어서 사용할 수도 있다.

 

아마도 이렇게 데이터베이스의 모델을 바탕으로 정의된 도메인에 따라 자동적으로 만들어져서 제공되어지는 유동적으로 사용할 수 있는 api 들을 통해 왠만한 애플리케이션의 경우 이를 바탕으로 대다수의 CRUD 식의 로직을 만들 수 있기 때문에 아마도 GraphQL 이 더 좋고 편리하다고 생각하는 듯 하다. 또한 GraphQL 을 실제 사용할 경우 AppSync 나 Hasura 같은 솔루션을 사용하는데 그 솔루션에는 여러 마이크로 서비스들을 통합하여 사용할 수 있는 기능들을 제공하기 때문에 백엔드 용 범용적 통합 솔루션으로 사용될 수 있기 때문에 또한 이를 장점으로 생각하기도 하는 듯 하다.

 

하지만...

 

전통적인 백엔드 서비스 구성에 있어 서비스 레이어 라는 부분이 분명이 존재하며 매우 직관적이고 커스텀 가능하고 학습량이 낮다. GraphQL 을 사용하기 위해서는 일반적이지 않은 GraphQL 방식의 사용법을 학습해야 하며 또한 GraphQL 의 경우 이러한 방식을 제공하기 위해 블랙박스 형태의 중간 단계가 존재하기 때문에 오히려 그냥 백엔드 웹애플리케이션을 만들어 서비스레이어를 통해 이러한 부분들을 제공하는 것이 좀 더 커스텀에 용이하고 직관적이며 일반적이다. 마이크로서비스 들의 공통 인증을 위한 토큰 적용방식 이라던가 subscription 또는 이벤트 나 액션 등의 기능 또한 전통적인 비즈니스 서비스 레이어를 가진 웹애플리케이션 방식에서도 충분이 가능하며 더욱더 직관적이고 일반적이고 커스텀이 용이하다.

 

단순히 자동으로 만들어지는 기본적인 도메인과 api 나 subscription, 이벤트, 액션 등의 기능들 때문에 GraphQL 이 좋다고 생각할 수도 있을 수 있다. 또한 어쩌면 백엔드 엔드포인트 통합 관리형 솔루션으로 굉장히 좋은 툴이라고 착각을 할 수도 있게 만들 수 있다.

 

하지만...

 

결국 자동적으로 엄격한 룰에 따라 데이터베이스 모델 그 자체를 바탕으로 자동화된 api 를 만들어주는 마치 엄격한 rest api 같은 그리고 엔드포인트 응답을 유동적으로 제공하기 위해 중간에 GraphQL 방식의 블랙박스 같은 기능을 추가한 것에 불과하다.

 

차라리 비즈니스 서비스레이어를 둔 전통적인 백엔드 개발방식이 더 낫다고 생각한다.

 

아마도 계속 찜찜한 느낌이 들었던 것은 GraphQL 사용법에 대한 높은 학습량과 GraphQL 방식을 위한 블랙박스 같은 중간단계가 존재한다는 점 때문인 것 같다. GraphQL 을 학습할 바에 전통적 웹애플리케이션 개발을 학습하는 것이 더 효율적인 것으로 보인다.

 

rest 스러운 api 를 잘 만들기 위해서는 어떤 것이 엄격한 rest api 표준인 지를 아는 것이 중요하기 때문에 rest api 에 대한 학습과 실질적인 기술은 swagger 사용법 등을 학습하는 것이 좋아보인다. 

 

프론트 측에서 GraphQL 을 사용하면 편리하다고 하지만 ,,, 그렇지 않다. 그 불편성에 대해서 나열하기 위해서는 시간이 길어지기에 이렇게만 언급해놓겠다.