1. GraphQL의 설계 원칙
GraphQL API 작성법에 제한은 없지만 GraphQL 서비스를 만들 때 고려해야 할 몇가지 지침이 있습니다.
- 위계적
- GraphQL 쿼리는 위계성을 띠고 있습니다. 필드 안에 다른 필드가 중첩 될 수 있으며, 쿼리와 그에 대한 반한 데이터는 형태가 서로 같습니다.
- 제품 중심적
- GraphQL은 클라이언트가 요구하는 데이터와 클라이언트가 지원하는 언어 및 런타임에 맞춰 동작합니다.
- 엄격한 타입 제한
- GraphQL 서버는 GraphQL 타입시스템을 사용합니다. 스키마의 데이터 포인트마다 특정 타입이 명시되며, 이를 기초로 유효성 검사를 받게 됩니다.
- 클라이언트 맞춤 쿼리
- GraphQL 서버는 클라이언트 쪽에서 받아서 사용할 수 있는 데이터를 제공합니다.
- 인트로스펙티브
- GraphQL 언어를 사용해 GraphQL 서버가 사용하는 타입시스템에 대한 쿼리를 작성할 수 있습니다.
2. GraphQL의 탄생
**페이스북은** RESTFul 서버와 FQL(페북의SQL) 데이터 테이블을 사용하고 있었습니다. 성능도 별로였고, 앱은 자주 충돌이 났습니다. 그때 엔지니어들은 데이터를 클라이언트 애플리케이션으로 전송하는 방식을 개선해야 한다는 사실을 깨달았습니다.그러고 나서 페이스북 엔지니어들은 GraphQL을 만들기 시작하였고 이는 페이스북의 클라이언트 및 서버 애플리케이션데이터 모델 요구사항과 기능을 정립하기 위한 쿼리 언어가 됩니다.
현재 페이스북 내부의 데이터 페칭은 거의 GraphQL을 통해 이루어져있고 IBM, 에어비엔비 등등 다른 회사 제품에서도 사용중에 있습니다.
3. 데이터 전송의 역사
RPC
1960년에 RPC(Remote Procedure call, 원격 프로시저 호출)가 발명되었습니다. RPC는 클라이언트에서 원격 컴퓨터로 요청 메세지를 보내 무언가를 하도록 만듭니다. 원격 컴퓨터는 클라이언트로 응답 메세지를 보냅니다. 클라이언트가 서버로 데이터 요청을 보내고, 서버는 이에 대한 응답을 보내줍니다.
SOAP
1990년 후반에 마이크로소프트에서 SOAP(simple Object Access Protocol), **단순 객체 접근 프로토콜이 나왔습니다. SOAP는 XML을 사용해 메세지를 인코딩하고 HTTP를 사용해 전송합니다. SOAP에서는 타입 시스템도 사용하고 `리소스 중심의` 데이터 호출이라는 개념도 도입해 사용하였습니다. SOAP**를 사용하면 결과 값을 예측하기가 상당히 쉬우나, 구현하기가 꽤 복잡하기 때문에 사용 도중 좌절할 위험이 있습니다.
REST
REST는 로이필딩이 200년에 작성한 캘리포니아 어바인 대학 학위 논문에서 정의된 개념입니다. 이 논문에는 사용자가 GET, PUT,POST,DELETE 와 같은 행동을 수행하여 웹 리소스를 가지고 작업을 진행하는 리소스 중심의 아키텍처에 대한 내용이 담겨있습니다.
리소스 네트워크는 가상 상태 머신(Virtual state machine)이며 행동은(GET, PUT,POST,DELETE )은 머신 상태를 바꿉니다. RESTful 아키텍처에서 라우트는 정보를 나타내는 개념입니다. 예를 들어 다음과 같은 각각의 라우트를 통해 정보를 요청하면 그에 따라 응답이 다르게 오게 됩니다.
REST를 사용하면 데이터 모델의 엔드포인트를 다양하게 만들 수 있고, 이전의 아키텍처보다 개발하기 쉽습니다. 데이터 응답 형식을 자유롭게 만들 수 있는 가능성을 열어줍니다. 초반에 REST는 XML과 함께 사용됐습니다. AJAX는 원래 "비동기 자바스크립트" 그리고 XML의 머리글자만 따서 만들어진 단어였습니다. 왜냐하면 AJAX의 요청에 대한 응답 데이터가 XML형식이였기 때문입니다.
하지만 이제는 Ajax라는 철자를 가진 독립적인 단어가 되었습니다.
이 때문에 웹 개발자가 받는 고통은 가중되었습니다. JS에서 데이터를 사용하기 전에 XML응답을 파싱해야 되었기 때문입니다.
얼마 지나지 않아 더글라스 크록포드가 JSON(자바스크립트 객체 표기법)을 만들고 표준화하였습니다. JSON은 특정 언어에 구애 받지 않으며, 다양한 언어에서 파싱하고 사용할 수 있도록 데이터 포맷을 가지고 있습니다.
REST의 단점
오버페칭
REST 버전 데이터를 가져왔을 때 앱에서 필요한 데이터보다 큰 경우입니다. 예를들어 클라이언트가 필요한 데이터 3개지만 REST 라우트를 통해 데이터를 페칭해온다면 더 많은 데이터가 들어 올 수 있습니다.
이러한 불필요한 오버 페칭을 GraphQL의 쿼리 방식으로 해결이 가능합니다. 불필요한 데이터를 가져오지 않는 것은 응답속도가 빨라질 여지를 만드는 것입니다.
언더 페칭
필요한 데이터 보다 적게 가져오는 경우입니다. REST를 사용하였을 경우 원하는 데이터를 가져오기 위해 페칭을 여러번 해야하는 경우가 생깁니다. 즉 데이터를 요청하고 나서 추가 데이터를 또 요청해야하는 상황이 온다는 것입니다. 이를 언더페칭이라 합니다.
하지만 GraphQL은 쿼리를 중첩적으로 정의하여 페치 한 번에 필요한 모든 데이터를 요청하여 이런 언더페칭의 문제를 해결 할 수 있습니다.
REST 엔드포인트 관리
REST API의 불만 중 하나는 유연성이 부족하다는 것입니다. 클라이언트에 변경 사항이 생기면 대개 엔드포인트를 새로 만들어야 하는데, 이렇게 되면 엔드포인트의 개수가 몇배로 빠르게 늘어납니다.
하지만 GraphQL을 사용하면 설계상 엔드포인트가 보통 하나로 끝나게 됩니다. 단일 엔드포인트가 게이트 웨이로써 몇 가지 데이터 소스를 조율하는 역할을 하게 되고 데이터 체계 역시 손쉽게 관리됩니다.
GraphQL과 REST를 같이 사용하고 있다는 것에 유의 해야합니다. GraphQL 엔드포인트를 만들어 REST 엔드포인트의 데이터를 가져오는 식의 작업 방식은 완벽하게 유효한 GraphQL의 사용법입니다.
4. GraphQL 클라이언트
GraphQL은 개발 환경에(react,vue,JS, 브라우저)에 독립적입니다.
GraphQL 클라이언트의 목적은 개발자가 빠르게 작업 할 수 있는 환경을 만들어 주고 애플리케이션의 성능과 효율성을 끌어올리는 것입니다. 네트워크 요청 , 데이터 캐싱, 사용자 화면에 따라 데이터 주입 등의 일을 담당합니다. 여러 종류 중 Realy와 Apollo입니다.
GraphQL클라이언트 : Apollo, Realy 네트워크 요청, 데이터 캐싱, 데이터 주입의 일을 담당
Apollo 클라이언트는 더 복합적인 GraphQL 툴 제공을 목표로 커뮤니티 주도의 프로젝트가 진행 중입니다. 모든 주요 프론트 엔드 개발 플랫폼에서 사용 할 수 있으며 프레임 워크에 종속 되어 있지 않습니다.
Reference
