はじめてのgRPC-Web

kahirokunn

twitter: https://twitter.com/kahirokunn

qiita: https://qiita.com/kahirokunn

最近はインフラの方に興味関心がある

フリーランス

アジェンダ

  • rpcの振り返り
  • gRPCとは
  • gRPC-Webとは
  • gRPC-Web vs OpenAPI
  • gRPC-Webの現状とこれから

システム間連携の復習

RESTやGraphQL、gRPCはどれもシステム間連携と深く関わりがある.

gRPCは名前からしてもrpcフレームワークの一種なので、

システム間連携について振り返る.

振り返りにはEnterprise Integration Patternsを主に参考にする.

Integration Styles

Remote Procedure Invocation (RPI)

RPIはアプリケーションが他のアプリケーションがもっている情報を必要とするなら直接そのアプリケーションに依頼する手法の事を指す

つまり直接通信して情報の受け渡しをする

A
B

RPCとREST

つまり、RPCとRESTはRPIの一種である.

RPCとRESTの違いは、APIの設計手法の差.
RPCはプロシージャ指向であり、RESTはリソース指向.

参考文献: 「API 設計: gRPC、OpenAPI、REST の概要と、それらを使用するタイミングを理解する」

RESTに関する余談

RESTはWebサービスの設計原則の一つ.

2000年にRoy Fieldingが提唱した.
RESTの考え方に完全に準拠しているWeb APIをRESTful APIと呼んでいる.
今では実際に一部だけ準拠しているのをREST APIと読んでいる事が多い.
エンタープライズアプリケーションでは、リソース指向で作る必要性が薄い事も多く、単純なRPCで作る事や、一部RESTの考えを取り入れたハイブリッドな手法で開発されることが多い.

gRPC

google製のRPCフレームワークである.
​言語問わずにRPCをするライブラリを提供している.
gRPCサーバーが提供しているrpcとそのデータ形式の定義にはProtocol Buffersを利用する.
Protocol Buffersを定義し、それを利用してgRPC用のクライアントとサーバーのコードを生成する.

Protocol Buffers

// The greeter service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

gRPC-Web 

ブラウザ上だとjsにかなりの制限がある.
gRPC-Webは、ブラウザがgRPCサービスにアクセスできるようにするJavaScriptのライブラリ.
現在GAしている.
gRPCはアプリケーション間の接続方式とデータフォーマットにまで言及しており、その要件を全てのブラウザーで満たすことはできない.
それ以外にもあるが、gRPC-Webはブラウザの都合に沿って作られている.
しかし、そのままだとgRPCのサービスを実装したサーバーとの互換性がないので、gRPCの世界に入る為のGatewayとして、Envoy等をReverse Proxyとして設置し、そこでgRPC-WebのメッセージをgRPCに変換して、サーバーとやりとりをする

メリット・デメリット

  1. Web用にgRPC-Gatewayの用意が必要 (デメ
  2. バックエンドをgRPCの技術で作成可能
  3. 既にgRPCやProtocol Buffersが導入されていた場合、スタックの統一が可能
  4. gRPCは流行りの機能満点な仕様ではなく、ただただ必要なRPCを定義していくだけの凄くシンプルな仕様なので、実装がシンプルに済む
  5. ストリーミングも考慮されているので、リアルタイム要素があるものの実装が可能  (リアルタイムチャット等
  6. クライアント・サーバーのコードの自動生成が可能

使ってみた感想

Protocol Buffersの定義をしてから実装が始まるので、RPCのインターフェイスに関する議論を実装しながら決めたり、実装開始後に変更する事がなく、RPCの実装はそれだけに集中できてとてもよかった.

また、下手なRequestが飛んでこないのでとても良い.

比較: OpenAPIやGraphQL等

他のIDLを使った開発と比べると、Envoyを用意する必要がある分、1歩手間である.
しかし、サーバーの実装が使い慣れたgRPCでできたり、スタックを統一できるのはかなりメリットなのかなと.
しかし、そのメリットの対象外の場合、正直OpenAPIやGraphQLを断る理由はないと思います.

ご静聴ありがとうございます

Made with Slides.com