GoでのORMを使用しないAPI開発。SQLの結果をstructにmapすることについて。

Question

前提

GoでAPIを構築する際、ORMを使用せず生のSQLを書くとそれをStructにマッピングする必要があります。
sqlx (https://github.com/launchbadge/sqlx) のようなライブラリを使うことで、マッピングを簡易的に行うことも可能ですが、
One-to-ManyやMany-to-Manyとなると対応しておらず、クエリを複数回叩くか、取得したデータをループで回して手動でStructに入れていかなければなりません。

はじめはそんなわけがないと思い、いろいろ解決策を探したのですが例えばここ（https://stackoverflow.com/questions/54601529/efficiently-mapping-one-to-many-many-to-many-database-to-struct-in-golang）
でも言及されてるように、泥臭い解決方しかないようです。

聞きたいこと

そこでお聞きしたいのは、どうやって解決するか？ということではなく、
本当にこんなことをみんなやってるのか？という素朴な疑問です。

ORMの話になったとき、巷ではよく「ORMを使うのはよくない」とか「本来ORMは必要ない」というような情報を目にします。
中でもGoは言語思想的にもしくは言語の特徴的にORMを使わない方が良いという風潮が強いように感じます。

でもORMを使わないことがこんなに面倒ならあまりに割に合ってない気がしてしまいます。

リンク先の例は非常にシンプルなものですが、実際の現場ではもっと複数のテーブルを組み合わせる必要があったり、もっと深くネストすることもありますよね、そう考えるととてもORM無しでやれるとは思えません。

世の中のバックエンドエンジニア方々、ORMなんて無くていいんだという強者な人たちは本当にこんなことをしているのでしょうか？
それとも私が知らないだけでもっと優れた解決法があるのでしょうか？

個人ではフルスタックで開発していますが、ORMを使用した経験(Node.js + prisma等)しかありません。
会社で働く際はフロントエンド中心でバックエンドを触る機会はあまりなく、あったとしてもORMを使用したプロジェクトにしか関わったことがないのでこちらで質問させていただきました。

先輩方のお話を聞かせていただけると幸いです。

Answer 1

多くのGoバックエンドはDBをシンプルに設計しつつゴリゴリ実装を書いているプロダクトが多いように見えます。

One-to-ManyやMany-to-Manyが必要ならそれに対応したORMを利用するとよいと思いますよ。特にサンプルコードが例示されているものが良いのではないでしょうか。

https://entgo.io や https://gobuffalo.io などは対応しているようですよ。

ORM不要論っていうのは非機能要件的にNGなクエリを投げてしまうような
ORMが想定してなかった使い方をしてしまいがちだったり、
DBMSに適したSQLを結局生で記述させられたりといった過去があったりします。

「NGポイントを発見」ー＞「複雑なORMのコードを追うコストの高さ」ー＞「生SQL書いたほうが早く目的の実装が出来上がる」という流れは多く観測されてきました。

Goの場合、Goを選択したという時点で応答性能の高いバックエンドが求められているのかなと思いますが、その場合、DBテーブルの構成をシンプルに保ちつつ参照範囲をできるだけ狭くなるように設計することが重要になります。あまり賢くないORMを利用した場合、このあたり貪欲に広範囲のデータを参照しようとしてしまう傾向があります。そうなってくると、RubyやPython、Nodeのような賢いORMのある環境のほうが平均的に応答性能が高いという結果もあり得るわけです。

そういう意味でGoをチョイスした理由とGo古参のORMとは若干ミスマッチだなぁとは思っています。
Goを選んだ場合、「シンプルなDBテーブル構成で手書きコードまたはコード生成でマッピング」とする傾向が強いというのはありそうです。

Goの賢いORMがどれかというと私もまだ把握しきれていないですが、冒頭のものはよさそうに思っています。

Comments

[nobonobo]

gobuffaloのほうはフルスタックのWebフレームワークでORMを内包しています。

[berliner]

なるほど、しっかりとGoの強みをいかせるようなDB設計と参照をしない(できない)限り、わざわざGoを選ぶメリットはさほどないということですかね。
ただ、その点はGoに非があるというよりかは単純に利用されてる歴史の長さでしょうか。もしくは自分が思ってるよりももっと限定的なところで真価を発揮するためにGoが作られたのであって、普通のWeb API程度ではNodeで十分なのかもしれません。
その辺ももっと理解していきたいと思います。

ご親切にありがとうございました。