今回の背景
私の今いる企業は自社開発の製品を持っているのですが、「あまりイケてない」企業です。
テストやドキュメントなど存在を知っているのかと疑うレベルですし、使っている技術も少し古いです。
リプレイスを提案してみても受け入れられるかわからないので、今回勝手にリプレイスするならこんな技術を使うという仮定のもと技術選定をしてみました。
1. 現状の課題認識
- 使用技術：EJS + jQuery
- 強み：SSRによる高速な初期表示
- 課題：
- jQueryによるDOM操作の煩雑化・スパゲッティコード化
- UIや状態の再利用・分離が困難
- テストしづらく、保守性が低い
2. モダン化の方向性を検討
- フロント：ReactによりUIの再利用性を高めたい
- バックエンド：既存のExpress資産を活かしたい
- 開発効率と保守性を両立させる構成を模索
3. なぜモダン化するのか？
- 保守性と拡張性を大幅に向上させるため
- 将来的なスケール（チーム、機能、サービス分離）に備えるため
- テスト可能で安全な開発基盤（型、状態管理、ESLint、CI対応）を整備したいため
- 社内や外部との共通言語としてReact + TypeScript環境を導入
- jQueryは開発も活発でなく今後のアップデートもあまり期待できない
- 社外へのアピールになる
4. SSR、SSG、CSRの違い（Next.js視点）
| 項目 | SSR | SSG | CSR |
|---|---|---|---|
| HTML生成 | リクエスト時 | ビルド時 | クライアントで描画 |
| 表示速度 | ◯（やや遅） | ◎（高速） | △（JS読み込み後） |
| データ更新 | ◎ 最新 | △ 更新には再ビルド必要 | ◎ 最新 |
| SEO対応 | ◎ | ◎ | △（遅延が発生） |
| 用途 | 動的ページ全般 | LPやブログなど静的ページ | SPA内部のUI更新 |
今回は元々EJSなこともあり、スピードを重視したいのとデータの更新が頻繁に行われる構成のためSSRを行えることを基準に選定しました。
5. Next.jsに注目（React + SSRを実現するため）
- Reactの利点（コンポーネント、Hooks、SPA的UX）とSSR（初期表示の速さ）を両立
- ページ単位でSSR/SSG/CSRを選べる柔軟性
6. Expressとの共存構成を検討
- 既存Expressを活かすため、Next.jsをカスタムサーバーとして統合
- Express：API、Next.js：フロントとして責務を分離
- API呼び出しとページ描画の分担が可能
7. フロントとバックを1プロセスで統合運用する是非
メリット
- インフラ構成がシンプル
- CORS不要で開発しやすい
- CI/CD・デプロイが一本化できる
デメリット
- スケーラビリティの限界
- 再起動・障害時に影響範囲が大きい
- 将来的なサービス分離が困難になる可能性
8. TypeScriptを検討
- 型安全性によるバグ抑制、リファクタリング耐性向上
- フロント・バック共通で型定義を活用できる
- 状態管理やForm処理、APIのレスポンスなどで型が有効
- Next.js, ExpressともにTypeScriptとの親和性が高い
- JavaScriptを使っていることもあり、学習コストが低い
9. リプレイスの段階的戦略
- Express + EJSを
/v1、Next.jsを/v2に分離して共存構成構築 - 優先度の高い動的ページを Next.js + SSR で実装（例：ダッシュボード、プロフィール）
- jQueryのDOM操作を React コンポーネントに段階的に置き換え
- Express API を
/api/**に再設計し、Next.jsからfetchで利用 - 状態管理や認証処理を React 側で再実装
- 将来的に Next.js の API Routes にも移行可能なよう構成を整理
10. 最終目標像
- 表示速度を犠牲にせず、React + TypeScriptによる開発基盤を確立
- Express APIとフロントを疎結合化し、保守性とテスト性を向上
- 柔軟な拡張・再利用が可能な構成
- 将来のサービス分離やマイクロサービス化にも耐えられる基盤
技術スタックと設計戦略まとめ
| 項目 | 採用技術 | 理由 |
|---|---|---|
| フロント | Next.js + React + TypeScript | 表示速度と開発効率を両立 |
| バックエンド | Express（API専用） | 既存資産活用、柔軟なAPI設計 |
| 実行構成 | Next.js + Express 統合プロセス | インフラ簡素化、初期構築の高速化 |
| 状態管理 | React Hooks / Context / Zustand など | UIの再利用、jQuery脱却 |
| ビルド管理 |
tsconfig, webpack, esbuild（Vite）など |
フロント・バック分離ビルドを視野に |
| スタイル | Tailwind CSS / shadcn/ui | コンポーネント化と開発効率を向上 |
以上、勝手にリプレイスの技術選定を妄想してみました。
これを元にリプレイスの提案をしてみようと思います。
ツッコミ、コメント、お待ちしております！