背景：なぜTypeScriptをやめたのか
もともとバックエンドは以下の構成でした。
- Next.js
- TypeScript
- ORM: Prisma
- コンテナ: Docker
TypeScript自体に不満があったわけではありません。
むしろ開発体験は非常に良好でした。
ただ、プロダクトが成長するにつれて次の課題が顕在化しました。
- 高負荷時のレイテンシ増大
- メモリ使用量の不安定さ
- コンテナ起動時間の遅さ
- 型があっても「実行時エラー」は普通に起きる
「スケールを見据えたとき、このままで良いのか？」
という疑問が、Go移行のきっかけでした。
結論：TypeScriptからGoに変えたら○○だった
結論から言うと、
運用が圧倒的にラクになった
これに尽きます。
以下、具体的に見ていきます。
良かった点①：パフォーマンスを“考えなくていい”
Goにして最初に驚いたのは、
特に何も工夫していないのに速いことでした。
- レスポンスタイムが安定
- GCで悩まされない
- CPU・メモリ使用量が予測しやすい
TypeScript時代は、
- 非同期処理の書き方
- ライブラリの癖
- Nodeのバージョン差
を意識する必要がありましたが、Goではそれが激減しました。
良かった点②：シングルバイナリの破壊力
Goはビルドすると単一バイナリになります。
これが想像以上に強力でした。
- Dockerfileが極端にシンプル
- 本番とローカルの差分がほぼゼロ
- デプロイが「置き換えるだけ」
Node.js特有の
- node_modules地獄
- lockfile差分
- Alpineとの相性問題
から完全に解放されました。
良かった点③：コードの“統一感”が出る
Goは言語仕様がかなり制限されています。
その結果、
- 書き方が自然に揃う
- レビューで揉めない
- 属人性が下がる
という副次効果がありました。
TypeScriptでは起きがちな
- 書き手による設計のばらつき
- 謎に凝った型定義
がほぼ消えました。
正直しんどかった点①：初速は遅い
Goはシンプルですが、
TypeScriptほどの即効性はありません。
- ORM周りの実装が冗長
- ジェネリクスの表現力は控えめ
- 便利ライブラリは自作前提
「サクッとAPIを生やす」体験は
TypeScriptの方が上です。
正直しんどかった点②：型で遊べない
TypeScriptに慣れていると、
Goの型システムは物足りなく感じます。
- Conditional Typesがない
- 型レベルプログラミング不可
ただし、それが逆に保守性を上げている
というのも事実でした。
移行して分かった「Goが向いているケース」
以下に当てはまるなら、Goはかなり有力です。
- 中〜大規模のバックエンド
- 長期運用が前提
- パフォーマンスと安定性重視
- チーム開発で属人性を減らしたい
逆に、
- MVP開発
- フロントエンドとコード共有したい
ならTypeScriptの方が幸せです。
まとめ
TypeScriptからGoへの移行は、
- 開発体験はやや落ちる
- 代わりに運用体験が激的に良くなる
というトレードオフでした。
個人的には、
「プロダクトが育ったらGo」はかなりアリ
という結論です。
この記事が、同じ悩みを持つ方の判断材料になれば幸いです。