Open2024/03/25にコメント追加28

connect-goとかSpannerとか

自分でconnectサーバーを作ろうとしたときに詰まったのでこちらでアウトプットしながら進めていく

前提としてconnect-goを使う
protoファイルを作成し、そこからGoのインタフェースなどを自動生成
main.goでそれらを参照してサーバーを立ち上げる

protoファイルは以下のような内容

syntax = "proto3";
package greet.v1;
option go_package = "example/gen/greet/v1;greetv1";
message GreetRequest {
  string name = 1;
}
message GreetResponse {
  string greeting = 1;
}
service GreetService {
  rpc Greet(GreetRequest) returns (GreetResponse) {}
}

buf mod init で buf.yaml を作成後、buf.gen.yaml を自分で作成する

なぜ buf.gen.yaml を自動生成するコマンドはないか

buf.gen.yaml だけ作成すれば buf generate に成功した
buf.yaml を作成するのは必須ではなさそう

とりあえず go mod init example と example を使えば問題なさそう

connectサーバーを起動できた
全体的な流れはだいたい以下

protoファイルを作成
buf.gen.yaml を作って buf generate を実行し、xxx.connect.go と xxx.pb.go を作成
中身を実装した構造体を用意
greetv1connect.NewGreetServiceHandler みたいなのに渡してhttpサーバー起動
localhost:8080/greet.v1.GreetServer/Greet などにリクエスト

xxx.pb.go にはやり取りするデータの型が定義されている
xxx.connect.go にはサーバーの実体を作る関数などが定義されている（ルーティングとか）

xxx.connect.go は基本的に NewXXXServiceHandler() を使う目的でしかインポートしなさそう
（xxx.pb.go はものすごく頻繁に使う）

チュートリアルを進めただけなので自分で一から作ろうとすると躓く部分がありそう
けどそれは一旦スルーしてCloud Runにデプロイしてみる

Spanner はもしかして重い？
Spanner のテーブルにデータを追加するだけで 200ms くらいかかった

90日間無料のインスタンスだから何か制限されている？

とりあえず Cloud Run にデプロイしても同じ結果になるかどうかを確認する

Cloud Run にデプロイしても同じくらい時間がかかった
もともと100万件くらいのレコードが存在しているから重くなっている？
あまり関係なさそうだけどどうだろう
とりあえず全件削除して再計測してみる

100万件を一気に削除することはできなさそう
（削除の場合は 80,000 件が上限）
Spanner という感じの制限
DELETE 文に WHERE が必須なのもなんか好き
あと WHERE 1 は構文エラーで、WHERE TRUE と書く必要がある（boolじゃないといけない）

一旦テーブルを削除して再生成、その後レコードを挿入したが、やはり200msかかった
Goのコードの書き方が悪い？

公式ドキュメントのコードを眺めてみる

公式が「GORM で Spanner を使える」と言っている

公式が GORM に言及しているのが意外だった

まだ始めたばかりという感じ（スター数は16）

ネストされたトランザクションがサポートされていないのが少し残念
Spanner は仕組みが複雑だから仕方がない気もする

Spanner の DML とミューテーションはどう違う？

DML のほうが優勢という感じ
基本的に DML を使っておけば問題なし？
ただ Go 言語で DML を使えるかどうかは不明

DML だと早いのかと思ったけどそうでもなさそう
ミューテーションと同じで200msくらい

DML の実行に100ms、トランザクションのコミットとかで100msかかっているっぽい

Cloudコンソールで実行すると3msくらい
なぜこんなに差があるんだろう

Spanner の STRUCT 使うのが楽しみ

$a = b + c$