RustでAPIを開発してみたら結構辛かった話

技術的要素以外の背景があった

そもそもなぜRustでやってみようとなったのか

統合テストと単体テストを別々に動かせるようにした

Fromトレイトを積極的に使って変換処理を楽にした

? 演算子を積極的に使ってエラーハンドリングを楽にした

認証済みのリクエストしかアクセスできないような制御をする仕組みを用意した

モジュールの可視性を細かく設定できる

構造体の定義と独自実装、トレイトの実装を分けて書けるので見通しが良い

静的解析が強いので、脳死で従うだけでも統一感のあるコードに近づいていく

ライフタイムが今でも理解できていない気がしているくらい難しかった

可変参照を色々なところで使わざるを得ない状況になってしまった

構造体をJSON化したいだけなのに、コードがいっぱい必要だった

（自分的に）使いやすいORMがなかった

（自分的に）テストが書きやすいとは言えなかった

kbwo

Kyosuke Awata

鏡華

magicant

白山風露

Takaaki Furuse

フラワー

Toshiki

(以下で言うORMはいわゆるActiveRecord的なものを指します) 
ORMについて、多様性に欠けるという点ではエコシステムが充実していないというのはその通りだと思いますが、発展が遅く未熟というよりは、Rust開発者がORMを好まない傾向にあるためORM開発のモチベーションが比較的少ないというのもあるのではないかなと思っています。 
明確なエビデンスがあるわけではないですが、Redditを観察しているとRustのORMやDB周りの話では毎回sqlx推しが集まっている印象があります。それもdieselが非同期処理をサポートしていないなどによる消去法的選択肢というよりは、ORMを使うことによる短期的メリットより、sqlxのような薄いながらもコンパイル時チェックなど本当に解決してほしい問題を解決してくれるものを推すようなコメントが多いように思います。 
ただ、私もsqlx推しのためそのバイアスがかかっていますし、"dieselは使いたくないけど、かといってRustのエコシステムが未熟なことを認めたくない"だけのRust開発者もいるかもしれないので、上記の印象は眉唾ものですが、こういう視点もあるというコメントでした。

コメントありがとうございます！ 
Rust開発者の傾向まではチェックできていなかったので、大変参考になります！

chronoはserdeのSerialize/Deserialize実装を提供しています 
<iframe id="zenn-embedded__7f90a5474be26" src="https://embed.zenn.studio/github#zenn-embedded__7f90a5474be26" data-content="https%3A%2F%2Fgithub.com%2Fchronotope%2Fchrono%2Fblob%2Fmain%2Fsrc%2Fdatetime%2Fserde.rs" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://github.com/chronotope/chrono/blob/main/src/datetime/serde.rs" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://github.com/chronotope/chrono/blob/main/src/datetime/serde.rs</a>
Rustは言語機能としてfeature-gateを内蔵しており、ライブラリなどにおいても使う側が必要な機能だけを有効にすることができます. 
serdeでのシリアライズ機能は、chronoの利用者のすべてが必要としているわけではないが、あると便利、みたいなものですよね. 
なのでデフォルトでは無効にしつつ、featureを指定した場合に有効になる、のように実装されています.
Cargo.tomlで
<div class="code-block-container"><pre class="language-toml"><code class="language-toml">[dependencies]
chrono = { version = "0.4.23", features = ["serde"] }
</code></pre></div>などとすればSerialize/Deserialize出来るようになるはずです

ありがとうございます！ 
こちらのやり方の方が簡単なので、もっと簡単なやり方もあるよ！と追記しようと思います！

<blockquote>
可変参照を色々なところで使わざるを得ない状況になってしまった
</blockquote>
これは内部可変性といわれるパターンで解消できます. 
記事内に書かれているRefCellも内部可変性を実現するための構造体のうちの一つです. 
RcやRefCellはSendやSyncを実装していない(スレッドを跨ぐマルチスレッド環境では安全に扱えない)ので、Webサーバーなどマルチスレッドな環境では安全に扱えるArc&lt;Mutex&lt;T&gt;&gt;などが頻出します.

<blockquote>
ユースケースやドメインサービスにこのコネクションオブジェクトを渡す必要がありました。
</blockquote>
普通、データベースへのコネクションは処理のスレッドごとに別々に用意するものじゃないでしょうか。複数の処理で同時に同じコネクションを無理やり使い回すと、あるトランザクションの途中で別のトランザクションの処理が混じるみたいなカオスな状況になりそうな気がします。
コネクションを毎回何度も接続したり切断したりするのは非効率なのでコネクションプールを使って管理するのが一般的かと思いますがいかがでしょう。

コメントありがとうございます！
<blockquote>
普通、データベースへのコネクションは処理のスレッドごとに別々に用意するものじゃないでしょうか。複数の処理で同時に同じコネクションを無理やり使い回すと、あるトランザクションの途中で別のトランザクションの処理が混じるみたいなカオスな状況になりそうな気がします。
コネクションを毎回何度も接続したり切断したりするのは非効率なのでコネクションプールを使って管理するのが一般的かと思いますがいかがでしょう。
</blockquote>
その通りだと思います！ 
そして今回もそのような作りになっています！
具体的には以下のような流れになります（詳細はサンプルコードを読んで頂けると分かりやすいかと思います）
<ol>
<li>
<code>scenario</code>でコネクションプールからコネクションオブジェクトを取得</li>
<li>
<code>scenario</code>から<code>presentation</code>に定義されている関数を呼び出す</li>
<li>
<code>presentation</code>の関数では、ユースケースのインスタンスを生成する（必要ならリポジトリやドメインサービスを生成してユースケースに渡す。</li>
<li>...省略...</li>
</ol>
↑このリポジトリやドメインサービスを作る際に可変参照なコネクションオブジェクトが必要になります

返信ありがとうございます。そして本文のコードをうまく読み解けていなかったようですみません。
コネクションプールは既に使っておられて、コネクションプールからコネクションを取り出すまでは順調にできているのですね。それでいて
<blockquote>
RcとRefCellを組み合わせて無理やり可変参照を複数の場所から参照できるようにしました
</blockquote>
ということが必要だったということは、ユースケースやドメインサービスの中にコネクションの参照を保持しているということでしょうか。コネクションを保持するオブジェクトが複数あるのであれば一つのコネクションを共有するために Rc&lt;RefCell&gt; のパターンが必要になってくるのも腑に落ちます。
ただ自分ならオブジェクト内に保持するのではなくて必要になるたびに毎回関数の引数で渡す道を選びそうだなと思いました。その方がコンパイル時チェックに頼れる範囲が広いので。

<code>From</code> トレイトの話をするなら <code>Into</code> トレイトの話を入れてほしかった感。 <code>From</code> トレイトの嬉しい点は <code>From</code> トレイトを実装すると <code>Into</code> トレイトが自動的に実装されて、 <code>into()</code> で気軽に型変換できることだと思うので、 <code>X::from(y)</code> の形で使用することだけだと本当になんかちょっと短くなっただけで<code>X::from_y(y)</code> を実装するのと大差なくなってしまう

(マジレスでなく、ジョークとして読んでください。)
RobynというPython製のフレームワークがありまして・・・ 
これを使うという反則技もあります。 
下ではPyO3というライブラリーを使ってAPIレベルからPythonコードをRustに変換してる感じです。
<iframe id="zenn-embedded__dcd45fffa8325" src="https://embed.zenn.studio/card#zenn-embedded__dcd45fffa8325" data-content="https%3A%2F%2Frobyn.tech%2F" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://robyn.tech/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://robyn.tech/</a>

下で動いてるのはRustなので、Rustで開発してる!(キリッ

突然の質問失礼致します。 
気になったのですが、ユースケース層やドメイン層にDBコネクションオブジェクトを持たせる理由は何でしょうか？ 
基本的なDDDのプラクティスであれば、ドメインロジックとDBやFW等の詳細を分離するため、DBコネクションはインフラストラクチャ層で実装するものと理解しています。ユースケース層やドメイン層にDBコネクションを渡した場合、この分離ができなくなると思うのですが、もし何か理由があれば教えていただきたいです。（自分の理解が誤ってるかもしれないので、その場合は指摘いただけると幸いです。）

これは記事の内容が誤ってました、申し訳ありません。
正しくは「複数のリポジトリのコンストラクタにコネクションオブジェクトを渡す必要がある」でした。 
ユースケースやドメインサービスは、生成されたリポジトリを受け取る形になりますね。
記事も併せて修正しました！ありがとうございます！ 
具体的なコードは<a href="https://github.com/wooootack/rust-ddd-sample/blob/53e03f779fc88dbafb60b01d371c08d3cba2ea59/src/modules/user/presentation/create_user.rs#L22" target="_blank" rel="nofollow noopener noreferrer">こちら</a>が分かりやすいかと思います。

いえいえ、回答ありがとうございます！そして、返信遅くなり申し訳ありません。 
DBコネクションをリポジトリに渡すということであれば、自分のDDDの理解とずれてないので納得できました。
余談ですが、ソースコード読ませていただきました。なるほど、複数の機能でDBコネクションオブジェクトを使いまわしたいから、それぞれの機能のリポジトリにDBコネクションを渡さなければならず、複数のリポジトリのコンストラクタにコネクションオブジェクトを渡す必要があるということですね。 
それで、DBコネクションは可変参照だから shared xor mutableで複数オブジェクトで共有できないと。
確かにGCありの言語なら、DB接続はインスタンス変数に持たせて使いまわしたりすることが常套手段だと思いますが、Rustだとその辺りが厄介になりそうなところかもですね。 
僕も勉強になりました。ありがとうございました。

ご存知かもしれませんが、 
JSONからRustの構造体を作りたいときはこのサイトを使うと楽になります！ 
<iframe id="zenn-embedded__71ecb6a8f120b" src="https://embed.zenn.studio/card#zenn-embedded__71ecb6a8f120b" data-content="https%3A%2F%2Ftransform.tools%2Fjson-to-rust-serde" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://transform.tools/json-to-rust-serde" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://transform.tools/json-to-rust-serde</a>