RPC導入_失敗の理由

Transcript

1. RPC導入で失敗する たった1つの理由 2026/4/23 柿 海斗
2. ⾃⼰紹介 ・柿 海斗（@cu30rry_） ・ENECHANGE株式会社 ・Webアプリケーションエンジニア ・業務: TypeScript, React, Next.js, TanStack Start ・個人: TanStack Start, Hono, ElysiaJS, ReactNative Expo
3. アジェンダ
5. Satisfaction（使った⼈の満⾜度） Interest（使ってみたいか）
6. 結論
10. 具体例① 仕様把握
11. 具体例② ドキュメント作成が負荷
12. 技術選定とDX（開発体験）の関係性 適切な技術選定は単なるツール選択でなく、開発プロセス全体を改善する意思決定です
13. RPCにおける技術選定で何を意識すべきか RPCの課題を意識した技術選定をしましょう！
14. ユースケースとフレームワーク ‧✅ OpenAPI⽣成が必要: ElysiaJS or oRPC ‧✅ 軽量でシンプルに始めたい: Hono ‧✅ 学習コストを抑えたい: Hono ‧✅ Next.jsと使⽤したい: oRPC ‧✅ その他FW / AI SDKなどと連携したい: ElysiaJS ‧✅ パフォーマンス重視: ElysiaJS
15. 重要項⽬による⽐較
16. tRPC ✅ Pros ・既存知見・採用事例が豊富 ⚠ Cons ・OpenAPI生成に追加の依存関係が必要（ trpc-to-openapi or oRPC） ・HTML設定など手書きする必要がある ・trpc-to-openapiに関してはサポートされている SchemaがZodのみ
17. tRPCの実装① ・HTML設定の記述が必要
18. tRPCの実装② ・procedureにopenAPIのmetaタグ 記述などを全てのrouteに対して記述 するため実装コストが高い
19. oRPC ✅ Pros ・OpenAPIをファーストサポート ・Next.jsとの相性が特に良い（ Server Actionsのサポートなどもある） ・Date・File・Blob・URLなどNative Typeをサポート ・その他Lazy Routerによるコールドスタート対策など機能が豊富 ⚠ Cons ・情報量・採用事例が少なめ
20. oRPCの実装① ・OpenAPIReferencePluginで ドキュメントの設定を集約 ・docsProvider optionで SwaggerUIでの生成も可能
21. oRPCの実装② ・全てをosに集約できる ・エラー定義だけでなく Middlewareの定 義なども追加可能
22. oRPCの実装③ ・actionable modifierを追加すれば Server Actionsも定義可能 ・useServerActionsはReactの useActionStateの上位互換
23. Hono ✅ Pros ・Web標準で軽量かつシンプル ・Hono CLIがあり、CLI型 Agentとの親和性が高い ・JS界で最速の Router RegExpRouterを搭載 　・2025年10月には更に軽量で速い PreparedRegExpRouterが発表された ⚠ Cons ・OpenAPIが標準サポートでなく、実装時の記述量・依存関係が増える
24. Honoの実装① ・追加の依存関係にhono-openapi や@scalar/hono-api-referenceが 必要 ・SchemaにZod以外を使用する場 合は、@hono/standard-validator が必要
25. Honoの実装② ・describeRouteにOpenAPIの定義を表現する必要がある （openapi.ymlをコードで表現する必要がある） ・特にresponseの部分は、StatusCodeごとに定義が必要 （1機能ならいいが、これが 10・20と増えると かなりの記述量になる）
26. ElysiaJS ✅ Pros ・Zero-configのOpenAPI機能 ・圧倒的なパフォーマンスで Go・Rustに匹敵する （Expressの約21倍、Honoの約2.5倍） ・公式やコミュニティからの Pluginが豊富で認証・監視など機能を後付できる ⚠ Cons ・チームによっては学習コストが激増する
27. ElysiaJSの実装① ・3通りのOpenAPI生成 　① ランタイムスキーマの活用 　② 指定Routeの型推論 　③ ①・②を共存 ・②の場合、 fromTypesのみ指定すれば、 Schema定義不要で OpenAPI生成が可能 ・③の場合、ランタイムスキーマが優先される ・Schemaなど定義が fixするまでは②を採用し、 fix後に共存させるなど、柔軟な開発方針を取れ る
28. ElysiaJSの実装② 型推論を使⽤する場合 ・最低限のOpenAPIのdetail情報のみで定義す るだけで良い ・requestやresponseの型は自動推論される
29. ElysiaJSの実装③ ランタイムスキーマを活⽤する場合 ・request（params・query）やresponseの 型定義が必要 ・しかし、Honoのように各StatusCodeで openapi.ymlのような記述をしなくてよく、 responseの型のみ記述するだけでよい
30. 個⼈的な推しはElysiaJS ‧✅ 唯⼀のBunネイティブフレームワーク ‧✅ パフォーマンスはHonoより良く、GoやRustに匹敵する ‧✅ 最も簡単にOpenAPI連携ができる ‧✅ マルチランタイムサポート（Node‧Bun‧Edge‧etc） ‧✅ 公式‧コミュニティのPluginが豊富 ‧✅ イベントベースのMiddlewareで細かい制御ができる （HonoやExpressはキューベース） ‧✅ Elysia 2で初期化‧メモリなどがより速く‧軽量となることが期待でき る https://x.com/saltyAom/status/1991564346535948630 https://x.com/saltyAom/status/2040963262096031913
31. まとめ DX（開発体験）を設計対象にしていない技術選定は、 将来的に失敗する可能性を⾼めます 「コードを書くスピード‧効率」だけでなく、 「仕様の共有しやすさ」「保守‧運⽤のしやすさ」を含めた ライフサイクル全体で最適なツールを選びましょう！
32. 良かったら記事も読んでみてください！ https://zenn.dev/sc30gsw/articles/6be1b73d3db81b
33. https://zenn.dev/sc30gsw/articles/1c13f3f44b40e5
34. 詳細はエンジニア採用サイトもご覧ください！ “エネチェンジ エンジニア” で検索🔍 エンジニアを積極採用しています！ エンジニア採用サイト カジュアル面談申込 エネルギーの未来をつくる CHANGING ENERGY FOR A BETTER WORLD
35. 付録 tRPC‧oRPC‧Hono‧ElysiaJS ⽐較ソースコード https://github.com/sc30gsw/tanstack-rpc-comparison tRPC‧oRPC‧Hono‧ElysiaJS ⽐較アプリ https://tanstack-rpc-comparison.vercel.app/