> gRPC는 모든 환경에서 실행할 수 있는 최신 오픈 소스 고성능 일반 원격 프로시저 호출 프레임워크이며, Google, Netflix, Square, IBM, Cisco 및 Dropbox와

> gRPC는 모든 환경에서 실행할 수 있는 최신 오픈 소스 고성능 일반 원격 프로시저 호출 프레임워크이며, Google, Netflix, Square, IBM, Cisco 및 Dropbox와 같은 많은 주요 기술 회사에서 gRPC를 채택했습니다. 이 프레임워크는 최대 API 보안, 성능 및 확장성을 보장하기 위해 HTTP/2, 프로토콜 버퍼 및 기타 최신 기술 스택에 의존합니다. gRPC에서 클라이언트 응용 프로그램은 마치 로컬 개체인 것처럼 다른 컴퓨터의 서버 응용 프로그램에서 메서드를 직접 호출할 수 있으므로 분산 응용 프로그램 및 서비스를 더 쉽게 만들 수 있습니다. > ❗️ gRPC는 프로토콜 버퍼 및 HTTP/2와 같은 기술을 사용하여 상호 운용 가능하고 현대적이며 효율적으로 만들어 기존 RPC 설계 방법을 새롭게 해석합니다. 다음과 같은 이점으로 인해 일부 작업에서 REST를 대체할 수 있는 확실한 후보가 됩니다. ❗️ 가벼운 메시지 . 호출 유형에 따라 gRPC 관련 메시지는 JSON 메시지보다 크기가 최대 30% 작을 수 있습니다. ❗️ 고성능. 다른 평가에 따르면 gRPC는 REST+JSON 통신보다 빠릅니다. ❗️ 내장 코드 생성. gRPC는 Java, C++, Python, Go, Dart, Objective-C, Ruby 등을 포함한 다양한 프로그래밍 언어로 코드 생성을 자동화했습니다. ❗️ 더 많은 연결 옵션. REST는 요청-응답 아키텍처에 중점을 두고 있지만 gRPC는 서버 측 스트리밍, 클라이언트 측 스트리밍 및 양방향 스트리밍과 같은 이벤트 기반 아키텍처를 통해 데이터 스트리밍을 지원합니다. > ❗️ 제한된 브라우저 지원 ❗️ 캐싱 없음 ❗️ 사람이 읽을 수 없는 형식-데이터를 이진 형식으로 압축하여 protobuf 파일을 사람이 읽을 수 없게 됩니다. > gRPC의 성공은 HTTP/1.1 대신 HTTP/2를 사용하고 XML 및 JSON 대신 프로토콜 버퍼를 사용하는 두 가지 기술의 사용 덕분입니다. 대부분의 gRPC 이점은 이러한 기술을 사용하는 데서 비롯됩니다. > 프로토콜 버퍼는 Google에서 거의 모든 기계 간 통신에서 개발 및 사용되는 메시지 구조화에 널리 사용되는 기술입니다. gRPC에서는 REST에서 XML 또는 JSON 대신 프로토콜 버퍼(또는 protobuf)가 사용됩니다. 클라이언트와 서버 간의 gRPC 서비스 및 메시지는 proto 파일에 정의됩니다. Protobuf 컴파일러인 protoc는 런타임에 .proto 파일을 메모리에 로드하고 메모리 내 스키마를 사용하여 바이너리 메시지를 직렬화/역직렬화하는 클라이언트 및 서버 코드를 생성합니다. 코드 생성 후 각 메시지는 클라이언트와 원격 서비스 간에 교환됩니다. > 스트리밍은 단일 요청에서 많은 프로세스가 발생할 수 있는 gRPC의 또 다른 핵심 개념입니다. HTTP/2의 다중화 기능(단일 TCP 연결을 통해 다중 응답 전송 또는 다중 요청 수신)이 이를 가능하게 합니다. 스트리밍의 주요 유형은 다음과 같습니다. ❗️ 서버 스트리밍 RPC : 클라이언트는 서버에 단일 요청을 보내고 데이터 시퀀스 스트림을 다시 받습니다. 시퀀스가 유지되고 서버 메시지는 메시지가 남지 않을 때까지 계속 스트리밍됩니다. ❗️ 클라이언트 스트리밍 RPC : 클라이언트는 데이터 시퀀스 스트림을 서버로 보내고 서버는 단일 응답을 처리하고 클라이언트에 반환합니다. 다시 한 번, gRPC는 독립적인 RPC 호출 내에서 메시지 시퀀싱을 보장합니다. ❗️ 양방향 스트리밍 RPC : 클라이언트와 서버가 서로에게 일련의 메시지를 보내는 양방향 스트리밍입니다. 두 스트림 모두 독립적으로 작동합니다. 따라서 어떤 순서로든 메시지를 전송할 수 있습니다. 각 스트림의 메시지 순서는 보존됩니다. > REST와 gRPC는 모두 IT 환경에서 제 위치를 차지하고 있습니다. 사용 용이성 측면에서 REST가 승리합니다. 그러나 REST는 부피가 크고 상태 비저장입니다. REST 응답은 네트워크를 통해 많은 데이터를 전송하며 대부분은 실제 데이터 자체가 아닌 데이터 구조와 관련이 있습니다. REST에서 개발자는 대상에 대한 연결을 만든 다음 대상이 해당 연결을 통해 지속적으로 데이터를 반환하도록 할 수 없습니다. 개발자는 주기적으로 API를 호출하여 해당 데이터를 가져와야 합니다. 반면, gRPC는 지속적인 스트리밍을 지원하도록 설계되었습니다. gRPC의 단점은 개발자가 이를 사용하기 위해 많은 개념과 작업을 알아야 한다는 것입니다. 예를 들어 클라이언트와 서버 모두 .proto 파일 사양을 알아야 합니다. 둘 다 프로토콜 버퍼로 인코딩 및 디코딩을 수행하기 위해 해당 정보를 사용합니다. REST와 달리 개발자는 도구에 URL을 입력하여 호출을 실행하고 결과를 JSON으로 받을 수 없습니다. gRPC는 REST의 진화가 아니며 API를 빌드하는 더 나은 방법도 아닙니다. 간단히 말해서, 이것은 몇 가지 편리한 조정으로 HTTP와 함께 RPC의 경량 구조를 사용하는 방법입니다. 이는 새로운 API 설계를 시작할 때 고려해야 할 또 다른 대안일 뿐입니다.