GraphQL: 필요한 데이터만 쿼리
REST API에서는 필요한 데이터만 얻기 위해서 몇 번의 요청을 보내야 한다. 그래서 GraphQL은 이 상황을 바꾸기 위해 탄생했다.
GraphQL은 정확하게 데이터를 요청하는 방법을 설명하는 구문이다. 서로를 참조하는 복잡한 엔티티를 사용하는 애플리케이션의 데이터 모델을 GraphQL으로 구현해 볼 만한 가치가 있다.
최근 GraphQL 생태계는 Apollo, GraphiQL 그리고 GraphQL Explorer와 같은 강력한 도구와 라이브러리로 확장되고 있다.
GraphQL 동작 방식
GraphQL은 GraphQL API에서 만들 수 있는 모든 쿼리와 반환하는 모든 타입에 대해 설명하는 스키마를 정의하는 것으로 시작한다. 스키마 정의 언어(SDL)에서는 엄격한 타입 정의를 사용하기 때문에 스키마 정의가 쉽지 않다.
쿼리 전에 스키마를 통해 "클라이언트에서는 서버로부터 응답을 받을 수 있는지 확인"을 위한 쿼리에 대한 유효성 검사를 할 수 있다. 백엔드 애플리케이션에 도달하면, 전체 스키마를 통해 GraphQL 작업이 해석된 후, 프론트엔드 애플리케이션에 응답할 데이터가 생성된다. 하나의 대규모 쿼리를 서버에 요청하면 API는 요청한 데이터의 형태와 정확히 일치하는 JSON 데이터를 응답으로 반환한다.
GraphQL에는 RESTful한 CRUD 작업 외에도 서버로부터 실시간 알림을 받는 구독이 있다.
GraphQL의 장점
스키마에서 타입을 사용한다. GraphQL은 무엇을 할 수 있는지 미리 게시하여 검색 성능을 높인다. GraphQL API에서 클라이언트에 접근하면 사용 가능한 쿼리를 확인할 수 있다.
그래프 형태의 데이터에 매우 적합하다. GraphQL은 연결된 관계의 데이터를 다루는데 효율적이지만 단순한 구조의 데이터를 다루는데에는 효율성이 떨어진다.
버전 관리를 사용하지 않는다. 버전 관리의 모범 사례는 API의 버전을 전혀 관리하지 않아도 되는 경우이다.
REST는 여러 버전의 API를 제공하지만, GraphQL은 발전하는 단일 버전을 사용하여 새로운 기능을 언제든 사용할 수 있고, 서버 코드를 더 깔끔하고 유지 관리가 용이하게 작성할 수 있다.
상세한 에러 메시지. GraphQL은 SOAP과 유사한 방식으로 발생한 에러에 대한 세부 정보를 제공한다. 에러 메시지는 모든 resolver와 정확하게 에러가 발생한 쿼리 부분을 명시한다.
유연한 권한. GraphQL에서는 개인 정보를 보호하며 특정 기능을 선택적으로 노출할 수 있다. 반면 REST 아키텍처는 데이터를 부분적으로 공개할 수 없다. 데이터 전부가 노출되거나 전부 보호된다.
GraphQL의 단점
성능 문제. GraphQL은 성능을 대가로 복잡성 얻었다. 하나의 요청에 너무 많은 중첩 필드가 있는 경우, 시스템에 과부하가 발생한다. 따라서 REST는 복잡한 쿼리에 더 적합한 옵션이다.
캐싱의 복잡성 GraphQL은 HTTP 캐싱 시멘틱을 재사용하지 않기 때문에 사용자 정의 캐싱을 구현하기 위해 노력을 필요로 한다.
개발 전, 많은 사전 교육 GraphQL은 틈새 운영 및 SDL을 파악을 시간이 충분하지 않은 이유로, 많은 프로젝트에서는 잘 알려진 REST를 사용한다.
GraphQL 사용 예시
모바일 API 를 개발하는 경우, 네트워크 성능과 단일 메시지의 페이로드 최적화가 중요하다. 따라서 GraphQL은 모바일 기기에서 보다 효율적인 데이터 로딩을 제공한다.
복잡한 시스템과 마이크로서비스 GraphQL은 API 뒤에 있는 여러 시스템 통합의 복잡성을 숨길 수 있다. GraphQL은 여러 시스템으로부터 데이터를 집계하여 하나의 글로벌 스키마로 병합한다. 이는 시간에 지남에 따라 확장하는 레거시 인프라 또는 third-party API와 관련이 있다.
다음 상황에는 어떤 API 패턴이 가장 접합할까?
API 프로젝트마다 요구 사항이 다르다. 일반적으로 다음 사항에 따라 아키텍처를 선택한다.
- 사용하는 프로그래밍 언어
- 개발 환경
- 인적, 재정적 자원의 여유
각 API 아키텍처 스타일의 장단점을 모두 알고 있으면, API 설계자는 프로젝트에 가장 적합한 API 아키텍처 스타일을 선택할 수 있다.
RPC는 긴밀한 결합을 필요로 하는 내부 마이크로 서비스에서 활용되지만 강력한 외부 API 또는 API 서비스를 위한 옵션은 아니다.
SOAP의 번거롭지만 청구, 예약, 그리고 지불 시스템에서 SOAP가 제공하는 다양한 보안 기능은 다른 API 아키텍처 스타일로 대체 불가능하다.
REST는 API는 추상화 정도가 가장 높고 최고의 API 모델링을 가지고 있다. 그러나 통신에서 느리고 메시지가 과다한 경향이 있어 모바일에 적용하기에는 아쉽다.
GraphQL은 데이터 조회 측면에서 한 발 앞서 있지만 모든 사람이 GraphQL을 익히기에 충분한 시간과 노력을 투자할 수 있는 것은 아니다.
이 글을 읽고나서, 특정 스타일의 사용 사례를 확인하고 해당 사례가 문제에 적합하고 문제를 해결했는지 확인해보는 것이 내용을 이해하는데 도움이 될 것이다. 만약 도움이 되었다면, 더 많은 사용 사례를 확인해보자.
참조: https://www.altexsoft.com/blog/soap-vs-rest-vs-graphql-vs-rpc/
