정의
API를 제공하기 위한 쿼리 언어
쿼리 언어란 뭘까?
사용자에게 필요한 정보를 데이터베이스나 정보 시스템에 보여달라고 요청할 수 있게 하는 컴퓨터 언어입니다. 쿼리 언어 종류는 여러 가지가 있지만 대표적으로 알려진 언어로는 SQL(Structured Query Language)이 있습니다.
SQL과 GraphQL은 어떤 차이점이 있을까?
언어적 구조, 사용법 등 여러 가지 차이가 존재하나 가장 큰 차이점은 언어의 목적이 다르다는 점입니다. SQL은 데이터베이스에 저장된 데이터를 효율적으로 가져오는 것이 목적이며, GraphQL은 웹 클라이언트가 데이터를 서버로부터 효율적으로 가져오는 것이 목적입니다.
왜 이 기술이 생겨났을까?
기존에는 API 개발을 할 경우 주로 REST API를 사용했었습니다. 하지만, REST API는 서비스가 커질수록 관리해야 할 API의 증가로 인해 여러 가지 문제들이 발생되었습니다. 그래서 이를 극복하기 위해 개발된 것이 바로 graphQL입니다.
이름에 ‘Graph’라는 표현이 붙었을까?
모든 데이터가 그래프 형태로 연결되어 있다고 전제하기 때문에 이 표현이 붙었습니다. 일대일로 연결된 관계도, 여러 계층으로 이루어진 관계도 모두 그래프입니다. 단지 그 그래프를 누구의 입장에서 정렬하느냐에 따라 트리 구조를 이룰 뿐입니다.
특징
- API에 GraphQL 쿼리를 보내서 필요한 정보만 얻을 수 있음 : GraphQL을 사용하는 앱은 서버가 아닌 가져오는 데이터를 제어하기 때문에 빠르고 안정적입니다.
- 단일 요청으로 많은 리소스 얻을 수 있음 : GraphQL 쿼리는 한 리소스의 속성에 액세스 할 뿐만 아니라 리소스 간의 참조를 원활하게 따릅니다. 일반적인 REST API는 여러 URL에서 로드해야 하지만 GraphQL API는 앱에 필요한 모든 데이터를 단일 요청으로 가져옵니다. GraphQL을 사용하는 앱은 느린 모바일 네트워크 연결에서도 빠를 수 있습니다.
- 유형 시스템으로 무엇이 가능한지 설명 가능 : GraphQL API는 엔드포인트가 아닌 유형과 필드로 구성됩니다. GraphQL은 유형을 사용하여 앱이 가능한 것만 요청하고 명확하고 유용한 오류를 제공하도록 합니다. 앱은 수동 구문 분석 코드 작성을 피하기 위해 유형을 사용할 수 있습니다.
- 강력한 개발자 도구로 더 빠르게 이동 가능 : API에서 요청할 수 있는 데이터를 정확히 파악하고 쿼리를 보내기 전에 잠재적인 문제를 강조 표시할 수 있는 GraphiQL 개발 도구 제공
- 버전 없이 API 수정 가능 : 기존 쿼리에 영향을 주지 않고 GraphQL API에 새 필드와 유형을 추가할 수 있습니다. GraphQL API는 앱에 새로운 기능에 대한 지속적인 액세스를 제공하고 더 깨끗하고 유지 관리가 용이한 서버 코드를 권장합니다.
- 자신의 데이터 및 코드 가져오기 : GraphQL은 특정 스토리지 엔진에 의해 제한되지 않고 전체 애플리케이션에 걸쳐 균일한 API를 생성합니다. 유형 시스템의 각 필드에 함수를 제공하면 GraphQL이 최적의 동시성을 사용하여 호출합니다.
장점
- 애플리케이션 API가 기존 쿼리를 중단하지 않고도 진화할 수 있도록 허용합니다.
- GraphQL은 특정 애플리케이션 아키텍처를 지정하지 않으므로 기존 REST API에 추가하여 기존 API 관리 툴과 연동할 수 있습니다.
- 한 개의 Endpoint를 지님으로써, API나 View를 따로 구성할 필요가 없어집니다. 요청을 보낼 때는 정해진 한 군데로만 요청을 보내면 되고, 그 외의 API를 신경 쓸 필요가 없어져, 유지보수가 용이해집니다.
- GraphQL은 한 번의 요청으로 원하는 모든 데이터를 서버로부터 요청하여 가져올 수 있습니다.
단점
- REST API에 친숙한 개발자의 경우 GraphQL를 학습하는 데 시간이 필요합니다.
- GraphQL은 데이터 쿼리의 상당 작업을 서버 측으로 옮겨 서버 개발자 작업의 복잡성이 커집니다.
- HTTP의 캐싱 전략은 각각 URL에 각자의 정책을 설정하는 방식으로 이루어지는데, RESTful API는 그대로 사용이 가능하나 GraphQL은 하나의 URL로 처리하기에, HTTP에서 제공하는 캐싱 전략을 그대로 사용하는 것은 불가능합니다. 따라서 캐싱 방식이 REST보다 훨씬 복잡합니다.
- GraphQL은 지속적으로 성장하는 생태계로써, 완성된 설계가 존재하지 않습니다. 따라서 이 외의 것들은 직접 개발할 수밖에 없게 되는데, 대표적인 예로 파일 업로드가 있습니다.
- GraphQL은 클라이언트가 필요한 데이터를 스스로 결정하여 요청하게 됩니다. 따라서 GraphQL의 다양한 요청 형태에서 잘못된 요청을 필터링하기가 까다롭습니다.
마무리
오늘은 요새 많은 회사에서 사용 중인 GraphQL에 대해서 공부해봤습니다.
공부를 해보니 GraphQL은 확실히 REST의 단점들을 많이 개선했을 뿐 아니라 생산성이 더 좋아졌다고 생각이 들어서 저는 이 기술이 괜찮다고 생각을 합니다. 하지만 위에 적어둔 여러 가지 문제점들 때문에 모든 개발에 GraphQL 방식을 적용하는게 맞을까?라는 의심이 생기네요.
아직 부족하거나 틀린 부분이 있을 수도 있으니 주의하시면 좋을 거 같습니다.
이번 포스팅은 마무리하면서 다음 포스팅에서 뵙겠습니다.
'CS 지식 > 아키텍처' 카테고리의 다른 글
멀티모듈(Multi Module)구조에 대하여 (0) | 2023.12.15 |
---|---|
도메인 주도 설계(Domain Driven Design)란? (0) | 2022.09.22 |
이벤트 기반 아키텍처(Event Driven Architecture)란? (0) | 2022.03.20 |