リフレクション

概要

リフレクションは、gRPCサーバーがエクスポートするProtobufで定義されたAPIを、標準化されたRPCサービスを通じて宣言するために使用できるプロトコルです。これには、リクエストメッセージとレスポンスメッセージによって参照されるすべての型が含まれます。クライアントは、この情報を使用して、人間が読める形式でリクエストをエンコードし、レスポンスをデコードできます。

リフレクションは、grpcurlやPostmanのようなデバッグツールで広く使用されています。RESTの世界から来た人は、gRPCリフレクションAPIを、REST APIを記述しているHTTPサーバーでOpenAPIドキュメントを提供することと比較するかもしれません。

透明性と解釈可能性

gRPCの優れたパフォーマンスに大きく貢献しているのは、シリアライゼーションにProtobufを使用していることです。これはバイナリであり、人間が読めないプロトコルです。これによりRPCは大幅に高速化されますが、サーバーとの手動でのやり取りがより困難になる可能性もあります。理論上、curlを使用してHTTP/2経由でサーバーにgRPCリクエストを手動で送信するには、次のような手順が必要になります。

1. サーバーが公開しているRPCサービスを知ること。
2. リクエストメッセージのProtobuf定義と、それが参照するすべての型を知ること。
3. レスポンスメッセージと、それが参照するすべての型のProtobuf定義を知ること。

その後、その知識を使用して、リクエストメッセージをバイナリ形式で手作業で作成し、レスポンスメッセージを慎重にデコードする必要があります。これは時間がかかり、イライラし、エラーが発生しやすい作業です。代わりに、リフレクションプロトコルにより、ツールはこのプロセス全体を自動化できるようになり、目に見えなくなります。

gRPCサーバーでリフレクションを有効にする

リフレクションはgRPCサーバーで自動的に有効にされるわけではありません。サーバーの作成者は、リフレクションサービスを追加するために、いくつかの追加関数を呼び出す必要があります。これらのAPI呼び出しは言語によって若干異なり、一部の言語ではgrpc-reflectionのような名前の別のパッケージへの依存関係を追加する必要があります。

お使いの言語の詳細については、以下のリンクを参照してください。

ヒント

grpcurlなどのツールでは、リフレクションは非常にシームレスに動作するため、多くの人がそれが裏側で起こっていることに気づいていません。しかし、リフレクションが公開されていない場合、物事はまったくシームレスには機能しません。代わりに、クライアントは厄介なエラーで失敗します。これは、gRPCサービスのルーティング設定を書く際によく発生します。リフレクションサービスも、アプリケーションのメインRPCサービスと同様に、適切なバックエンドにルーティングする必要があります。

gRPC APIが一般ユーザーに公開されている場合、リフレクションサービスを公開したくない場合があります。これはセキュリティ上の問題と見なされる可能性があるためです。最終的には、あなたとあなたのユーザーにとって、セキュリティと使いやすさの最適なバランスをとる決定を下す必要があります。