Goの組織でバックエンドTypeScriptを採用してどうだったか / How was adopting backend TypeScript in a Golang company

2025/04/22
フルスタックTypeScriptの現在地：3社が本音を語るハイブリッド勉強会
https://toggle.connpass.com/event/349725/

Goの組織でバックエンドTypeScriptを採用してどうだったか

@osuzu
ソフトウェアエンジニア

Transcript

1. Goの組織でバックエンドTypeScriptを 採用してどうだったか osuzu フルスタックTypeScriptの現在地 @20250422
2. Agenda 1.なぜバックエンドTSを選んだ？ 2.どう開発をしているか 3.バックエンドTSを選んでどうだった？ 　3-1.モダンなモノレポがとても良かった！ 　3-2.フルスタックTSの開発はGoに比べてどう？ 　3-3.結局TSを選んでよかったの？
3. 1.なぜバックエンドTSを 選んだ？
4. なぜバックエンドTSを選んだのか GoやTypeScriptの言語自体の問題のような積極的な理由ではなく、 チームやプロジェクトに起因する消極的な理由がきっかけでした。 ・リリースまでの開発期間が短かった。書くコード量が多くなりやす いGoではなく、短期的なスピードが見込めるTSを選んだ。 ・エコシステムや設計にオーナーシップ持てるGopherが居なかった ため、TSの方が良いものを作れる確度が高かった。 ※カミナシにはGopher多いですが新プロダクトの人的リソース起因 あるスコープで積極的な技術選定（エコシステムや設計での良い選 択）をするために、上位のスコープ（言語やアーキテクチャでの選 択）で消極的な技術選定になったとも言えます。
5. バックエンドTSで何を期待していたか とはいえバックエンドTSを選定したことには、 もちろん狙いや期待もありました。 ・モノレポで構成し、バックエンドとフロントエンドのコンテキスト スイッチを極力減らす。 ・型への期待と、フロントエンドの開発パラダイム（宣言的、関数 型、冪等性、イミュータブル等）とサーバーの開発パラダイムを合わ せること。 ・組織として特定の言語やフレームワークにフルベットしない。運用 を通して自組織（ドメイン）に応じたトレードオフの学びを得る。
6. 2.どう開発しているか
7. どう開発しているか
8. Backend Tech Stack - Web Framework - Hono - ORM - Prisma (Typed SQL GA 待機勢) - API Spec - OpenAPI (Hono RPCを利用) - Authorization - Casbin 　　　※Authenticationは別サービスの責務。本APIはtoken introspectionのリクエストを送るだけ。 - Validation - Zod (v4 待機勢) - Observability - @opentelemetry/~ (api, instrumentation等) - Datadog - Testing - Vitest - Lint/Format - Biome
9. 3.バックエンドTSを 選んでどうだった？
10. 3-1.モダンなモノレポが とても良かった！
11. モダンなモノレポがとても良かった！ pnpmとTurborepoによりモノレポ開発が進化していました！ 何年か前に試したとき(Lernaなどの世代)に比べ、 構築も楽でCI/CDや開発体験がよくなっています。 Turborepoで複数アプリが立ち上がる様子。 UIが良く、モノレポで課題になりやすい デプロイ効率化の解決策になるような キャッシュの仕組みを持っている。 pnpm catalogでのバージョン管理。 ライブラリのバージョンなどが中央集権的に管 理できる（各アプリで統一できる） renovateやdependabotも対応済み。
12. スタートアップがモノレポでやる意義 カミナシではフルサイクル開発者を採用しており、チームやプロダク トやコードベースへのオーナーシップを持つことを重視しています。 そうした環境でモノレポでやることの意義は大きく、オーナーシップ を持ちやすくすることに繋がっている感覚があります。（弊チームで はterraformのコードも同じリポジトリで管理してます） 特にスモールチームでは1つのチームが1つのリポジトリに結びついて る状況が一番パフォーマンス出ると経験上思います。 チームとコードベースが1:NやN:1やN:Nになるにつれ、どうしても オーナーシップは薄まっていくのではと。
13. 3-2.フルスタックTSの開発は Goと比べてどう？
14. TSをGoと比べて:コンテキストスイッチはどうだったか 言語的な文法の他、型表現の柔軟さに差があり（TSの方が柔軟）、GoとTSの 行き来の大変さは型面で特に大きかったです。 ライブラリやエコシステムの差（キャッチアップコスト）も重く、両面に習 熟するのは困難。TSもGoもある意味似てる部分として、小さなライブラリや モジュールを組み合わせるのが一般的で、ORMやバリデーションなど様々な 分野で選定の余地があります。（両方に通ずるのが難しい） 例えばGoでsamber stackを採用するとTSに書き味近くなったりします。 逆にライブラリ選定を工夫することで、言語問わない層を用意する発想も可 能です。例えばSQLCやConnectやPrismaといったライブラリはTSでもGoで も動作し、言語に依存しないコードが中心になります。 カミナシでは認可としてcasbinが広く使われており、言語に依存しません。
15. TSをGoと比べて:Goのが良かった面（TSで工夫が必要な面） TSは書きやすく、Goは読みやすいという表現がされますが同意します。 Goは書き味が愚直でミスりづらいというチームの感想もありました。 特にTSではエラー周りの設計はちゃんとしないとGoよりミスが起きやすくな る印象です（TSでもneverthrow使うなどの工夫もありますが） テスト面では、TSは動的に閾値のコード換えられたりモックが強力だったり するので、どんなテストも出来てしまう便利さはありますが、モックが強力 なゆえDIも不要になる状況も多く、依存関係の整理や方向すらも無法地帯に なりやすい印象です。 Goは誰が書いても同じコードになりやすいですが、TSはそうではなく、責務 を曖昧にしてもコードが書けてしまう注意点があります。
16. TSをGoと比べて:TSのが良かった面 私のチームではNext.js App Router(RSC)を採用してますが、RSC時代のアー キテクチャでは、フロントエンドとBFFとAPIの領域が溶けあいます。 マルチプロダクト（マイクロサービス）の世界で、検索のAPIアグリゲーショ ンや認可の責務をどこで持つのか等を個別に検討する必要があります。 バックエンドTSはRSC時代のマルチプロダクト（マイクロサービス）アーキ テクチャにあってると考えてます。バックエンドとBFF間で言語や専門性の境 界を作ると、本来ロジックを置くべき場所を考慮せず、チームや人のバラン スで持つ場所を決めてしまう印象があります。 またモノレポ × RPCという選択もTSのエコシステムでは十分に可能になって きており、サーバークライアントをまたいでもモノレポで関数を呼ぶだけ、 しかもそのIOの型が共通という体験は、タスクによっては圧倒的に楽で高速 になります。React書くGopherにぜひ一度体験して欲しいです😂
17. チームでこれから改善していきたいこと CQSで設計を分け、Command側の特にドメインロジックに対して TypeScriptをより活用していきたいと考えています！ 具体的にはドメインモデルやドメインイベントを型システムや関数で 表現していく、集約を扱っていくなど。 Query側は整合性の担保など要らない代わりにパフォーマンスの問題 が出やすいため、APMを活用しながらインデックスや クエリ最適化を個別に進めていきます。 — 現在弊チームでは「関数型ドメインモデリング」本の読書を行っています。 また、この分野では一休さんの発信に刺激をいただいてます！ https://speakerdeck.com/naoya/functional-typescript https://speakerdeck.com/naoya/typescript-guan-shu-xing-sutairudebatukuendokai-fa-noriaru
18. 3-3.結局TSを選んで よかったの？
19. TSを選んで:コスト周り ドメインやサービスによるが、ほとんどのSaaSではバックエンドTS を選択できると思いました（コンピューティングのコスト面で） ボトルネックになっているのがI/OとDBまわりで、アプリケーション はコストのネックになっていません。（Thread処理を多くやりたい 等の特性があるならGoの方がいいかも。複数のデータソースをアプリ ケーション層でLoopして突合するとか。ただしこうしたケースでバッ クエンドGoだとしてもBFFがTSなら、結局そちらでアグリゲーション した方が楽だし素直なことも多い。） Per Requestの売上が高いビジネスならば（リクエストが極端に多い SaaS以外はそうなはず）、お金でスケールできるので、TSは自ドメ インだと十分に選定可能だったと感じてます。
20. TSを選んで:キャッチアップ面 カミナシのGopherとの知見共有がしづらいといった課題には直面しました。 （とはいえ一つの技術にベットするのもそれはそれでリスクありトレードオ フだと思いますが） またバックエンドTSでは、特に日本語だと良質な情報を発信されている組織 や人が限られている弱みがあります。 （国内だと一休さんやCloudbaseさんの発信に助けられてます🙏） ということで私からのお願いは… シニアバックエンドの皆さま、時々で良いのでバックエンドTS のこと思い出してください。（特にフルサイクル開発者） そしてReactも書くGopherの皆さま、ぜひ一度フルスタック TS & モノレポ & RPCの開発を体験してください！！
21. TSを選んで:結論 カミナシはこれからもGo中心のバックエンドであり続ける予定です が、以下のような条件下ではバックエンドTSも推奨していきたいと考 えています！ • チームにTS周りのエコシステムでオーナーシップやリーダーシッ プを持てる人がいる • APIアグリゲーションをするBFFがTSで動く（RSCなど） • コンピューティングリソースがボトルネックにならなそう、もし くはPer Requestの売上が高いビジネス領域 • モノレポでRPCして開発体験を出来るだけよくしたい • バックエンドよりもフロントエンド側に困難さの中心が寄りそう （非正規化のデータをDBに保存したくなるなど）
22. AD カミナシではエンジニア募集中です！ 散々話しといて恐縮ですが、 現在私のチームのヘッドカウントは ないため、求人はバックエンドGoと なります😂 Goもいいぞ。