connect bufの素振り
ningenmeとりあえず、protobufから自動生成して、クライアント <-> サーバー間の疎通は割と楽だった。ローカルは。
ningenmeningenmeドキュメントは基本公式読むだけでok
ningenmeaws環境で動かすときに困ったことがあったのでメモ
alb経由でアクセスする感じで、ブラウザ -> alb -> サーバー って経路でインフラ組んだけど疎通できなかった。
原因はプロトコルで、最初GRPCにしてたんだけど、healthcheckまではうまくいくものの、ブラウザ越しだとCORSになる。設定は下記みたいな感じ。
ningenmeブラウザ側のnetwork情報を見るとCORSエラーになるから、最初go側の設定をずっと疑ってたけど、ちゃんとorigin設定してるし謎になってた。
よく見ると、プレフライトリクエストの時のレスポンスが、ステータスコード464とかいう初見のやつになってたので、これで検索したらいい感じの文言が見つかる。
考えられる原因:
リクエストプロトコルは HTTP/1.1 であるが、ターゲットグループのプロトコルバージョンが gRPC または HTTP/2 である。
リクエストプロトコルは gRPC であるが、ターゲットグループのプロトコルバージョンが HTTP/1.1 である。
リクエストプロトコルは HTTP/2 であり、リクエストは POST ではないが、ターゲットグループのプロトコルバージョンが gRPC である。
なるほど？
ningenmeconnectのプロトコル的にはhttp methodは全部POSTになるから、albのプロトコルはGRPCでヘルスチェックかなと思ってたけど、ブラウザ的には HTTP/1.1 でリクエストしてるっぽい。まあそりゃそうか。
GRPCで投げれてたらそもそも従来のenvoy必要問題は解決してたもんね。。
ningenmeということで、サーバ側に、connectのプロトコルと別で、普通のhttpリクエストをGETで受けれるhealthcheck用のエンドポイントを作成
そして、alb側をHTTP1にすると動くようになった。
いえい。
下記で一応、connectプロトコルでも叩けてるのがわかる
ningenmeとりあえずgoとtypescriptが使えるのが分かったのと、envoy不要になったのが大きい。
今後いろんな言語でも実装されて発展する技術として期待。