우리 서비스, GraphQL 도입해야 하는 단계인가?

아래의 내용은 우리 회사 개발팀에서 논의한 내용을 정리한 것입니다. 개발자 분들께서 열정적으로 토론한 내용을 정리해 보았습니다.

우리 서비스에서 GraphQL이 필요한가??!!!!!!!!

GraphQL 도입에 대한 논의 배경

우리 서비스의 현재 상태는 다음과 같다.

• 우리 서비스는 빠르게 성장하고 있으며(앱 서비스), 그 가운데 가까운 시일 내에 해외 출시 및 웹 출시가 이루어질 예정이다.
• 그런데 장고로 개발된 우리 서비스의 백엔드 코드는 Restful API가 아니며 현재는 HTTP API를 사용하고 있기 때문에 웹 서비스를 도입했을 때 백엔드가 기기별 대응을 할 수가 없는 상태이다.

이 때문에 우리는 Restful API 혹은 GraphQL은 도입할 단계에 왔으며 GraphQL을 도입 했다고 가정했을 때의 문제 및 그 효율성에 대해 논의할 필요가 있었다.

GraphQL 도입에 대한 기준은 다음과 같다.

1. 이관, 그리고 migration이 쉬운가?
2. 현재 우리 서비스 개발자들이 도입하기에 어려움이 없는가?
   • 이는 사람에 따라 다를 수는 있겠으나 논의의 중심은 REST API과 GraphQL을 비교했을 때 어느 것이 '덜 어렵겠는가'이다.
3. 어느 방안이 더 효율적인가?

우리 서비스의 현재

현재 우리 서비스의 백엔드는 장고-HTTP API를 사용하고 있다(RESTful API가 아니다).

• 우리 서비스는 앞에서도 말했듯 빠르게 성장하고 있다. 그러나 아직 안정된 단계는 아니며 그렇기 때문에 제품이 구조화 되어 있지 않다.
• API Documentation 관리가 잘 되고 있지 않다.
  - 백엔드는 백엔드의 api를, 프론트엔드는 DTO를 확인해 관리하고 있다.
• RDS가 고성능 CPU를 사용하고 있지 않다.
  - 따라서, 한 API에 무거운 쿼리를 던지면 CPU 이슈가 발생할 수 있다.
  - 현재까지는 아~주 가끔씩 특이 케이스의 경우 504 에러가 정도이지만 점점 무거워지고 있다.

GraphQL이 필요한가

세 가지 관점에서 논의를 해보겠다.

기획

1. 빠르게 성장하는 서비스는 기획이 수시로 바뀐다.
   • 그렇기 때문에 이에 대응하기 위해 custom resolver를 view에 준하는 갯수만큼 짜야 하는 문제가 발생할 가능성이 높다.
2. '화면 배치가 바뀌는' 등의 간단한 기획에서도 백엔드 API가 변경되어야 하며 이에 따라 프론트엔드에서는 새로운 API를 호출해야 한다.
   • GraphQL을 사용하면 그럴 필요 없이 있는 쿼리만 짜서 호출하면 된다.
   • 그러나 이러한 상황은 자주 발생하는 상황은 아니며 같은 데이터일 경우 REST API를 사용할 경우 굳이 바꿔줄 필요가 없을 것이다. 즉, REST API를 사용하면 된다.

프론트엔드

1. 쿼리의 성능 이슈를 프론트엔드에서는 알지 못한다.
   • 즉, 프론트엔드에서 필요한 쿼리들을 모두 조회하게 될 경우 DB 부하가 생길 수 있는데 이를 프론트에서 일일이 확인할 수는 없다. 이는 백엔드의 영역이다.
   • 장애를 겪고 나서야 이슈를 해결하게 되는 상황이 발생하게 될 수 있다.
   • 또한, 프론트에서 요청할 수 있는 depth에 제한을 걸어줘야 할 필요성도 있을 것 같다(하수라를 이용해 allowed query를 설정해 프론트엔드에서 조회 가능한 쿼리를 제한할 수 있다).
2. 클라이언트는 필요 없는 정보를 가져오지 않아도 된다.
   • 그러나, 현재 우리 서비스에서 필요 없는 정보를 클라에서 들고 왔다고 해서 문제가 생길 정도는 아니다.

백엔드-프론트엔드 협업

1. API Documentation 관리
   • 프론트엔드에서는 백엔드에서 제공하는 필드와 정확히 동일한 것을 사용하게 되기 때문에 type 또는 null 이슈가 발생하지 않는다.
   • description을 백엔드에서 추가할 수 있어 프론트엔드와 백엔드가 원활히 소통할 수 있다.

그래서 좋은점은?

• docs를 유지 관리 하는 차원에서 도입하는 것은 좋다.
  • git으로 이력 관리가 된다.
• 처음 배우고 공부해 GraphQL을 도입해야 하는 입장에서는 REST보다 GraphQL이 더 배우기 쉽다.
  

결론

우리 서비스에 GraphQL이 필요한 이유는 다음과 같다.

1. GraphQL이 제공하는 API Documentation
   • description을 제공하기 때문에 프론트엔드와의 소통에 용이하다.
   • git으로 이력을 관리하기 때문에 변경 사항을 확인하기 좋다.
2. 추가적으로, 나~중에는 재사용성을 높이는 데도 기여할 것이다.

이제 우리가 해야할 일

• HTTP API인 우리 서비스를 리팩토링 하면 GraphQL 도입에 적합한 상태가 될 것이다.
  • GraphQL의 API Documentation description 및 git을 통한 이력 관리의 이점은 우리 프로젝트에 도입할만 하다.
    • 따라서, 우리 장고 프로젝트의 모든 앱들을 resolver 형태로 차근차근 리팩토링 해놓고 리팩토링이 끝난 시기에 GraphQL을 본격적으로 도입하도록 한다.
  • 백엔드의 문서화만 완료 되면 프론트엔드에 그 때 알려서 프론트엔드에서 GraphQL을 사용하도록 안내한다.
• 그동안은 프론트엔드 개발자는 DTO를 보고 사용해야 하는 필드를 확인하면 된다.