Hacker News 의견

• gRPC를 배우지 말았어야 했다는 후회가 있음. 디버깅과 설정 조정에 많은 시간이 소요되었음

  • gRPC는 내부를 숨긴다고 하지만, 실제로는 많은 디버깅과 설정 조정이 필요함
  • Maven 플러그인, HTTP2와의 호환성 문제, 방화벽 문제 등으로 많은 시간을 낭비했음
  • 문서가 부실하고, 오류 메시지를 관찰 가능하게 만드는 데 어려움이 있었음

• 오랫동안 API를 구축해왔으며, gRPC와 HTTP/REST를 사용해왔음

  • OpenAPI와 REST의 차이를 구분하는 것이 이상하다고 생각함
  • OpenAPI는 HTTP API의 동작을 문서화하는 방법이며, RESTful API를 표현할 수 있음
  • gRPC는 프로토콜 버퍼를 주고받는 RPC 메커니즘임
  • gRPC는 효율적이지만, HTTP 라이브러리만큼 강력하지 않음

• FAANG에서 일한 경험이 있으며, 내부 서비스 라우팅에 gRPC가 유용하다고 생각함

  • RPC 프로토콜은 대규모 및 고속으로 작업을 가능하게 함
  • 그러나 고객이나 웹을 대상으로 하는 경우에는 gRPC를 사용하지 않을 것임

• 양방향 스트리밍을 하지 않는 한, gRPC는 시간 낭비라고 생각함

  • 다양한 언어로 구현된 서비스 간의 RPC 호출을 할 때 많은 미들웨어가 필요함

• gRPC를 사용한 프로젝트에서 성능을 이유로 도입했으나, JSON API로 전환했음

  • gRPC에 대한 경험이 부족했고, 프로젝트는 여러 문제로 인해 실패했음

• connectrpc를 사용하면서 gRPC의 문제점을 해결하고 있음

  • buf.build를 통해 3rd party proto 파일을 쉽게 가져올 수 있음
  • SDK 자동 생성 기능이 매우 유용함

• gRPC는 REST보다 개발 경험이 나쁘다고 생각함

  • 추가적인 도구가 필요하고, 생성된 클라이언트 코드가 복잡함

• REST API는 초기 URI와 표준화된 미디어 타입만 알면 된다고 Roy Fielding이 언급함

• 데이터 센터 내에서 gRPC 사용을 좋아하지 않음

  • 성능이 높지 않고, 오픈 소스 클라이언트의 품질이 낮음
  • 웹 기반 API에서는 JSON의 가독성을 선호하지만, 타입 불일치 문제가 있음

• gRPC는 Google 외부에서는 접근하기 어렵다고 느꼈음

  • gRPC JS 클라이언트가 무겁고 불투명함
  • REST의 단순함에 비해 실행이 잘못되었다고 생각함