Commits at f8d73a6d0c458c02271be057488905dc48fcea05
4a363d11
backend: HTTP サーバのホストとポートを CLI 系で変更可能にした
ぶっちゃけログのほうがメインだったり。実際に何度も立ち上げて
わかりづらかったので。
Shota FUJI
authored at
2025-04-18 14:07:14 +0900
Shota FUJI
comitted at
2025-04-18 14:10:18 +0900
7627d966
backend: まともに CLI 引数を渡せるようにする
Go の flag パッケージは普通の `-a`/`--a-long` 形式をサポートせずに
`-a-long` で全部ポインタのため。楽だが、成果物の UX が悪くなるという
アンチパターン。 Go の標準ライブラリ割とだめじゃね...?
Shota FUJI
authored at
2025-04-18 13:38:32 +0900
Shota FUJI
comitted at
2025-04-18 13:52:16 +0900
dafd1a3c
backend: テキストログ出力をまともに見れるように修正
Shota FUJI
authored at
2025-04-18 13:37:10 +0900
Shota FUJI
comitted at
2025-04-18 13:37:37 +0900
0b23f623
backend: テキストログと JSONL ログを選べるようにした
JSONL は便利だがテスト時などは見にくい。
Shota FUJI
authored at
2025-04-18 10:28:35 +0900
Shota FUJI
comitted at
2025-04-18 10:29:43 +0900
e95f3a9c
backend: デバッグログを見れるようにする
見れなきゃ出しても意味ないので。
Shota FUJI
authored at
2025-04-18 10:21:46 +0900
Shota FUJI
comitted at
2025-04-18 10:22:17 +0900
4440b52c
backend: 管理者作成パスワードの初期指定
自動テストが書けないので。
Shota FUJI
authored at
2025-04-18 10:15:11 +0900
Shota FUJI
comitted at
2025-04-18 10:17:45 +0900
6b71ff4f
proto: ユーザの権限モデル定義
Shota FUJI
authored at
2025-04-17 17:25:33 +0900
Shota FUJI
comitted at
2025-04-17 19:51:06 +0900
f1497f78
backend: ログイン RPC
Shota FUJI
authored at
2025-04-15 14:01:45 +0900
Shota FUJI
comitted at
2025-04-15 14:46:13 +0900
05bda859
backend: イベント生成のヘルパ関数
自動生成されるコードがあまりにも酷くノイズでしかないため。
Shota FUJI
authored at
2025-04-15 13:51:17 +0900
Shota FUJI
comitted at
2025-04-15 13:53:01 +0900
a20b0398
backend: 管理者ユーザ作成時に PW を設定する
単純な抜け。
Shota FUJI
authored at
2025-04-15 13:26:48 +0900
Shota FUJI
comitted at
2025-04-15 13:27:18 +0900
e3344e20
backend: 初期管理者作成フロー
テストは一パターンしかないが、初期パスワードを明示的に指定する機能が
ないとテストができないので (ログをキャプチャするとかは勘弁) とりあえず
サンプル的に書いてあるだけ。ちゃんと書くならある程度ヘルパ関数に出して
いく必要がありそう。
スナップショットやプロジェクションあたりは PoC をベースにシンプルで
クリーンな感じを目指して書いたが、もう少し詰めてきれいにできそうな
気がする。
Go 特有のボイラープレートは全然問題ではなかったが、 Protobuf/Go の吐く
コードがやばすぎてやばさがやばい。現状、
* WASM 出力ができる
* 2023 edition の Protobuf に対応している
* ランタイムオーバヘッドが大きくない
言語が Go しかなくスイッチはできないので、ヘルパなり何なりで早めに対策
をする必要がありそう。特に `oneof` のコード生成がオワコンすぎる。
Protobuf 2024 edition が出たら生成コードが Opaque になって Builder 系の
ヘルパが生成されるのでそれまで待つのもあり? 2025 Q3 あたりでようやく
仕様が固まる見通しっぽいからあまりにも酷ければ移行を見越したヘルパなり
Builder と似た機構を用意したほうがいいかも。
色々と中途半端なところや TODO コメントがあるが、これ以上完璧を目指すと
diff を読むのが地獄なのでここで一区切り。
Shota FUJI
authored at
2025-04-13 23:14:50 +0900
Shota FUJI
comitted at
2025-04-13 23:38:31 +0900
9aef8519
Zig 関連の設定を削除
利用しなくなったため。
Shota FUJI
authored at
2025-04-11 21:09:45 +0900
Shota FUJI
comitted at
2025-04-11 21:11:23 +0900
dd213fe7
vendor/go-sqlite3-js: WASM で DB が開けないのを修正
そもそもこのコードが動いていたのか甚だ疑問。
Shota FUJI
authored at
2025-04-11 16:07:11 +0900
Shota FUJI
comitted at
2025-04-11 16:08:07 +0900
516cab77
backend: SQLite3 の導入
WASM でも動かすために色々追加している。
ただ、これ以上環境依存のツールを導入しなければ後は共通の
コードを書くだけになるはず。
Shota FUJI
authored at
2025-04-10 21:26:57 +0900
Shota FUJI
comitted at
2025-04-11 16:06:24 +0900
115fc47f
backend: すべて Go で書く
WASM の出力がおかしいのはどうやら v1.24.1 限定のバグだった模様。
v1.23.8 と v1.24.2 では再現しなかった。リリースノートにはないので
バレないようにしれっと直したのだろう。
pwa パッケージにサンプル的なコードが入っているが、これは動作確認用。
後で消す予定だが、どのみち pwa パッケージは使わなくなるのでそのまま
になる可能性も。
Shota FUJI
authored at
2025-04-09 15:49:19 +0900
Shota FUJI
comitted at
2025-04-10 21:06:00 +0900
82244747
backend: SQLite3 での Event Sourcing スキーマ
SQL 文の正常性確認は実際に行いそうなクエリや INSERT を書いたものを
`001_test.sql` と保存した上で、
```
$ cat migrations/*.sql | sqlite3 -table
```
を実行した。
本来であればマイグレーションの実行までを一纏めにしたかったが、
ここに来て Zig の protobuf である Gremlin のコード生成が全然ダメ
なことが発覚。特に `oneof` を普通のメッセージと同様に出力するため
利用側でどのフィールドが判別できない ("_" でプリフィクスされてる
フィールドが `null` かどうかを見ればわかるが、非公開だしハック)
ので実用に耐えないことが分かった。他の Protobuf コード生成ツールは
Protobuf3 しか対応しておらず、 edition 向けのちゃんとしたツールを
書くしかない。しかし工数的に、というかペース的にそんな余裕がないので
Go (WASM 出力できれば) か Rust (Go がウンコだったら) での書き換えを
する予定。そうなると更に低レベルな内容のコミットとなるため、別の
コミットにすることとした。
要約すると、大量の環境整備が入るけどこの SQL 捨てるの勿体ないから
コミットしたよ。
Shota FUJI
authored at
2025-04-07 09:29:30 +0900
Shota FUJI
comitted at
2025-04-07 20:38:34 +0900
7db4a3ee
backend: server.zig を削除
サーバも WASM を使うことにしたため。
Shota FUJI
authored at
2025-04-06 21:53:59 +0900
Shota FUJI
comitted at
2025-04-06 21:54:34 +0900
f6062794
proto: ユーザ作成 RPC
Shota FUJI
authored at
2025-04-06 15:35:13 +0900
Shota FUJI
comitted at
2025-04-06 15:36:52 +0900
35f896e8
proto: 単一ワークスペース前提の workspace/v2 モジュール
SingletonWorkspaceService を作ったが、既存のモデル定義を拡張していくと
どうしてもノイズが多くなったり注釈が増えたりしてくる。
根本的なアーキテクチャ変更なのでバージョン変更は妥当と判断し、最小限の
モジュールを作成した。
根本的な変更の理由はユーザ管理・ログインを実際に実装しようとして既存の
サービス設計では実現が難しい、できてもハック盛りだくさんになってしまう
ため。労働者管理とユーザ管理を分離しようとして設計した v1 だったが、
結果的にそれのせいでユーザ管理が追加できない事態となってしまった。
Shota FUJI
authored at
2025-04-06 14:21:58 +0900
Shota FUJI
comitted at
2025-04-06 15:05:14 +0900
8edcdcf5
proto: ユーザモデルをワークスペース配下に移動
シングルトンワークスペースがメインになる以上、ユーザはワークスペースに
属するデータとなる。
Shota FUJI
authored at
2025-04-06 13:48:02 +0900
Shota FUJI
comitted at
2025-04-06 13:48:58 +0900
eb9ece9c
proto: 内容がおかしいコメントの修正
多分コピペ。
Shota FUJI
authored at
2025-03-27 23:36:28 +0900
Shota FUJI
comitted at
2025-04-06 13:39:25 +0900
3abc4595
proto: カスタムフィールド
社員 ID などを設定して CSV などでエクスポート、外部システムで
紐づけなどのユースケースがあるため必須要件となる。
Shota FUJI
authored at
2025-03-27 23:34:33 +0900
Shota FUJI
comitted at
2025-04-06 13:39:24 +0900
87be8e69
proto: ログアウト RPC
Shota FUJI
authored at
2025-04-05 20:04:26 +0900
Shota FUJI
comitted at
2025-04-05 20:04:45 +0900
c433adc6
proto: ログイン RPC
Event Sourcing をするにしろ通常の CRUD SQL にするにしろ、
まずこれが必要になる。このあとのユーザ周りの設計にも必要
になってくる。
Shota FUJI
authored at
2025-04-03 20:19:51 +0900
Shota FUJI
comitted at
2025-04-03 20:22:01 +0900
b24ca3f0
backend: connectrpc を使ったサーバ
リクエストを受けると Go -> Zig (WASM) -> Go という順番で処理を
行う。 connectrpc のデザイン制約上 binary -> Go struct -> binary
-> Zig struct -> binary -> Go struct -> binary と非常に非効率な
シリアライズ・デシリアライズをしてしまっている。ただ、現状 Zig で
まともな gRPC ライブラリがないこと、自前の HTTP2/3 をベースにした
実装だとプロファイルやテストで実装コストが膨らむことから当面は
この非効率実装を妥協点とする。
長期的には独自の protobuf 用 RPC + rate limit 付きの (非効率な)
現状と同じ connectrpc 経由の外部向け gRPC というのが無難そうか。
Shota FUJI
authored at
2025-03-27 09:45:18 +0900
Shota FUJI
comitted at
2025-03-27 09:52:26 +0900
75d721c8
backend: Wazero を使った Go からのコア呼び出し
gRPC やらサーバ周りは Go が充実しているため。
また、サンドボックスで実行されることにより I/O を限定でき、
安全にコアを実行できる。
Shota FUJI
authored at
2025-03-26 20:46:48 +0900
Shota FUJI
comitted at
2025-03-26 20:56:00 +0900
f5eafc11
backend: WASM バックエンド
DB とかはない。そもそもどんな DB アクセスにするのかとか
設計とか考えてないし。
Shota FUJI
authored at
2025-03-24 13:35:19 +0900
Shota FUJI
comitted at
2025-03-24 14:27:36 +0900
62a6766e
backend_core: Zig から protobuf を利用する
使っている Gremlin というコード生成ライブラリと Zig という言語の
仕様上、 proto でライブラリを出力、というのはハックになってしまう。
そのため、多少効率は悪くなるが利用側で都度出力する形にした。
Protobuf は .proto 毎にソースファイルを生成、という形だが Zig は
配布形態に合わせたパッケージングとなる。つまり、静的・動的な
ライブラリや実行ファイルがモジュールの単位となる。そのため「複数
ファイル群をモジュールとして公開」ということはできない。
このコミットでは protobuf の wkt (well-known types) の追加も
含まれている。これは Gremlin が protoc に対応しておらず wkt が
含まれていないため。このベンダリングに伴うライセンス周りの変更も
入っているため少し変更ファイル数が多くなっている。
Shota FUJI
authored at
2025-03-22 14:52:31 +0900
Shota FUJI
comitted at
2025-03-22 16:57:44 +0900
e551c6fc
proto: 単一ワークスペース向け構成 RPC
現実的な運用としてマルチワークスペースはなさそうということが判明。
自分の組織だけのデプロイなのにワークスペース選択やらがあるのは不便なので
単一ワークスペース向けのフローを考えそれに必要な RPC を実装した。
Shota FUJI
authored at
2025-03-21 15:14:37 +0900
Shota FUJI
comitted at
2025-03-21 19:39:53 +0900
90396a7f
proto: 疎通確認RPC
実装初期やテスト、ステータス確認などいろいろ便利なため。
Shota FUJI
authored at
2025-03-20 13:58:55 +0900
Shota FUJI
comitted at
2025-03-20 14:02:50 +0900
Commits for
f8d73a6d0c458c02271be057488905dc48fcea05
Viewing range
4a363d11
~ 90396a7f