Application Programming Interface의 줄임말이며 두 소프트웨어가 서로 통신할 방법을 설명하기 위해 고안된 방식이다.
API를 개발하면 인증 절차를 거쳐 회사의 데이터와 기능을 내외부 개발자들이 사용할 수 있게된다.
가장 흔한 방식은 HTTP 프로토콜을 사용한 RestAPI이며 Web 기반의 External API이다.
Internal API는 대표적으로 RPC를 사용하며 그 중 gRPC는 구글에서 개발한 대표적인 RPC Framework이다.
마이크로 서비스 간의 통신을 많이 해야했던 구글이 내부용으로 활용했던 프레임워크였고 오픈 소스로 공개하여 다른 기업이나 개인들이 활용하기 좋은 프레임워크로 발전하였다.
gRPC
전송을 위해 HTTP/2를 사용하며, 시작과 확장이 빠르고 쉽다는 특징이 있다.
여러 언어 및 플랫폼으로 확장하고 있고, 양방향 스트리밍과 통합 인증을 제공한다.
주요 특징
1. 간결하고 효율적인 프로토콜 버퍼를 사용
2. 다양한 언어로 구현
3. 양방향 스트리밍, 비동기 호출, 인증, 차단 및 비차단 바인팅, 취소 및 타임아웃 등 다양한 통신 패턴을 제공
4. HTTP/2 기반
5. SSL/TLS를 기본으로 지원
마이크로 서비스 아키텍처를 구성할 때 내부의 어플리케이션끼리 통신하기 용이하도록 만든 것이기 떄문에 그와 비슷하게 활용할 수 있다.
대표적으로 내부의 다른 애플리케이션 통신을 빠르고 안전하게 할 때 활용한다.
gRPC가 제공하는 가장 대표적인 기능이 streaming이기 때문이다.
그리고 대량의 데이터는 Rest 보다 7배 빠른 프로토콜 버퍼를 쓴다고 한다.
클라이언트가 서로 다른 언어로 되어 있더라도 새롭게 라이브러리를 작성하지 않아도 되며 이미 서버에 구현된 프로토콜 버퍼를 해당 언어에 맞게 배포하면 된다.
gRPC를 활용하는 case
- 마이크로 서비스 스타일 아키텍처에서 다양한 언어로 구성된 서비스를 연결할 때
- 모바일과 백엔드 서버를 연결할 때
- 스트리밍 요청 또는 응답을 처리해야 하는 실시간 서비스를 연결할 때
이와 비교되는 표준은 WebSocket이며 가장 많이 사요되는 곳은 채팅 서비스, 라이브 스코어 업데이트, 뉴스 피드와 같은 기능에서 활용된다.
REST
Representational State Transfer Architectural Style의 줄임말이며 가장 흔하게 사용하는 API.
Web API의 한 종류로 REST 디자인 프린시플을 따르는 API를 REST API라고 한다.
개발자에게 높은 자유도를 보장해주며 많은 Component들을 연결하거나 마이크로 서비스 아키텍처에서 많이 활용되었다.
client, server, resource, representation으로 구성되어 있다.
가장 많이 사용되는 데이터 형식은 JSON이며 서버와 클라이언트가 REST API로 통신할 때 가장 먼저 정의하는 것이 JSON 스펙 정의이다.
GraphQL
GraphQL은 애플리케이션 프로그래밍 인터페이스를 위한 쿼리 언어이자 서버 측 런타임으로 클라이언트에게 요청한 만큼의 데이터를 제공하는데 우선순위를 둔다. 기존에 있던 REST보다 더욱 빠르고 유연하며, 개발자 친화적으로 만들기 위해 설계되었다.
Rest를 대체할 수 있으며 단일 API 호출로 다양한 데이터 소스에서 데이터를 끌어오는 요청을 구성할 수 있다.
Rest의 한계
시간이 지나며 End-Point가 늘어나면서 복잡성이 높아지기 시작했고 의존성 핸들링을 위해 코드가 추가되고, 유틸 함수들이 늘어나게 되었다.
문서화 이슈도 발생하게 되는데 Swagger 같은 툴도 있지만 이 툴을 이용하는 것 자체로도 리소스가 많이 필요하다.
그러다 보니 비용이 계속해서 증가하고 문서화에 소홀히 하는 경우가 생겨 정보가 불충분하여 문제가 생기는 경우도 발생한다.
GraphQL의 장점
FE에서 필요한 최소한의 정보만 별도 요청이 가능하여 HTTP 요청 횟수를 줄여 효율을 높일 수 있다.
그리고 REST는 JSON을 통해 데이터를 전송하고 그 안에 타입 정의는 딱히 없지만 GraphQL은 데이터 유형 정의가 엄격하여 클라이언트와 서버 간의 통신 오류를 줄여준다.
또한 REST는 Resource 종류별로 요청을 해야 하기에 요청 횟수가 필요한 Resource 종류에 비례하여 증가하게 된다.
GraphQL은 원하는 정보를 하나의 Query에 모두 담아 요청이 가능하다. 즉, HTTP 응답 Size를 줄일 수 있다.
GraphQL은 애플리케이션 API가 기존 쿼리를 중단하지 않고도 배포가 가능하다.
마지막으로 Over-Fetching과 Under-Fetching을 개선한다.
이 또한 REST의 한계이며 Over-Fetching은 필요한 데이터 보다 많은 데이터를 서버에서 받아오는 것을 의미하며 네트워크 리소스를 의미 없이 잡아 먹는 경우가 생긴다.
Under-Fetching은 이와 반대로 한 번의 요청으로 필요한 데이터를 모두 받아오지 못해 여러 번 요청을 수행하는 것을 의미하며 하나의 화면을 만들기 위해 서버에 요청하는 Request가 많아지면 눈에 보일 정도로 네트워크가 지연되기 시작한다.
이러한 상황을 최대한 줄이는 것이 GraphQL이라고 볼 수 있다.
GraphQL의 단점
File전송과 같은 Text 기반의 전송이 아닌 요청은 작업 처리가 복잡하다.
그리고 Caching 기능이 REST보다 복잡하다.
그리고 고정된 요청과 응답만 필요한 경우가 있고 데이터 쿼리의 상당 작업들이 서버측에서 처리 되기 때문에 서버 개발자 작업의 복잡성이 증가한다.
한 마디로 서버 개발자가 해야 할 일이 많아진다.
