はじめに

インフォメティス株式会社でのアプリ開発ではJotaiを採用しています。

また、TypeScriptも積極的に使い、end-to-endでの型安全を目指しています。

Jotaiの利用範囲を広げていく中で、APIも検討視野に入りました。その際、tRPCを活用する案が出てきました。

そこで、、、。

jotai-trpcの開発

jotai-trpc というライブラリを開発しました。初期のバージョンはほんの30行ほどの簡単なラッパーライブラリでした。atomWithQueryだけを実装したもので、tRPCのVanilla Clientを呼び出すだけでしたが、ちゃんと使えるものになりました。

その後、atomWithMutationなど追加機能も実装し、tRPCのVanilla Clientを全て対応しました。

tRPC Vanilla Client

ところで、jotai-trpcの開発途中に、tRPCの作者からもうすぐv10が出るよと聞かされました。公開予定のv10のAPIを調べてみると、とても大きな変更があることを知りました。短くない道のりでしたが、tRPCのコミッターとも相談しながら、v10対応のjotai-trpcが完成しました。

採用する準備は整ったのですが、、、。

tRPCは採用せず

結果として、tRPCおよびjotai-trpcは、インフォメティス株式会社でのアプリ開発では採用しませんでした。いくつかの理由があるのですが、ポイントをまとめるとおよそ次のようになります。

v9からv10からの変更が大きく、近い将来、仮にv11が登場した時の変更の大きさが予想できなかった
とあるプロジェクトではApollo Clientおよびgraphql-codegenを使用しており、すでにend-to-endの型安全が実現できていた
とあるプロジェクトではバックエンドとフロントエンドのリポジトリが分断していて、tRPCによる型の共通化がやりにくかった

将来的には分かりませんが、現状の構成では採用するメリットが薄かったことになります。

おわりに

とは言え、場合によってはtRPC採用のメリットはあるとは思っています。特に、GraphQLがオーバースペックなケースで、型安全だけを実現したい場合はtRPCのマッチ率は高いでしょう。

現状、jotai-trpcの完成度はそれほど低くないと思います（依然として簡単なラッパーであるため）が、利用実績もそれほどなさそうです。理由の一つとして推測しているのが、tRPCを使いたいユーザの多くが、react-queryやNext.jsを採用しているからだと思います。それらとjotai-trpcを組み合わせることは不可能ではないにしてもあまり自明ではありません。joti-trpc自体に興味を持ってくださる方はいるようなので、今後の発展に期待します。

最後に、インフォメティス株式会社の採用情報はこちらにありますので、ご興味をお持ちになられた方は是非ご覧ください。