Chapter 14

エンジニアならコードで語れ!

Spiegel
Spiegel
2021.09.27に更新

最初は「GoPostgreSQL の BLOB (Binary Large OBject) データって簡単に扱えるん?」と軽い動機だったのだが,素の pq または pgx ドライバを使うのはちょっとかったるいし Go ではメジャーな GORMent を使うのがいいかなぁ,と沼にハマり始めた(笑) さらに個人的にお気に入りの zerolog を組み込めないのか,と試行錯誤し始め,気が付いたら「GoPostgreSQL の BLOB (Binary Large OBject) データって簡単に扱えるん?」を知りたいために丸2日も費やしてしまったですよ。

で,せっかく2日も使って調べたのだからせめて作業記録をブログ記事として残そうと思ったのだが,途中まで下書きして気が付いた。「これ3回シリーズでも終わらんわ」「じゃあ Zenn 本にすればいいじゃない!」。で,どうせ Zenn 本にするならもう少しちゃんと書かないと,と更に1フィートくらい深堀りした結果が今回のアウトプットである。

公式サイトを含めネットの情報をあちこち彷徨い歩いた印象は「おまーらホンマにこのコードで動かしたのか?」だった。いや,たとえブログ記事でもコードを丸ごと載せたら冗長でピンぼけな内容になりがちだし,最低限のコードに絞るというのは悪くない戦略だけど,せめて import パッケージは明示して欲しかった。

というわけで,この本では言葉の説明は最低限にして,とにかく動くコードを載せまくることにした。目標は来年の私がこの本を起点にして PostgreSQL の再調査ができるレベルまで持っていくことである。まぁ,我ながら「本」とは思えない狂った内容だと自覚してるので,あまりいぢめないでやってください(笑)

簡単にまとめっぽいものを書いておくと

  1. 全ての Gopher は PostgreSQL ドライバを pgx に乗り換えるべし
  2. もう logger は zerolog でいいぢゃん。標準以外の選択肢に zerolog を受け付けてくれよ
  3. 既にテーブル設計が完了しているなら GORM のほうが扱いやすい[1]
  4. 設計要件でデータ間のグラフ構造をより重視するのであれば,要件定義の段階から ent でコードを書くべし

といったところだろうか。特に ent は目から鱗が落ちた。

レガシー・システムではテーブル設計は最重要で真っ先に決定すべき事項とされているが,これはテーブル構造はシステム設計においてもっとも「依存されるもの」であり高安定性が要求されるからだ。でも本当に「依存されるもの」であり高安定性が要求されるのはテーブル構造ではなくグラフ構造なのだ。

ent が秀逸なのは未分化だったテーブルとグラフを分離し,テーブルをグラフの内側にカプセル化するという夢の設計を高いレベルで実現している点だろう。その代わり ent ではグラフの制御をテーブル側に傾けすぎないよう配慮している印象がある。ゆえにテーブル構造への直接的な干渉が難しく,最初にテーブルありきで設計を始めると ent はとてつもなく扱いにくいフレームワークになってしまう。設計の最初の1フィートがこれまでとは違うのだ。

おそらく,実験的実装以外で ent を採用するのであれば,要件定義の段階からコードを書いて議論していかないと無理だろう。特にレガシー・システムから入れ替えたい場合などは,かなり斬新な設計変更が求められるんじゃないかな。紙や Excel でスキーマ設計する時代は終わったのである(笑)

まぁ,でも,いまどきはデータ同士の関係が合理的にグラフ化出来ないと DX もへったくれもないので,言語に依らず ent のようなアプローチは今後増えていくのかもしれない。

脚注
  1. GORM と組み合わせて使える smallnest/gen といった製品もある。 smallnest/gen では GORM で利用可能な Model 構造体を生成できる。 ↩︎