gRPC-Web が一般提供開始

gRPC-Web の GA (General Availability) リリースを発表できることを嬉しく思います。gRPC-Web は、Web アプリケーションが HTTP サーバーを仲介役として必要とせずに、gRPC バックエンドサービスと直接通信できるようにする JavaScript クライアントライブラリです。「GA」とは、gRPC-Web が一般提供可能になり、安定しており、本番環境での使用に適格であることを意味します。

gRPC-Web を使用すると、Protocol Buffers でクライアント側とサーバー側のデータ型およびサービスインターフェイスを定義することで、真のエンドツーエンド gRPC アプリケーションアーキテクチャを簡単に構築できます。これは以前から強く要望されていた機能であり、ついに本番環境で使用できる準備が整いました。さらに、gRPC サービスにアクセスできるようになったことで、Web ベースのツール を gRPC の周りで構築するためのエキサイティングな新しい可能性が開かれました。

基本

gRPC-Web は、gRPC と同様に、クライアント（Web）とバックエンド gRPC サービス間のサービス「契約」を Protocol Buffers を使用して定義できます。クライアントはその後、自動生成できます。これを行うには、Closure コンパイラ、またはより広く使用されている CommonJS のいずれかを選択できます。この開発プロセスにより、カスタム JSON シリアライゼーションおよびデシリアライゼーションロジックの作成、HTTP ステータスコードの管理（REST API によって異なる場合があります）、コンテンツタイプネゴシエーションの管理などの懸念事項を管理する必要がなくなります。

より広範なアーキテクチャの観点から見ると、gRPC-Web はエンドツーエンド gRPC を可能にします。以下の図はこのことを示しています。

図 1. gRPC-Web を使用した gRPC（左）と REST を使用した gRPC（右）

左側の gRPC-Web の世界では、クライアントアプリケーションが Protocol Buffers を使用してバックエンド gRPC サーバーと通信し、そのサーバーが他の gRPC バックエンドサービスと Protocol Buffers で通信します。右側の REST の世界では、Web アプリケーションが HTTP を使用してバックエンド REST API サーバーと通信し、そのサーバーがバックエンドサービスと Protocol Buffers で通信します。

gRPC-Web を使用する利点

gRPC-Web は、今後も機能セットを拡充していく予定ですが、現時点での 1.0 の機能は以下の通りです。

• エンドツーエンド gRPC — Protocol Buffers を使用して RPC パイプライン全体を構築できます。クライアントリクエストが HTTP サーバーに送信され、そのサーバーが 5 つのバックエンド gRPC サービスとやり取りするシナリオを想像してみてください。HTTP インタラクションレイヤーの構築に、パイプラインの残りの部分全体を構築するのと同等以上の時間を費やすことになる可能性が高いです。
• フロントエンドとバックエンドチーム間の緊密な連携 — RPC パイプライン全体が Protocol Buffers を使用して定義されるため、「マイクロサービスチーム」と「クライアントチーム」を別々に配置する必要がなくなります。クライアントとバックエンドのやり取りは、他の gRPC レイヤーの 1 つにすぎません。
• クライアントライブラリの簡単な生成 — gRPC-Web を使用すると、外部の世界とやり取りするサーバー、つまりバックエンドスタックとインターネットを接続する膜が、HTTP サーバーではなく gRPC サーバーになります。つまり、サービスすべてのクライアントライブラリを gRPC ライブラリにすることができます。Ruby、Python、Java、およびその他の 4 つの言語のクライアントライブラリが必要ですか？これらすべてに対して HTTP クライアントを記述する必要はもうありません。

gRPC-Web の例

前のセクションでは、大規模アプリケーションにおける gRPC-Web の高レベルな利点の一部を説明しました。次に、簡単な TODO アプリの例で、より詳細を見ていきましょう。gRPC-Web では、次のような単純な `todos.proto` 定義から開始できます。

syntax = "proto3";

package todos;

message Todo {
  string content = 1;
  bool finished = 2;
}

message GetTodoRequest {
  int32 id = 1;
}

service TodoService {
  rpc GetTodoById (GetTodoRequest) returns (Todo);
}

この `.proto` 定義から CommonJS クライアントサイドコードを生成するには、次のコマンドを使用します。

protoc echo.proto \
  --js_out=import_style=commonjs:./output \
  --grpc-web_out=import_style=commonjs:./output

バックエンド gRPC サービスから TODO のリストを取得することは、次のように簡単です。

const {GetTodoRequest} = require('./todos_pb.js');
const {TodoServiceClient} = require('./todos_grpc_web_pb.js');

const todoService = new proto.todos.TodoServiceClient('https://:8080');
const todoId = 1234;

var getTodoRequest = new proto.todos.GetTodoRequest();
getTodoRequest.setId(todoId);

var metadata = {};
var getTodo = todoService.getTodoById(getTodoRequest, metadata, (err, response) => {
  if (err) {
    console.log(err);
  } else {
    const todo = response.todo();
    if (todo == null) {
      console.log(`A TODO with the ID ${todoId} wasn't found`);
    } else {
      console.log(`Fetched TODO with ID ${todoId}: ${todo.content()}`);
    }
  }
});

データ型とサービスインターフェイスを宣言すると、gRPC-Web はすべてのボイラープレートコードを抽象化し、クリーンで人間が理解しやすい API を提供します（これは、現在の Node.js の gRPC API と基本的に同じ API ですが、クライアントに転送されています）。

バックエンドでは、gRPC サーバーは Go、Java、C++、Ruby、Node.js など、gRPC をサポートする任意の言語で記述できます。パズルの最後のピースはサービスプロキシです。初回リリースから、gRPC-Web はデフォルトのサービスプロキシとして Envoy をサポートしており、数行の設定で適用できる組み込みの envoy.grpc_web フィルター があります。

次のステップ

GA になったということは、コアビルディングブロックがしっかりと配置され、本番 Web アプリケーションで使用できるようになったことを意味します。しかし、gRPC-Web にはまだまだ多くのことが予定されています。コアチームが近い将来に構想していることは、公式ロードマップ を参照してください。

gRPC-Web への貢献に興味がある場合は、コミュニティに役立ってほしいことがいくつかあります。

• フロントエンドフレームワーク統合 — React、Vue、Angular のような一般的に使用されるフロントエンドフレームワークは、まだ gRPC-Web の公式サポートを提供していません。しかし、これらのフレームワークと gRPC-Web の統合は、アプリケーションにユーザーが認識できるパフォーマンス上のメリットをもたらす手段となるため、これらのフレームワークがサポートすることを強く希望しています。これらのフロントエンドフレームワークのサポートを構築することに興味がある場合は、gRPC.io メーリングリスト、GitHub での機能リクエストの提出、または以下の機能調査フォームを通じてお知らせください。

• 言語固有のプロキシサポート — GA リリース時点では、Envoy が gRPC-Web のデフォルトプロキシであり、特別なモジュールを介してサポートを提供しています。NGINX も サポートされています。しかし、言語固有のインプロセスプロキシの開発も歓迎します。これらは、Envoy や nginx のような特別なプロキシの必要性をなくし、gRPC-Web の使用をさらに容易にするでしょう。

コミュニティからの機能リクエストも歓迎します。現在、機能リクエストを行う最善の方法は、gRPC-Web ロードマップ機能調査 に記入することです。フォームに記入する際には、追加したい機能をリストアップし、「I’d like to contribute to」セクションで、それらの機能の開発に貢献したいかどうかもお知らせください。gRPC-Web エンジニアは、プロジェクトの開発プロセス全体を通じて、その情報を真摯に受け止めます。

最も重要なことは、過去 1 年間にわたってフィードバック、バグレポート、プルリクエストの貢献をしてくださったすべての Alpha および Beta ユーザーに感謝することです。この勢いを維持し、このプロジェクトが開発者コミュニティに具体的なメリットをもたらすことを確実にしたいと考えています。

• ←前へ
次へ→