Protocol Buffersをシコシコ使ってるんですが、clang-formatをかけると具合の悪くなるパターンを発見したのでメモ。
ちなみに一応書いときますがclang-formatはProtocol Buffersをサポートしてます。
例えばこういうパターンです。
これに対してclang-formatをかけると・・・
🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔
調べたけどソースコード読むのダルくてわからん。
ただLLVMのbug reportはされているみたいなので、バグという認識をしている人はちゃんといるっぽい。
このままじゃ困るので一旦の応急措置。
はい。微妙な違いなのですがoption内でセミコロンを使わないってことをしています。
こうするとclang-formatをかけても・・・
schema のところがちょっと変わっちゃいましたが、まぁ概ね問題無しですね。
というわけで、clang-formatでインデント崩れ起こしちゃうパターンがあるよという話でした。
まぁバグっぽい挙動なので直るのを粛々と待つしかないですね・・・
gRPCにはgrpc-gatewayという、gRPC ServerのレスポンスをRestful APIの形にして返すプラグインがあります。
Protocol Buffersに少し記述を足すだけで、簡単にRestful APIの対応が出来るのでとても重宝しているのですが、一つ困ったことが起きました。それが掲題の件です。
ページネーションに対応したレスポンスを返すエンドポイントを作成する際に、以下のような形で返したかったというのが理由になります。
Server側ではページ移動する際に必要なリクエストの内容を返却し、Gateway側では直接URLを返却するという感じになります。
で、ここで問題になるのがServerのレスポンス形式とGatewayのレスポンス形式は同じにしか出来ないというところです。
例えば、このようなprotocを記述すると思うのですが、
こうした場合、Server・Gatewayのどちらもレスポンスが ExampleResponse の形式に依存することになります。 google.api.http でGatewayのレスポンスを設定が出来たらいいんですが、そういったものも見つかりませんでした。
対処の流れ説明すると
ってな感じです。（言語はGoを想定しているのであしからず）
protocol buffersは google/protobuf/any.proto をインポートすることでAny型というものが使えます。Anyの名前が指し示す通りどんなメッセージ型でも受け入れることが出来ます。まずは、これをResponseに入れ込みましょう。
これで Response の pagination を通して、Server側のレスポンスとしては ServerPaginationMessage を、Gateway側のレスポンスとしては GatewayPaginationMessage を返す土壌は出来ました。
Any型のpagination fieldにServer側レスポンスを当て込むように実装していきます。
コードとしては以下のようなイメージです。
これでAny型にServer側レスポンスを上手く流せ込めました。
さて、ここからが本番なのですが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を吐くことが出来ますが、その際にParametersの個々のfieldにdescriptionをどうやったら付けれるのかよく分からなかったのでメモ。
これを追加したかった。
至極簡単で、OpenAPIのfieldを使ってゴニョゴニョすればいい。
例えば以下のような感じで、protocファイルに記述する。
message HogeRequest {
uint64 id = 1 [(grpc.gateway.protoc_gen_swagger.options.openapiv2_field) = {description: "Test hoge"}];
}
簡単なことだけど、これに気付くまでにめちゃくちゃかかった・・・
基礎からわかるElm読み終わったので読書感想文です。
皆さん、Docker使ってますか？僕は新天地でバリバリDocker使うことになりそうなので慌てて復習していたりします。
さて、そんな中Docker Composeで見事にハマってしまった罠があったので、Project Nameにハイフンは使わないようにしましょうという話をします.
Docker Composeは作成されるcontainer imageの名称が以下のように決められています。
{プロジェクト名}_{サービス名}_{連番}
(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 オプション指定してプロジェクト名をアンダーバーのものにしとくと良いです。