最佳 BloomRPC 替代方案

BloomRPC 曾是每个 gRPC 开发者最终都会问的一个问题的答案：“针对 gRPC 的 Postman 在哪里？”导入一个 .proto 文件，获取可编辑的 JSON 请求 body，点击发送。它很简单，免费，并且凭借着做好这一件事，在 GitHub 上获得了约 9,000 个 Star。然而，在 2023 年 1 月 4 日，该仓库被归档了。README 中的措辞直言不讳：项目停滞不前，issue 堆积如山，维护者现在明确表示“不再建议使用它”。他们让你去参考 awesome-grpc 列表，并祝你好运。

答案显而易见：对于大多数团队来说，Apifox 是最佳的 BloomRPC 替代方案，因为它不仅仅是替代了一个加载 .proto 的窗口。它支持所有四种 gRPC 调用类型（一元调用、服务端流式、客户端流式和双向流式），支持从本地路径、URL 或服务端反射导入 .proto 文件，并将你的 gRPC 工作与 REST、WebSocket 和 GraphQL 接口整合在同一个项目中，同时包含文档、协作和保存的调试设置。如果你只需要从终端进行一次临时调用，也有更轻量级的工具，我们也会对此进行客观介绍。本文将阐述随着 BloomRPC 的终结逝去了什么、用什么来替代它，以及具体如何进行迁移。

BloomRPC 是什么，以及它为何不复存在

BloomRPC 于 2018 年作为一款 Electron 桌面应用发布，其核心任务只有一个：无需编写客户端即可进行 gRPC 调用。你导入 .proto 文件，它会列出服务和方法，为每个请求消息生成 JSON 骨架，并允许你编辑元数据并发送。对于一元调用和基本的流式传输，它的表现尚可，而“好用且免费”让它在多年来成为了默认的 gRPC GUI。

归档声明干净利落地结束了那个时代。归档的仓库意味着没有 Bug 修复、没有依赖更新，也没有版本发布。对于一个 Electron 应用来说，这并不是一个中立的状态：捆绑的 Chromium 和 Node 版本会超出安全支持期限，更新的 proto 语法和 gRPC 特性无法得到处理，而已知的 Bug（BloomRPC 在 proto 导入和某些流式传输流程上存在长期未解决的问题）也将永远无法修复。维护者对此很坦诚，这比许多无疾而终的项目做得更好。他们传达的信息是：停止安装此软件。

人们仍然在寻找 BloomRPC，是因为该工具的形式是正确的。问题在于，你是去寻找一个相同形式的替代品（另一个独立的 gRPC 窗口），还是去解决底层的碎片化问题：大多数运行 gRPC 的团队同时也运行 REST，而在两个相互孤立的工具中测试它们，一直是使用 BloomRPC 默默付出的代价。我们之前曾写过什么是优秀的 gRPC 客户端；简而言之，“加载 proto 并发送调用”现在只是基本要求，而差异化的竞争优势在于此之上。

答案是：Apifox

Apifox 是一个拥有超过 50 万开发者使用的 API 开发平台，涵盖了设计、调试、测试、mock 和文档。根据官方文档，它对 gRPC 的支持不仅涵盖了 BloomRPC 的所有功能，还完成了 BloomRPC 未能实现的遗留部分：

支持全部四种调用类型。 支持单向调用（Unary）、服务端流式（server streaming）、客户端流式（client streaming）和双向流式（bidirectional streaming）。流式调用类似于 WebSocket 会话：建立调用连接后，你可以通过“Message”标签页编写并发送消息，同时时间线视图会按顺序展示已发送和已接收的消息。BloomRPC 的流式支持并不完整，且在后期存在不少 Bug；而在这里，它是一项有文档支持的标准功能。
三种导入接口定义/规范的方式。 支持加载本地 .proto 文件、从 URL 导入，或者使用服务端反射（server reflection）直接从运行中的 gRPC 服务端拉取服务，无需准备 proto 文件。如果你的 proto 文件依赖其他 proto 文件，只需添加一次依赖目录即可。
JSON 输入，JSON 输出。 与 BloomRPC 类似，Apifox 将 protobuf 消息渲染为可编辑的 JSON，因此你无需手动编码二进制负载。如果你需要了解这一映射关系，请参阅 protobuf 转换为 JSON 的相关内容。
TLS、metadata 和 auth。 支持为每个请求切换 grpc:// 或 grpcs://，并为真实服务中实际存在的配置添加 metadata 和 auth 配置。对于 Token 和 mTLS 模式，我们的 gRPC 身份验证指南可以与此配合使用。
绝非孤立的工具。 保存的 gRPC 调用（服务端 URL、消息、metadata）可以与团队成员共享，并且它们与你的 REST 接口、测试场景以及已发布的文档共存于同一个工作区。这是任何独立的 gRPC 客户端窗口都无法提供的功能。

各项功能对比与迁移体验

发起调用

日常使用体验非常熟悉。导入 proto 文件，选择服务和方法，编辑生成的 JSON body，设置服务端地址，发送即可。单向调用（Unary）会返回响应面板；流式调用则会开启一个会话，供你推送消息并查看时间线。状态码将以 gRPC 状态码的形式返回，这与 HTTP 状态码有所不同；建议在第一周时将 gRPC 状态码参考指南保存在手边。

尤其是流式调用

这是最明显的升级。BloomRPC 的客户端流式和双向流式是其 Open Issues 的常见来源。Apifox 针对所有四种模式都提供了完备的文档支持，并将流式调用视为一个实时的会话，而不仅仅是单次请求。如果你的服务严重依赖流式传输，这一区别将起决定性作用；若要了解这些模式的背景知识，请参阅 gRPC 流式传输详解。

服务端反射

BloomRPC 必须依赖 proto 文件。而 Apifox 还支持服务端反射，因此你可以将其指向启用了反射的服务端，并直接浏览其服务，而无需到处寻找正确的 proto 版本。对于快速调试他人维护的测试环境服务端，这省去了最繁琐的步骤。

不仅仅是客户端

这就是品类上的跨越。在 BloomRPC 中，一旦关闭窗口，调试过的调用就会烟消云散。而在 Apifox 中，gRPC 服务都收纳在项目中：团队成员可以复用您保存的调试配置，而无需重新导入 proto 文件和重新输入元数据。同时，同一个工作空间还可以容纳您的 REST 和 WebSocket 工作、自动化的 gRPC API 测试、针对 HTTP 接口的 mock，以及可发布的文档。大多数 gRPC 后端在某些地方也会提供 REST 或 GraphQL 服务；如果您正在权衡这些协议的边界，我们在 [REST vs GraphQL vs gRPC](REST vs GraphQL vs gRPC) 中进行了对比，并在 [gRPC vs REST](gRPC vs REST) 中深入探讨了它们之间的权衡。

BloomRPC vs Apifox 一览

从 BloomRPC 迁移

坦白地说：其实没有什么需要导出的。BloomRPC 没有保留任何有意义的、可移植的状态，这使得迁移过程变得非常简单：

收集您的 .proto 文件。 它们存在于您的代码仓库中，而不是 BloomRPC 中。这就是全部的“导出”工作。
导入到 Apifox。 创建一个项目，添加 proto 文件（或其 URL），如果您的 proto 文件导入了其他文件，还要添加依赖目录。服务和 rpc 方法会直接显示为服务和方法。或者，您也可以完全跳过文件，直接对运行中的服务端使用服务端反射。
设置服务端地址和 TLS。 输入目标 URL 并选择 grpc:// 或 grpcs://。
重新创建元数据和 auth。 重新添加您曾复制粘贴到 BloomRPC 中的 header 和 Token。这次它们将随请求一起保存，因此您只需输入一次。
保存并共享。 保存的调用将成为团队共享的调试配置，这绝对是您之前未曾体验过的核心功能。

对于已经熟悉 BloomRPC 的用户来说，在十分钟内就能用 Apifox 发送请求，因为步骤 1 到 3 与您之前熟知的操作完全一样。

其他值得了解的 BloomRPC 替代方案

如果您希望在一个完整的 API 平台中管理 gRPC，那么 Apifox 就是您的不二之选。如果您的需求比较单一，我们也可以客观地看一看那些功能专一的工具：

grpcurl：gRPC 领域的 curl。适合编写 Shell 脚本、CI 检查以及针对启用反射的服务端执行单行命令的绝佳工具；它不是 GUI，也无意成为 GUI。我们在最适合的 grpcurl 替代方案中对其进行了深入对比。
grpcui：grpcurl 的同胞兄弟，可为单个服务端提供临时的 Web UI。适合用来进行五分钟的快速体验，其设计本身就不保存任何状态。
Kreya：一款专为 gRPC 和 REST 设计的桌面客户端，拥有流畅的 proto 工作流并提供免费版本。如果你明确需要一个独立客户端，它是最接近 BloomRPC 直接继承者的选择。请参阅什么是 Kreya以及最适合的 Kreya 替代方案，以了解其局限性。
Postman：于 2022 年添加了对 gRPC 的支持，所以如果你的团队已经付费订阅了该服务，它也是可用的；但需要权衡 Postman 常规的定价和工作区限制，这在最适合的 Postman 替代方案中有详细讨论。
evans：一款支持交互模式的 gRPC 终端 REPL。深受 tmux 用户的喜爱；但对于想要 BloomRPC 那种 GUI 界面的用户来说，则完全不适合。

总结其规律：命令行工具（CLI）用于自动化，单一用途的 GUI 用于独立的 gRPC 工作，而当 gRPC 只是你所使用的多种协议之一，且你希望将调用、测试和文档整合在一处时，Apifox 则是最佳选择。

常见问题

BloomRPC 还在维护吗？

不在维护。该仓库已于 2023 年 1 月 4 日归档，其 README 也声明不再推荐使用。它不会再有任何更新、安全修复或新版本发布。当前任何关于 gRPC 客户端的对比都应该将其排除在新项目的选择之外。

我可以将 BloomRPC 的配置导入到 Apifox 中吗？

由于 BloomRPC 没有存储任何可导出的数据，因此没有对应的导入文件。迁移意味着需要从你的仓库中重新导入 .proto 文件（或使用服务端反射），然后设置服务端地址、TLS 方案和元数据（metadata）。这只需要十分钟左右的时间，完成后配置就会被保存并可供团队共享，而不会被局限在单台机器上。

Apifox 支持 gRPC 流式传输（streaming）吗？

支持，Apifox 支持所有四种调用类型：简单 RPC（unary）、服务端流式传输（server streaming）、客户端流式传输（client streaming）和双向流式传输（bidirectional streaming）。流式调用作为实时会话运行，在此期间你可以发送消息并查看流量时间线。若想复习各个模式的适用场景，请参阅 gRPC 流式传输（streaming）。

如果我只需要快速通过命令行调用 gRPC 该怎么办？

使用 grpcurl。它能很好地处理脚本化和临时调用，尤其是在针对启用了反射的服务端时。无论你选择哪款 GUI，它都非常适合集成到 CI 中。我们的 grpcurl 替代方案指南介绍了它在哪些场景下会显得力不从心。

我可以在同一个工具中测试 gRPC 和 REST API 吗？

在 Apifox 中完全可以：gRPC、REST、WebSocket、SSE 和 GraphQL 都存放在同一个项目中，因此同时提供 gRPC 和 REST 接口的服务可以统一管理。我们的测试 gRPC API 指南完整展示了这一工作流。

停用已归档的客户端

BloomRPC 已经退场，唯一的问题是该何去何从。只需将 Apifox 指向你的 .proto 文件或启用反射的服务端，即可发起首次一元调用和流式调用，并将它们与你其他的 API 工作一起保存。免费下载 Apifox；4 人及以下团队无需支付任何费用，而你的 proto 文件就是你唯一需要的迁移文件。