DEV Community

Cover image for grpcurlの代わりに使えるgRPC APIテストツールおすすめ (GUI・CLI対応)
Akira
Akira

Posted on • Originally published at apidog.com

grpcurlの代わりに使えるgRPC APIテストツールおすすめ (GUI・CLI対応)

grpcurlはgRPCサービスを操作するための頼れるコマンドラインツールですが、フラグだらけのコマンドだけでは、API探索、ストリーミング呼び出しの確認、チームメイトとのリクエスト共有を効率化しにくい場面があります。ビジュアルなgRPCクライアントや、単発のメソッド実行以上の機能が必要な場合に備えて、この記事ではgrpcurlの代替となる6つのツールを、実装時の使い分けにフォーカスして解説します。

今すぐApidogを試す

grpcurlとは何か、そして限界はどこにあるか

grpcurlは、gRPC版のcurlです。サーバーを指定し、サービス名とメソッド名を渡し、JSON形式のリクエストボディを送るとレスポンスを取得できます。

たとえば、サーバーリフレクションが有効なgRPCサーバーでサービス一覧を確認する場合は、次のように実行します。

grpcurl -plaintext localhost:50051 list
Enter fullscreen mode Exit fullscreen mode

特定のサービスのメソッドを確認する場合は、次のようにします。

grpcurl -plaintext localhost:50051 list helloworld.Greeter
Enter fullscreen mode Exit fullscreen mode

単項RPCを呼び出す例です。

grpcurl \
  -plaintext \
  -d '{"name":"Alice"}' \
  localhost:50051 \
  helloworld.Greeter/SayHello
Enter fullscreen mode Exit fullscreen mode

grpcurlはサーバーリフレクションをサポートしているため、.protoファイルを渡さなくてもサービスやメソッドをリストできます。リフレクションが無効な場合でも、TLS、メタデータヘッダー、.protoファイル、またはプロトセット記述子を指定して利用できます。

grpcurl \
  -proto ./helloworld.proto \
  -H "authorization: Bearer $TOKEN" \
  -d '{"name":"Alice"}' \
  api.example.com:443 \
  helloworld.Greeter/SayHello
Enter fullscreen mode Exit fullscreen mode

grpcurlは、ヘルスチェックやCIでのスクリプト実行には非常に向いています。一方で、次のような作業では不便さが出やすくなります。

  • CLI専用であること。API探索では、メソッド一覧をターミナルで読み、JSONを手入力する必要があります。
  • ストリーミング操作が視覚的ではないこと。クライアント、サーバー、双方向ストリーミングは可能ですが、標準入力と標準出力を使うため、メッセージ単位の確認がしづらいです。
  • リクエストが保存されないこと。コレクション、履歴、環境切り替えは組み込みではありません。
  • チーム共有がコマンド文字列の共有になりやすいこと。ワークスペースや保存済みサンプルは自前で管理する必要があります。

つまり、grpcurlは悪いツールではありません。用途が明確なCLIツールです。単発のスクリプト実行を超えて、探索、保存、共有、ストリーミング確認が必要になった場合は、以下の代替ツールを検討するとよいでしょう。

grpcurlの代替ツール一覧

ツール インターフェース ストリーミングサポート リフレクション 最適な用途
Apidog GUI（デスクトップ） 単方向 + サーバー、クライアント、双方向 あり REST、GraphQL、ドキュメントと並行したビジュアルなgRPCテスト
grpcui Web UI 単方向 + ストリーミング あり grpcurlのブラウザフロントエンド、同じ作者
Postman GUI（デスクトップ/Web） 単方向 + ストリーミング あり すでにPostmanを標準化しているチーム
Kreya GUI（デスクトップ） 単方向 + ストリーミング あり gRPCとRESTに特化したデスクトップクライアント
Evans インタラクティブCLI 単方向 + ストリーミング あり REPLスタイルのターミナルワークフロー
BloomRPC GUI（デスクトップ） 単方向 + ストリーミング 限定的 レガシープロジェクトのみ（メンテナンス終了）

1. Apidog（ビジュアルgRPCクライアント）

Apidogは、REST、GraphQL、WebSocket、SOAP、gRPCを1つのデスクトップアプリで扱えるAPIプラットフォームです。gRPCについては、.protoファイルをインポートするか、サーバーリフレクション経由で接続して、サービスとメソッド定義を読み取れます。

実装時の基本フローは次のとおりです。

  1. Apidogでプロジェクトを開く
  2. gRPC APIを追加する
  3. .protoファイルをインポートする、またはサーバーリフレクションで接続する
  4. サービス一覧からメソッドを選択する
  5. 生成されたフォームでリクエストメッセージを編集する
  6. メタデータや認証情報を設定する
  7. 単方向RPCまたはストリーミングRPCを実行する
  8. レスポンスパネルでメッセージを確認する

フォーム駆動型のリクエストビルダーを使えるため、メソッドはクリック可能なリストとして表示され、リクエストメッセージはプロトスキーマに基づく編集可能なフィールドとして扱えます。レスポンスも整形された状態で確認できます。

Apidogでは、次の4種類のgRPC呼び出しを扱えます。

  • 単方向RPC
  • サーバーサイドストリーミング
  • クライアントサイドストリーミング
  • 双方向ストリーミング

特にサーバーサイドストリーミングでは、メッセージが到着するたびにレスポンスパネルで確認できます。grpcurlでは標準出力を追う作業になるため、ストリームの挙動を視覚的に確認したい場合はGUIの方が扱いやすくなります。

注意点として、ApidogはGUIのgRPCクライアントであり、grpcurlの1対1のCLI代替ではありません。シェルパイプラインに組み込むスクリプト可能なバイナリが必要な場合は、grpcurlやEvansの方が適しています。

Apidogが向いているのは、次のようなケースです。

  • 初見のgRPCサービスを探索したい
  • リクエスト例を保存したい
  • 環境ごとにエンドポイントやメタデータを切り替えたい
  • gRPC、REST、GraphQLを同じワークスペースで扱いたい
  • チームメンバーとリクエストを共有したい

複数プロトコルにまたがるサービスを構築している場合は、マルチプロトコルAPIワークフローも確認しておくと、RESTやGraphQLとgRPCを同じ流れで扱いやすくなります。

Apidogをダウンロードして、.protoファイルをインポートし、GUIで最初のストリーミング呼び出しを実行できます。

2. grpcui

grpcuiは、grpcurlと同じ作者であるfullstorydevによって提供されています。grpcurlの機能に近い操作を、ブラウザ上のフォームUIで実行したい場合に適したツールです。

grpcuiはローカルのWebサーバーを起動し、ブラウザからgRPCメソッドを呼び出せるフォームを提供します。サービスやメソッドのドロップダウン、リクエストメッセージ用の生成フォーム、メタデータ入力などが、サーバーリフレクションまたはプロト記述子に基づいて表示されます。

典型的な起動例は次のとおりです。

grpcui -plaintext localhost:50051
Enter fullscreen mode Exit fullscreen mode

リフレクションが無効な場合は、.protoファイルを指定します。

grpcui \
  -plaintext \
  -proto ./helloworld.proto \
  localhost:50051
Enter fullscreen mode Exit fullscreen mode

grpcuiはストリーミングもサポートしており、grpcurlファミリーに期待されるgRPC機能をブラウザUIで扱えます。

一方で、grpcuiは単一目的のツールです。gRPCエクスプローラとしては便利ですが、RESTテスト、セッションをまたいだコレクション保存、チームワークスペースなどはありません。単一のgRPCサーバーをすばやくブラウザで確認したい場合に向いています。

セットアップの詳細は、grpcuiのリポジトリを参照してください。

3. Postman

PostmanはgRPCサポートを追加しています。チームがすでにPostmanを標準ツールとして使っている場合は、別のツールを導入する前にPostmanのgRPC機能を試す価値があります。

基本的な流れは次のとおりです。

  1. PostmanでgRPCリクエストを作成する
  2. gRPCサーバーのアドレスを指定する
  3. .protoをロードする、またはリフレクション対応サーバーに接続する
  4. メソッドを選択する
  5. メタデータや認証を設定する
  6. 単方向またはストリーミング呼び出しを実行する
  7. リクエストをコレクションに保存する

Postman gRPC UI

Postmanの強みは、既存のコレクション、環境、ワークスペースと連携できる点です。チームがすでにPostmanを使い慣れている場合、gRPCだけ別ツールに分けずに済む可能性があります。

一方で、PostmanにおけるgRPC体験は、REST向けの体験と比べると洗練度が劣る場面があります。また、Postmanの利用形態によっては、クラウド同期や料金面の検討が必要です。

より広範なツール比較をしたい場合は、APIテストのためのPostman代替ツールのまとめも参考になります。Postman自身のgRPCドキュメントでは、現在の機能セットが説明されています。

4. Kreya

Kreyaは、gRPCとRESTに特化したデスクトップクライアントです。.protoファイルの読み取り、サーバーリフレクション、スキーマからのリクエストフォーム生成、ストリーミングモードの処理をサポートしています。

実装時の使い方はシンプルです。

  1. Kreyaでプロジェクトを作成する
  2. .protoファイルを追加する、またはリフレクションで接続する
  3. サービスとメソッドを選択する
  4. 環境変数やメタデータを設定する
  5. リクエストを送信する
  6. レスポンスを確認し、必要に応じてリクエストを保存する

Kreya gRPC UI

Kreyaは、クリーンなプロジェクトベースのレイアウトに重点を置いています。呼び出しの整理、環境設定、変数の再利用がしやすいため、専用のgRPC GUIを使いたい場合に選択肢になります。

完全なAPIプラットフォームと比べると、機能範囲は狭めです。モック機能、ドキュメント生成、設計支援のような領域までまとめて扱うツールではありません。ただし、主にgRPCサービスを探索・テストしたい開発者にとっては、この集中した機能範囲が利点になります。

5. Evans

Evansは、ターミナル内で動作するインタラクティブなgRPCクライアントです。単発コマンドというより、REPLのように操作できます。

セッションを開始すると、Evansはパッケージ、サービス、メソッドの閲覧、リクエストの組み立て、送信を対話的に進められます。サーバーリフレクションと.protoファイルをサポートし、ストリーミングも扱えます。

リフレクションを使って接続する例です。

evans --host localhost --port 50051 --reflection repl
Enter fullscreen mode Exit fullscreen mode

.protoファイルを指定する例です。

evans \
  --proto ./helloworld.proto \
  --host localhost \
  --port 50051 \
  repl
Enter fullscreen mode Exit fullscreen mode

REPL内では、パッケージやサービスを選択し、メソッドを呼び出します。

> package helloworld
> service Greeter
> call SayHello
Enter fullscreen mode Exit fullscreen mode

grpcurlのターミナルネイティブな操作感は好きだが、長いコマンドやフラグを毎回入力したくない場合、Evansは中間的な選択肢になります。

ただし、EvansもCLIツールです。視覚的なストリーミング表示や共有ワークスペースはありません。インタラクティブモードによってgrpcurlの不便さを一部解消するツールとして考えるとよいでしょう。

インストール手順は、EvansのGitHubリポジトリにあります。

6. BloomRPC（レガシー専用）

BloomRPCは、かつて人気のあったオープンソースのgRPC GUIです。メソッドエクスプローラーとリクエストエディターを備えたデスクトップアプリとして、多くの古いガイドで紹介されています。

ただし、BloomRPCは現在活発にメンテナンスされていません。これは、新しいgRPC機能、依存関係の更新、OS互換性の修正が期待できないことを意味します。

新規プロジェクトでBloomRPCを選ぶのは避けた方がよいでしょう。既存のワークフローがBloomRPCに依存している場合は、上記のメンテナンスされているツールへの移行を計画してください。

選び方

ツールは、実際の作業フローに合わせて選ぶのが最も重要です。

  • 視覚的にストリーミングを監視し、リクエストを保存・共有したい場合：Apidog
  • grpcurlが好きで、その上にブラウザフォームが欲しい場合：grpcui
  • チームがすでにPostmanを標準化している場合：PostmanのgRPCサポート
  • gRPCとRESTに集中したデスクトップクライアントが欲しい場合：Kreya
  • ターミナルにとどまりたいが、長いフラグ入力を避けたい場合：Evans
  • レガシー環境を維持している場合：BloomRPCがメンテナンス終了していることを理解し、移行を計画する

実務では、次のように使い分けると判断しやすくなります。

CIやヘルスチェックで使う
  -> grpcurl

gRPC APIをブラウザで素早く探索する
  -> grpcui

GUIで保存済みリクエスト、環境、ストリーミングを扱う
  -> Apidog / Kreya / Postman

ターミナルで対話的に操作する
  -> Evans

古い既存環境を維持するだけ
  -> BloomRPC
Enter fullscreen mode Exit fullscreen mode

gRPCをエンドツーエンドでテストし、メソッドごとの詳細な流れを確認したい場合は、gRPC APIを効率的にテストする方法のガイドも参考になります。コマンドラインにこだわる場合は、オリジナルのgrpc-curlウォークスルーが出発点になります。

よくある質問

grpcurlのGUI版はありますか？

同じ作者によるgrpcuiが、最も近い直接的なGUIです。grpcurlが利用するリフレクションとプロトハンドリングの上に、ブラウザフォームを提供します。

保存されたリクエスト、環境、視覚的に確認できるストリーミングが必要な場合は、Apidogのようなデスクトップクライアントを検討するとよいでしょう。ApidogではRESTやGraphQLと並行してgRPCを扱えます。

コマンドラインを使わずにgRPCストリーミングをテストできますか？

はい、できます。Apidog、Postman、Kreya、grpcuiはいずれもUIを通じてgRPCストリーミングをサポートしています。サーバーサイドストリーミングでは、メッセージが到着するたびに画面上で確認できます。

grpcurlとEvansもストリーミングに対応していますが、メッセージの入力と表示はターミナル上で行います。

これらのツールには.protoファイルが必要ですか？

常に必要というわけではありません。ここで紹介したツールはgRPCサーバーリフレクションをサポートしています。サーバーがリフレクションを公開していれば、クライアントはサービスとメソッドを自動的に発見できます。

リフレクションが無効な場合は、.protoファイルまたはコンパイル済みのプロトセットを指定します。

APIテスト全体の中でgRPCをどう位置づけるかを確認したい場合は、APIテストの究極ガイドも参考になります。

grpcurlはまだ使う価値がありますか？

適切な用途であれば、十分に価値があります。grpcurlは、スクリプト化された呼び出し、CIチェック、ターミナルからの単発実行に向いています。

一方で、単一のコマンドだけでは不十分になり、視覚的な探索、保存されたコレクション、監視可能なストリーミング、共有ワークスペースが必要になった場合は、GUIやインタラクティブCLIの代替ツールが役立ちます。

結論

grpcurlは、コマンドラインでgRPCを扱うための鋭いツールです。スクリプト化されたターミナルネイティブな呼び出しでは、今でも有力な選択肢です。

ただし、作業内容がAPI探索、ストリーム監視、リクエスト保存、チーム共有に広がると、ビジュアルクライアントの方が効率的になります。GUIオプションの中でもApidogは、gRPC、REST、GraphQL、モック、ドキュメントを1か所で扱えるため、gRPCテストを他のAPI作業から分離せずに進められます。

フラグを書かずにgRPCサービスをテストしたい場合は、Apidogを無料で試して、.protoをインポートするかリフレクション経由で接続し、GUIで単方向およびストリーミング呼び出しを実行してみてください。

Top comments (0)