BuffersをベースにしたRPCフレームワーク、gRPCがリリースされた。FrameworkMicroservicesがなんちゃらいわれる昨今だが、その実現のためには、設計面におけるベストプラクティスはもとより、実装面においても課題がある。サービス間でどのようにオーバーヘッドが少なく、帯域を浪費しない通信を実現するかということ。そんな折Googleが、上記のリンク先にある通り「うちらめっちゃMicroservicesだし」ってんで、まさに「これだ!」という技術スタックでいい感じのものを出してくれた。gdbmにRPCしてみるとりあえず試してみたいので、簡単にできそうな例として、gdbmにネットワークインタフェイスをもたせてRPCしてみる、ってのをやってみた。Buffersを用いて、こんな感じで書く。FetchというRPCを定義している。Buffersを使うぐらいなのでデータ量-awareな感じだろうから、ほんとは以下のRequestの定義をもっと厳密にわけた方がいいと思うけど、例なので深く考えない。2;}んでもって、この定義からRPCへのクライアントとサーバのコードを生成する。--go_out=plugins=grpc:gdbm生成された内容は以下の通り:https://github.com/kentaro/grpc-gdbm/blob/master/gdbm/gdbm.pb.goサーバとクライアントを書くあとはそれを使ってなんか適当に書いていくだけ。Fetchを実装したstructを、上記で生成されたpb.RegisterGdbmServer()にわたしてやると、RPCをいい感じに受け付けるようになる(生成されたコードに、そういうinterfaceが定義されている)。s.Serve(lis)}クライアントは特に述べるまでもない感じ。この例の場合に普通に使うなら、生成されたコードを使っていい感じのAPIを持つライブラリを作って、それを使うことになるだろう。r.Value)}RPCしてみるそしたら、あとはサーバとクライアントを使ってRPCできる。使いどころこの例で示したような、6〜7年前とかにThriftとか使っていた頃のようなユースケースにもあてはまるんだろうけど、いまだとまさにMicroservices用とかStreamingとかに使う感じになるんだろう。いうか、そうでないとHTTP/2なうれしさがあんまり見いだせないだろうし。当時だといろいろとしんどかった記憶があるけれども、いまだと例でも利用したGoもあるしHTTP/2もあるし、いろいろ環境は整っているなという感じがする。