여러 RPC 프레임워크 중 구글에서 만든 PRC 프레임워크로
클라이언트가 원격 서버에서 실행 중인 함수(메소드)를 로컬 함수처럼 호출할 수 있도록 하는 기술이다.
높은 성능과 강력한 개발자 커뮤니티, 풍부한 도구와 라이브러리를 갖추고 있어 널리 사용되는 PRC이다.
언어 독립적으로 서로 다른 프로그래밍 언어를 사용하는 서버와 클라이언트 사이에서도 사용될 수 있다.
위의 예시의 경우, 서버는 RUBY, 클라이언트틑 C#으로 작성되어있다.
ADD 함수는 서버에서 선언되고 정의된 함수이지만 , 클라이언트 코드에서는 마치 클라이언트의 함수를 사용하듯이 해당 함수를 호출할 수 있다.
이는 stub 객체를 사용하여 가능하다.
stub 객체는 서버에서 정의한 함수를 클라이언트가 로컬 함수처럼 호출할 수 있게 해준다. 클라이언트가 stub 을 통해 함수를 호출하면, 실제로는 네트워크를 통해 서버에서 함수가 실행되고 결과가 반환된다.
예시 : 책의 대여 가능 여부를 확인하기 위한 데이터의 요청과 응답의 경우.
REST API - 책의 식별 번호와 수량 데이터를 전달하면 해당 책에 대한 대여 가능 여부, 책의 위치 등의 정보를 응답으로 보내준다. 이때 사용되는 데이터의 형식은 JSON이다. JSON 데이터 형식의 경우 빈번한 요청과 응답의 경우, KEY 부분의 반복으로 데이터의 낭비가 발생한다.
gPRC - 이런 데이터의 낭비를 방지하기 위하여 gPRC의 경우 ‘Protocol Buffer’를 명시하여 사용한다.
이는 KEY 데이터가 필드로 작성되어 있고 대응하는 번호로 구분하고 있다.
각 메세지가 어떻게 작성될 지에 관한 약속으로, 서버와 클라이언트 모두에게 공유된다.
이를 기준으로 클라이언트와 서버는 주고받는 메세지를 작성하고 해독한다.
지정되어 있는 필드를 각각 매개변수와 반환 값으로 사용하도록 기능을 지정할 수도 있다. 이것이 서버에서 구현되고 클라이언트에서 호출하는 함수가 된다.
이처럼 Protocol Buffer를 사용하여 합의된 사양을 기준으로 언어와 환경이 다른 주체들끼리도 매끄럽게 소통을 할 수 있다.
단순히 키만 간소화하는 것이 아니라, 이를 바이너리 형태로 직렬화하여 전송한다. JSON 기반 텍스트 기반의 형식에 비해 용량이 작으므로 훨씬 빠르게 전송할 수 있다.
또한, Protobuf는 유연한 버전 관리를 지원한다.. 예를 들어, 클라이언트와 서버가 각각 다른 버전의 Protobuf 메시지 형식을 사용하더라도 상호 호환성 문제가 발생하지 않도록 설계되었다.

REST API - 주로 HTTP/1.1 사용, 요청과 응답을 차례대로 주고 받는다.
먼저 온 요청에 대한 응답이 지연된다면 그 뒤에 요청들은 처리를 기다리게 되어 지연이 발생할 수 있다.

gPRC - 서버와 클라이언트는 양방향으로 스트리밍을 할 수 있다. 여러 메세지를 한 번에 보낼 수 있고 순서에 상관없이 빠르게 처리해서 답을 보낼 수 있다.
또한, 서버가 클라이언트의 요청과 별개로 능동적으로 메세지를 보낼 수도 있어, 이는 서버와 클라이언트가 빠르고 효율적으로 소통할 수 있게 한다.
gPRC는 TLS를 통해서 데이터를 암호화하여 전달하여 기밀성과 무결성을 보장한다.
이를 통해 메세지의 내용 변경, 클라이언트 혹은 서버를 사칭하지 못하도록 하여 안전한 통신을 제공한다.
아직까지는 gPRC는 ****브라우저에서 동작하는 웹 프론트엔드에서는 잘 사용되지 않는다. 브라우저에서 HTTP/2를 지원하긴 하지만 상세 기능들의 지원을 아직 부족하기 때문이다.
가장 널리 사용되는 곳은 마이크로서비스 아키텍쳐이다.
빠른 전송, 높은 성능, 언어 중립성, 양방향 스트리밍이 마이크로서비스들간의 통신에 중요한 요소이기 때문이다.
또한, 전자 상거래 플랫폼, 은행 및 금융 서비스. 의료 기록 서비스 등에서 유용하게 활용되고 있다.
모바일 어플리케이션 , 온라인 게임처럼 서버와의 실시간 상호작용과 동기화가 필요한 곳에서도 적용할 수 있다.
‘얄팍한 코딩사전 - gRPC - 알고 나면 쉬움’을 참고하여 정리하였습니다.