生涯未熟

生涯未熟

プログラミングをちょこちょこと。

gRPC GatewayとServerで異なるレスポンスで返す方法

前置き

gRPCにはgrpc-gatewayという、gRPC ServerのレスポンスをRestful APIの形にして返すプラグインがあります。
Protocol Buffersに少し記述を足すだけで、簡単にRestful APIの対応が出来るのでとても重宝しているのですが、一つ困ったことが起きました。それが掲題の件です。

ページネーションに対応したレスポンスを返すエンドポイントを作成する際に、以下のような形で返したかったというのが理由になります。

Serverレスポンス

Gatewayレスポンス

Server側ではページ移動する際に必要なリクエストの内容を返却し、Gateway側では直接URLを返却するという感じになります。
で、ここで問題になるのがServerのレスポンス形式とGatewayのレスポンス形式は同じにしか出来ないというところです。

例えば、このようなprotocを記述すると思うのですが、

こうした場合、Server・Gatewayのどちらもレスポンスが ExampleResponse の形式に依存することになります。 google.api.http でGatewayのレスポンスを設定が出来たらいいんですが、そういったものも見つかりませんでした。

対処法

対処の流れ説明すると

  • ResponseにAny型を使用する
  • Serverから返す場合にはServer用のレスポンス形式で返すようにする
  • Gatewayから返す場合にはGateway用のレスポンス形式で返すようにする

ってな感じです。（言語はGoを想定しているのであしからず）

ResponseにAny型を使用する

protocol buffersは google/protobuf/any.proto をインポートすることでAny型というものが使えます。Anyの名前が指し示す通りどんなメッセージ型でも受け入れることが出来ます。まずは、これをResponseに入れ込みましょう。

これで Response の pagination を通して、Server側のレスポンスとしては ServerPaginationMessage を、Gateway側のレスポンスとしては GatewayPaginationMessage を返す土壌は出来ました。

Serverから返す場合にはServer用のレスポンス形式で返すようにする

Any型のpagination fieldにServer側レスポンスを当て込むように実装していきます。
コードとしては以下のようなイメージです。

これでAny型にServer側レスポンスを上手く流せ込めました。

Gatewayから返す場合にはGateway用のレスポンス形式で返すようにする

さて、ここからが本番なのですがGateway側の場合、少し複雑なプロセスが必要になります。
https://github.com/grpc-ecosystem/grpc-gateway/blob/master/examples/cmd/example-gateway-server/main.go#L21-L37 を参考に説明していきます。

grpc-gatewayにはruntimeパッケージが用意されており、まずはその中の runtime.WithForwardResponseOption を使って「レスポンスを返す前の処理」を実装していきます。

実に面倒なのが分かりますね。こんな風に Server側レスポンスを受け取る→Gateway側レスポンスを構築する→Any型に埋め込んで返す といった一連の流れになります。この辺のAny型の扱い、なかなか記事としても無いので難しいですね・・・

まとめ

という感じでこの問題は解決できましたが、Google API Design Guideを読むとどうやらGoogle様的には「ページネーションはTokenでやり取りせえよ！」というスタンスみたいなので、（Common Design Patterns  |  Cloud APIs  |  Google Cloud）もしかしたらこのやり方は邪道なのかもしれません。
しかし、昔ながらのページネーションを踏襲しつつやるにはこういった方法も必要になる場面が多いんじゃないかな？と一応書き残しておきます。

Protocol Buffersが出力するSwaggerのParameter descriptionを記述する方法

Protocol BuffersでSwaggerを吐くことが出来ますが、その際にParametersの個々のfieldにdescriptionをどうやったら付けれるのかよく分からなかったのでメモ。

どういうこと？

f:id:syossan:20190311192111p:plain

これを追加したかった。

やり方

至極簡単で、OpenAPIのfieldを使ってゴニョゴニョすればいい。

例えば以下のような感じで、protocファイルに記述する。

message HogeRequest {
  uint64 id = 1 [(grpc.gateway.protoc_gen_swagger.options.openapiv2_field) = {description: "Test hoge"}];
}

簡単なことだけど、これに気付くまでにめちゃくちゃかかった・・・

Docker ComposeのProject Nameにハイフンを使わない方が良いという話

皆さん、Docker使ってますか？僕は新天地でバリバリDocker使うことになりそうなので慌てて復習していたりします。

さて、そんな中Docker Composeで見事にハマってしまった罠があったので、Project Nameにハイフンは使わないようにしましょうという話をします.

どういうこと？

Docker Composeは作成されるcontainer imageの名称が以下のように決められています。

{プロジェクト名}_{サービス名}_{連番}
  • プロジェクト名 (Prefix)：デフォルトでは docker-compose.yml を置いているフォルダ名が使用される。
  • サービス名：docker-compose.yml に書いた任意の名前が使用される。
  • 連番 (Suffix)：スケールする際に連番で付与される。

(https://qiita.com/ymm1x/items/56961f8e2ffb48b8dbe3 より引用)

で、プロジェクト名ってよく hoge-system みたいにハイフンを間に噛ませるじゃないですか？
その状態でnetworksとか設定してしまうと、ホストからコンテナのIPアドレスを取得する時によく使う docker inspect --format "{{.NetworkSettings.Networks.hoge-system_networks.IPAddress}}" hoge-system_service_1 とかがパースエラーになって実行出来ないのでよくないという。

どうすればいいの？

単純に .env とかで COMPOSE_PROJECT_NAME=hoge_system にしとくとか、docker-compose実行時に -p オプション指定してプロジェクト名をアンダーバーのものにしとくと良いです。

Go 1.12で個人的に気になったところを触ってみた

Go 1.12来ましたね。

色々変更点はあるんですが、個人的にベンチマークの実行回数が指定出来るようになったのがオッとなり触ってみました。

実行コード

簡単なコードで試してみます。

package main

func Calc(x, y int) int {
    return x + y
}
package main

import (
    "testing"
)

func BenchmarkCalc(b *testing.B) {
    for i := 0; i < b.N; i++ {
        Calc(b.N, b.N)
    }
}

足し算するやつです。

試す

まずは今までやっていた実行秒数指定から。

$ go test -bench . -benchtime=5s
goos: darwin
goarch: amd64
pkg: hoge
BenchmarkCalc-8         10000000000              0.35 ns/op
PASS
ok      hoge      3.516s

5秒間回せました。
次に5回実行するようにやってみましょう。

$ go test -bench . -benchtime=5x
goos: darwin
goarch: amd64
pkg: hoge
BenchmarkCalc-8                5                53.0 ns/op
PASS
ok      hoge      0.006s

おー！5回実行できてますね！！
ただ、あまりにも少ない実行回数だと1回あたりの実行時間が大きくなってしまうみたいですね・・・

ちなみに10000000000回だと

$ go test -bench . -benchtime=10000000000x
goos: darwin
goarch: amd64
pkg: hoge
BenchmarkCalc-8         10000000000              0.35 ns/op
PASS
ok      hoge      3.541s

先程の実行時間指定でベンチマークしてみた値と同じになりました。

まとめ

これが実装された経緯が

github.com

これだと思うのですが、Russ Cox氏の反論とか見てると面白いですね。
正直、僕も実行回数指定出来てもあんま意味ないんじゃないかと思っとります。

取り急ぎ、現場からは以上です。