BloomRPC는 모든 gRPC 개발자가 결국 묻게 되는 질문, 즉 "gRPC용 Postman은 어디에 있나요?"에 대한 답이었습니다. .proto 파일을 로드하고, 편집 가능한 JSON 요청 본문을 얻고, 전송 버튼을 누르면 되었습니다. 간단했고, 무료였으며, 한 가지를 잘 해내면서 약 9,000개의 GitHub 스타를 얻었습니다. 그러다가 2023년 1월 4일, 해당 저장소는 보관(archive)되었습니다. README는 프로젝트가 정체되었고, 문제가 쌓였으며, 이제 관리자들이 "더 이상 사용을 권장하지 않는다"고 명확히 밝히고 있습니다. 그들은 여러분을 awesome-grpc 목록으로 안내하며 행운을 빌어줍니다.
여기 직접적인 답변이 있습니다: 대부분의 팀에게 Apidog는 최고의 BloomRPC 대체 도구입니다. 왜냐하면 단순히 .proto 로딩 창을 대체하는 것을 넘어섭니다. Apidog는 네 가지 gRPC 호출 유형(단항, 서버 스트리밍, 클라이언트 스트리밍, 양방향 스트리밍)을 모두 지원하며, 로컬 경로, URL 또는 서버 리플렉션에서 .proto 파일을 가져올 수 있습니다. 또한, gRPC 작업을 REST, WebSocket, GraphQL 엔드포인트와 동일한 프로젝트에 배치하며 문서, 협업, 저장된 디버깅 설정까지 포함합니다. 만약 터미널에서 일회성 호출만 필요하다면, 더 가벼운 도구들도 존재하며, 저희도 그것들을 솔직하게 다룰 것입니다. 이 글에서는 BloomRPC와 함께 사라진 것, 무엇으로 대체해야 하는지, 그리고 정확히 어떻게 마이그레이션해야 하는지를 설명합니다.
BloomRPC는 무엇이었고, 왜 사라졌는가
BloomRPC는 클라이언트를 작성하지 않고 gRPC 호출을 수행하는 단 하나의 작업을 위해 2018년에 Electron 데스크톱 앱으로 출시되었습니다. .proto 파일을 가져오면, 서비스와 메서드를 나열하고, 각 요청 메시지에 대한 JSON 스켈레톤을 생성하며, 메타데이터를 편집하고 전송할 수 있게 했습니다. 단항 호출 및 기본적인 스트리밍에 대해 괜찮았고, "괜찮고 무료"라는 점이 수년간 기본 gRPC GUI로 자리매김하게 했습니다.
보관 통지는 그 시대를 깔끔하게 마무리합니다. 보관된 저장소는 버그 수정, 의존성 업데이트, 릴리스가 없음을 의미합니다. Electron 앱의 경우, 이는 중립적인 상태가 아닙니다. 번들된 Chromium 및 Node 버전은 보안 지원에서 벗어나고, 최신 proto 구문 및 gRPC 기능은 처리되지 않으며, 알려진 버그(BloomRPC는 proto 가져오기 및 특정 스트리밍 흐름에 대한 오래된 문제를 가지고 있었습니다)는 그대로 남아 있습니다. 관리자들은 이에 대해 솔직했으며, 이는 많은 사라진 프로젝트들이 해내지 못하는 일입니다. 메시지는 다음과 같습니다: 이 프로그램을 설치하는 것을 중단하십시오.
사람들은 여전히 BloomRPC를 찾는데, 도구의 형태가 올바랐기 때문입니다. 문제는 그 형태(또 다른 독립형 gRPC 창)를 대체할 것인지, 아니면 근본적인 파편화를 해결할 것인지입니다. gRPC를 실행하는 대부분의 팀은 REST도 실행하며, 두 개의 단절된 도구에서 테스트하는 것은 BloomRPC가 조용히 부과했던 세금이었습니다. 저희는 이전에 좋은 gRPC 클라이언트의 조건에 대해 글을 쓴 적이 있습니다. 간단히 말해, "protos 로드, 호출 전송"은 이제 기본 요구 사항이며, 차별점은 그 위에 존재합니다.
답변: Apidog
Apidog는 50만 명 이상의 개발자가 사용하는 API 개발 플랫폼으로, 설계, 디버깅, 테스트, 목업, 문서화를 포괄합니다. 공식 문서에 따르면, Apidog의 gRPC 지원은 BloomRPC가 했던 일과 BloomRPC가 결코 완성하지 못했던 부분을 모두 다룹니다:
- 네 가지 호출 유형 모두. 단항, 서버 스트리밍, 클라이언트 스트리밍, 양방향 스트리밍이 모두 지원됩니다. 스트리밍 호출은 WebSocket 세션처럼 작동합니다. 호출을 열고, 메시지 탭에서 메시지를 작성 및 전송하면 타임라인 보기에서 전송 및 수신된 메시지를 순서대로 보여줍니다. BloomRPC의 스트리밍 지원은 부분적이고 버그가 많았지만, 여기서는 문서화된 기능입니다.
- API 정의를 가져오는 세 가지 방법. 로컬 .proto 파일을 로드하거나, URL에서 가져오거나, 서버 리플렉션을 사용하여 실행 중인 gRPC 서버에서 proto 파일 없이 직접 서비스를 가져올 수 있습니다. proto가 다른 proto에 의존하는 경우, 의존성 디렉토리를 한 번만 추가하면 됩니다.
- JSON 입력, JSON 출력. BloomRPC처럼 Apidog는 protobuf 메시지를 편집 가능한 JSON으로 렌더링하므로, 이진 페이로드를 수동으로 인코딩할 필요가 없습니다. 해당 매핑에 대해 자세히 알아야 한다면, protobuf to JSON을 참조하십시오.
- TLS, 메타데이터, 인증. 요청별로 grpc:// 또는 grpcs://를 토글하고, 실제 서비스가 가진 설정에 맞춰 메타데이터 및 인증 구성을 첨부할 수 있습니다. 토큰 및 mTLS 패턴에 대해서는 저희 gRPC 인증 가이드와 함께 사용하면 좋습니다.
- 막다른 골목이 아닙니다. 저장된 gRPC 호출(서버 URL, 메시지, 메타데이터)은 팀원들과 공유할 수 있으며, REST 엔드포인트, 테스트 시나리오, 게시된 문서와 동일한 작업 공간에 존재합니다. 이는 독립형 gRPC 창이 결코 제공하지 못했던 부분입니다.
기능별 전환 모습
호출하기
일상적인 사용은 익숙하게 느껴질 것입니다. proto를 가져오고, 서비스와 메서드를 선택하고, 생성된 JSON 본문을 편집하고, 서버 주소를 설정하고, 전송합니다. 단항 호출은 응답 창을 반환하고, 스트리밍 호출은 메시지를 푸시하고 타임라인을 보는 세션을 엽니다. 상태 코드는 HTTP와 다르게 읽히는 gRPC 상태 코드로 반환됩니다. 첫 주에는 gRPC 상태 코드 참조를 가까이 두십시오.
스트리밍, 특히
이것이 가장 큰 개선점입니다. BloomRPC의 클라이언트 측 및 양방향 스트리밍은 오랜 문제의 일반적인 원인이었습니다. Apidog는 네 가지 모드를 모두 문서화하고, 스트리밍 호출을 일회성 요청이 아닌 실시간 세션으로 처리합니다. 서비스가 스트림에 의존한다면, 이 차이가 전체 결정의 핵심입니다. 모드 자체에 대한 배경 지식은 gRPC 스트리밍 설명을 참조하십시오.
서버 리플렉션
BloomRPC는 proto 파일을 필요로 했습니다. Apidog는 서버 리플렉션도 지원하므로, 리플렉션이 활성화된 서버를 가리키고 올바른 proto 버전을 찾을 필요 없이 해당 서비스를 탐색할 수 있습니다. 다른 사람이 소유한 스테이징 서버를 빠르게 확인하는 데 가장 번거로운 단계를 제거합니다.
클라이언트를 넘어서
여기가 카테고리 점프입니다. BloomRPC에서는 창을 닫으면 디버깅된 호출이 사라졌습니다. Apidog에서는 gRPC 서비스가 프로젝트 내에 존재합니다. 팀원들은 proto를 다시 가져오고 메타데이터를 다시 입력하는 대신 저장된 디버깅 설정을 재사용하며, 동일한 작업 공간에 REST 및 WebSocket 작업, 자동화된 gRPC API 테스트, HTTP 엔드포인트용 목업, 게시 가능한 문서가 저장됩니다. 대부분의 gRPC 백엔드는 REST 또는 GraphQL도 어딘가에서 제공합니다. 이러한 프로토콜 경계를 고려 중이라면, REST vs GraphQL vs gRPC에서 비교했으며, gRPC vs REST에서 장단점을 자세히 살펴보았습니다.
BloomRPC vs Apidog 한눈에 보기
| BloomRPC | Apidog | |
|---|---|---|
| 상태 | 2023년 1월 보관됨; README: 사용 권장 안 함 | 활발히 개발 중 |
| 단항 호출 | 예 | 예 |
| 서버 / 클라이언트 / 양방향 스트리밍 | 부분적, 알려진 문제 있음 | 모두 지원, 타임라인을 갖춘 세션 스타일 |
| Proto 가져오기 | 로컬 .proto 파일 | 로컬 파일, URL, 서버 리플렉션 |
| TLS | 기본 | 요청당 grpc:// / grpcs:// 토글 |
| 메타데이터 및 인증 | 메타데이터 편집 | 메타데이터 및 인증 구성 |
| 팀 공유 | 없음 (로컬 전용) | 팀 작업 공간에서 저장된 호출 공유 |
| 다른 프로토콜 | gRPC 전용 | REST, WebSocket, SSE, GraphQL, gRPC |
| 문서, 테스트, 목업 | 없음 | 동일한 플랫폼, 동일한 프로젝트 |
| 가격 | 무료 (방치됨) | 최대 4인까지 무료 플랜 |
BloomRPC에서 마이그레이션하기
솔직한 마이그레이션 참고 사항: 내보낼 것이 없습니다. BloomRPC는 의미 있는 휴대 가능한 상태를 유지하지 않았으므로, 떠나는 것이 사소합니다.
- .proto 파일을 모으세요. 그것들은 BloomRPC가 아니라 여러분의 리포지토리에 있습니다. 이것이 "내보내기"의 전부입니다.
- Apidog로 가져오세요. 프로젝트를 생성하고, proto를 추가(또는 해당 URL)하고, proto가 다른 proto를 가져온다면 의존성 디렉토리를 추가하세요. 서비스와 rpc 메서드는 서비스와 메서드로 나타납니다. 또는 파일을 완전히 건너뛰고 실행 중인 서버에 대해 서버 리플렉션을 사용할 수도 있습니다.
- 서버 주소와 TLS를 설정하세요. 대상 URL을 입력하고 grpc:// 또는 grpcs://를 선택하세요.
- 메타데이터와 인증을 다시 만드세요. BloomRPC에 붙여넣었던 헤더와 토큰을 다시 추가하세요. 이번에는 요청과 함께 저장되므로 한 번만 입력하면 됩니다.
- 저장하고 공유하세요. 저장된 호출은 팀의 공유 디버깅 설정이 되며, 이는 여러분이 결코 가질 수 없었던 첫 번째 것을 알아차리게 할 것입니다.
기존 BloomRPC 사용자는 Apidog에서 10분 이내에 호출을 전송할 수 있어야 합니다. 왜냐하면 1단계부터 3단계까지는 이미 알고 있는 동일한 절차이기 때문입니다.
알아둘 만한 다른 BloomRPC 대안
Apidog는 전체 API 플랫폼 내에서 gRPC를 원할 때의 답변입니다. 만약 여러분의 필요가 더 좁다면, 좁은 도구들을 공정하게 평가해 봅시다:
- grpcurl: gRPC용 curl입니다. 쉘 스크립트, CI 검사, 리플렉션이 활성화된 서버에 대한 한 줄 명령에 적합한 도구입니다. GUI는 아니며 GUI인 척하지도 않습니다. 최고의 grpcurl 대안에서 자세히 비교했습니다.
- grpcui: grpcurl의 형제 격으로, 하나의 서버에 대해 임시 웹 UI를 제공합니다. 설계상 저장된 상태 없이 5분 동안 빠르게 확인하는 데 좋습니다.
- Kreya: 세련된 proto 워크플로우와 무료 티어를 갖춘 gRPC 및 REST 전용 데스크톱 클라이언트입니다. 독립형 클라이언트를 특별히 원한다면 BloomRPC의 직접적인 후계자에 가장 가깝습니다. Kreya는 무엇이며, 최고의 Kreya 대안에서 그 한계를 확인하십시오.
- Postman: 2022년에 gRPC 지원을 추가했으므로, 팀이 이미 비용을 지불하고 있다면 사용할 수 있습니다. 일반적인 Postman 가격 및 작업 공간 트레이드오프가 적용되며, 최고의 Postman 대안에서 다루었습니다.
- evans: 대화형 모드를 갖춘 gRPC용 터미널 REPL입니다. tmux에서 작업하는 사람들에게 사랑받지만, BloomRPC의 GUI를 원했던 사람들에게는 시작하기 어렵습니다.
패턴: 자동화를 위한 CLI, 고립된 gRPC 작업을 위한 단일 목적 GUI, 그리고 gRPC가 여러 프로토콜 중 하나이고 호출, 테스트, 문서를 한 곳에서 원할 때의 Apidog.
자주 묻는 질문
BloomRPC는 여전히 유지보수되고 있습니까?
아닙니다. 저장소는 2023년 1월 4일에 보관되었으며, README에는 더 이상 사용을 권장하지 않는다고 명시되어 있습니다. 업데이트, 보안 수정 또는 릴리스는 없습니다. 현재의 gRPC 클라이언트 비교에서는 새로운 설정에 대한 옵션으로 제외되어야 합니다.
BloomRPC 설정을 Apidog로 가져올 수 있습니까?
BloomRPC는 휴대 가능한 것을 저장하지 않았으므로 가져오기 파일이 없습니다. 마이그레이션은 리포지토리에서 .proto 파일을 다시 가져오거나(또는 서버 리플렉션을 사용하여), 서버 주소, TLS 스키마 및 메타데이터를 설정하는 것을 의미합니다. 10분짜리 작업이며, 그 후에는 구성이 한 컴퓨터에 갇히지 않고 저장되고 공유 가능합니다.
Apidog는 gRPC 스트리밍을 지원합니까?
예, 단항, 서버 스트리밍, 클라이언트 스트리밍, 양방향 스트리밍의 네 가지 호출 유형을 모두 지원합니다. 스트리밍 호출은 메시지를 보내고 트래픽 타임라인을 볼 수 있는 라이브 세션으로 실행됩니다. 각 모드가 언제 적합한지에 대한 복습은 gRPC 스트리밍을 참조하십시오.
간단한 명령줄 gRPC 호출만 필요하다면 어떻게 해야 합니까?
grpcurl을 사용하십시오. 특히 리플렉션이 활성화된 서버에 대해 스크립트 및 즉석 호출을 잘 처리하며, 어떤 GUI를 선택하든 CI에 포함되어야 합니다. 저희 grpcurl 대안 가이드는 그것이 충분하지 않은 지점을 다룹니다.
동일한 도구에서 gRPC 및 REST API를 테스트할 수 있습니까?
Apidog에서는 가능합니다. gRPC, REST, WebSocket, SSE, GraphQL이 하나의 프로젝트에 존재하므로, gRPC와 REST 인터페이스를 모두 노출하는 서비스는 하나의 집을 갖게 됩니다. gRPC API 테스트 가이드는 워크플로우를 처음부터 끝까지 보여줍니다.
보관된 클라이언트 폐기하기
BloomRPC는 떠나라고 말했습니다. 유일한 질문은 어디로 갈 것인가입니다. Apidog에 .proto 파일이나 리플렉션이 활성화된 서버를 지정하고, 첫 단항 및 스트리밍 호출을 수행한 다음, 나머지 API 작업 옆에 저장해 두십시오. Apidog를 무료로 다운로드하십시오. 4명으로 구성된 팀은 아무것도 지불할 필요가 없으며, proto 파일은 필요한 유일한 마이그레이션 파일입니다.