1. はじめに
ふだん、チーム開発などの現場に活かす目的で、実務を想定し個人開発しています。
この取り組みで得たいのは「新しい技術をただ学ぶ」ことではなく、課題を解決するために技術を選定・習得する力です。
この記事では、具体例として家計簿アプリを挙げます。
最初はLaravel(Blade)+jQuery(Ajax)のMVC構成で作っていたのですが、
運用していく中で開発効率や画面速度の課題が見えてきました。
実際に感じた課題と、それを解決するために
Vue.jsを使ったSPAへ段階的に移行している過程をまとめます。
この記事は自分のメモ・学習用という趣きが強いですが、
同じような課題を抱えている方の参考になれば幸いです。
2. 現在の構成
■ 技術スタック
- バックエンド: Laravel 10.x
- フロントエンド: Blade + jQuery
- DB: MySQL 8.0
- インフラ: XServer VPS(素のLinux環境)
■ 機能概要
- 支出・収入の登録、編集、削除
- カテゴリ別の集計表示
- 月次・年次のグラフ表示(Chart.js使用)
- CSVエクスポート機能
3. 実際に感じた課題
課題1: 画面開発の効率が悪い
Bladeテンプレートでは、HTMLの中にPHPのロジックが混在します。
例えば、支出一覧画面のコード:
@foreach($expenses as $expense)
<tr>
<td>{{ $expense->date }}</td>
<td>{{ $expense->category->name }}</td>
<td>¥{{ number_format($expense->amount) }}</td>
<td>
@if($expense->is_fixed)
<span class="badge">固定費</span>
@endif
</td>
</tr>
@endforeach
この書き方だと、
・表示ロジック(number_formatやバッジの出し分け)がテンプレートに散在
・再利用可能なコンポーネント化が難しい
・同じようなUI(日付フォーマット、金額表示)を何度も書く
結果、新しい画面を追加するたびに似たようなコードをコピペする羽目に。
カテゴリ別集計画面でも同じ金額フォーマット処理を書き、
グラフ画面でも同じ処理を書き...と、保守性が低下していきました。
課題2: 画面遷移が遅い
MVCは基本的に同期通信なので、毎回サーバーへのリクエスト→HTML生成→レスポンス
という流れになります。
具体的な体感:
・支出一覧 → 支出登録フォーム: 約1.2秒
・登録後に一覧へ戻る: 約1.5秒
・月次集計 → 年次集計の切り替え: 約1.8秒
合計で約4.5秒。1日に10回操作すると45秒のロスです。
特に辛かったのが、「登録→一覧確認→また登録」の繰り返し。
買い物から帰って、レシートを見ながら5件入力する時、
毎回1.5秒待つのはストレスでした。
また、ページ遷移のたびに画面全体が白くなる(再描画される)のも
UX的にイマイチだと感じていました。
課題3: Ajaxで部分的に改善したが、根本解決にならず
一部、Ajaxで非同期化してみました。
例: 支出の削除処理
$('.delete-btn').on('click', function() {
$.ajax({
url: '/expenses/' + expenseId,
method: 'DELETE',
success: function() {
// DOM操作で該当行を削除
$('tr[data-id="' + expenseId + '"]').remove();
// 合計金額も再計算して更新
updateTotalAmount();
}
});
});
これで削除は速くなったものの、新たな問題が:
・DOM操作が散在して、どこで何を更新しているか追いづらい
・削除後の合計金額計算ロジックがJS側にも必要になり、二重管理
・エラーハンドリングが不十分で、通信失敗時にUIと実データが乖離する
部分的な改善では限界があり、「フロントエンドを体系的に設計し直す必要がある」
と感じました。
4. SPAにリプレイスする理由
上記の課題を解決するため、SPAアーキテクチャへの移行を決めました。
■ 期待する効果
1. コンポーネント指向で開発効率UP
Vue.jsのSFC(Single File Component)なら、
金額表示、日付フォーマット、カテゴリバッジなどを
再利用可能なコンポーネントとして切り出せます。
2. 画面遷移の高速化
初回ロード後は必要なデータだけをAPIで取得。
ページ全体の再描画が不要になり、体感速度が大幅に向上するはず。
3. フロントエンドの状態管理を体系化
Piniaなどの状態管理ライブラリを使えば、
「どのコンポーネントがどのデータを保持しているか」が明確になります。
4. 他の開発者が参画しやすい環境へ
現状は素のLinux環境で、環境構築がやや面倒。
Docker化することで、docker-compose upだけで開発環境が立ち上がるようにします。
5. 段階的な移行計画
いきなり全てをリプレイスするのはリスクが高いので、
段階的に移行していく計画です。
【フェーズ1】Vue.jsの基礎習得(現在ここ)
・Todoアプリで基本文法を習得
・v-for, v-if, v-model, イベントハンドリング
・computed, watchの使い分け
実際に作ったもの:
- タスク追加・削除・完了チェック
- フィルタ機能(全て/未完了/完了済み)
- LocalStorageへの保存
習得期間: 約2週間(平日1時間、休日3時間)
【フェーズ2】Vue Routerでページ遷移
・/expenses(一覧), /expenses/create(登録)などのルーティング
・ナビゲーションガードで認証チェック
・クエリパラメータでの絞り込み(/expenses?category=food)
ここまでで「SPAの骨格」が完成。
【フェーズ3】バックエンドのAPI化
・Laravel側をAPI専用に変更(Laravelはそのまま使う)
・axiosで非同期通信
・ローディング状態の管理
・エラーハンドリングの統一
現在のControllerをベースに、JSON返却に変えるだけなので
そこまで大きな変更ではないはず。
【フェーズ4】TypeScript導入
・型定義でバグを事前防止
・IDEの補完が効いて開発効率UP
正直、ここまで行けるかは未定ですが、
Vue.jsに慣れてきたら挑戦したいと思っています。
【フェーズ5】Docker化
・docker-compose.ymlで環境定義
・Dockerfile(PHP, Nginx, MySQL)
・.env.exampleで環境変数管理
チーム開発を想定し、目指す状態は、
「Docker入れてcompose up叩けば動く」
6. 現在の学習状況と詰まったポイント
■ 実際に手を動かして分かったこと
1. 公式ドキュメントが分かりやすい
Vue.js公式のチュートリアルは、段階的に学べて良かったです。
特に「Reactivity Fundamentals」の章で、refとreactiveの違いが腑に落ちました。
2. Composition APIとOptions APIの選択
最初Options APIで書いていましたが、
ロジックの再利用を考えるとComposition APIの方が良さそう。
今は全てComposition APIで書き直しています。
3. 詰まったポイント: 子コンポーネントへのデータ渡し
propsで渡すのか、emitで親に通知するのか、Piniaで共有するのか。
最初は全部propsで渡そうとして、バケツリレーが発生しました。
解決策:
→ 表示用データはprops
→ ユーザー情報など複数コンポーネントで使うものはPinia
→ ボタンクリックなどのイベントはemit
この整理ができてから、コンポーネント設計がスムーズになりました。
7. まとめと今後
個人開発だからこそ、実際に使って感じた課題をもとに、
新しい技術にチャレンジできています。
MVCで動いているものを「あえて」リプレイスするのは、
一見無駄に思えるかもしれません。
でも、
・実際の課題を解決する文脈で学べる
・before/afterで技術的な効果を実感できる
・失敗してもユーザーは自分だけ
という点で、非常に良い学習機会だと感じています。
（冒頭にも書きましたが）
この記事は自分のメモ・学習用という趣きが強いですが、
同じような課題を抱えている方の参考になれば幸いです。