普通に使えると思いきやNodObjCが動かなかった
これまで
と
と複数のｇRPCをつかったリポジトリを保有しているものの、 .protoファイルがHelloWorldを流用してやり過ごしていた。
今回一念発起して、独自の.protoファイルかつStreamをつかったｇRPCにチャレンジした。
.protoファイルを触るのは今回が初なので、.protoを動的に扱ってくれるNode.jsで クライアントもサーバも作成することにした。 というか、前回の記事の
Node.jsで作ったWebカメラの映像をターミナルに表示するアプリのクラサバ間通信を ソケット通信からgRPCに変更するということで、
HelloWorldとともに公開されているRoute_guideのソースを見れば、大体わかる。 特にNode.js実装だと自分が慣れているのもあり、
- サーバ側からstreamを返すパターン
- クライアント側からstreamを送るパターン
- クライアント、サーバともにstreamを送るパターン
のパターンがあり、これらのそれぞれのパターンに対応するメソッドがサンプルに 書かれている。
今回はクライアントからは通常のリクエスト、サーバ側からストリームというパターンで 作るのでサンプルの
function listFeatures(call) {のメソッドを参考に作業を進めた。
自分の中にはストリームというとバイトストリームのイメージが強く、 JSONが分割して送信されると誤解していたが、 .protoファイルで定義したJSONがぼこぼこ返されるのだった。
ppm
はPPMファイルを適当にぶった切ってバイト列を
で送るものだと決めつけていたが、PPMファイルをまるまる一回の
で送ることが出来てしまった。
当初はｇRPCでStream指定をしたら、gRPC側で適当に細切れにして、クライアントに送信することを 来していたが、裏でどうなっているかは知らないが、表面的なAPIとしては、 サーバで1個streamを送信したら、クライアント側で1個受け取れる模様。
クライアントからのリクエストを空にする子も可能 今回のアプリはWebカメラの画像を貰うだけなので、特にクライアントからサーバに渡すデータは 不要だったが、サンプルは何かしら入れているので、どうしたものかと一瞬悩んだが、
という指定で.protoファイルを作ることが出来たので、スッキリした。
サーバ側で、Webカメラの映像が安定することを期待してウェイトを入れているが、 これがどの程度長くしても怒られないのか、また、怒られる場合は、gRPCのタイムアウト になるのだろうか。