1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

移行とは“再設計”ではなく“再解釈”である:Laravel + Vue2からReact + Serverlessへの構造的転換

Posted at

はじめに:移行は単なる刷新ではない

「Laravel + Vue2」から「TypeScript + React + Serverless」への移行。
それは単に“古い技術を新しくする”ことではない。

本記事では、この移行プロセスを 技術的視点 だけでなく、構造的・思想的な転換として捉え直し、
「レガシー」から「モダン」への道のりに潜む 設計哲学のシフト を明確にします。

なぜ私たちはVue2とLaravelという強力なフレームワークの組み合わせに限界を感じ、
Reactとサーバーレスという一見バラバラな技術の組み合わせを選んだのか?
そこには単なるトレンドではなく、“設計哲学の選択”があったからです。


1. なぜLaravel + Vue2は“レガシー”化したのか?

LaravelやVue2は、当時としては非常にモダンなフレームワークでした。
しかし、現在の観点から見ると以下のような特徴が「構造疲労」を起こしやすい原因となっています:

  • 命令的UI構築(DOMと状態が密結合)
  • 非同期処理の分離困難(Vueのmethodsにロジック集中)
  • サーバー中心モデル(Laravel Controllerに副作用が密集)
  • 型安全性の欠如(動的言語としてのPHPの限界)

これらは「分離されていない責務」に起因し、コードの予測可能性・保守性・再利用性を阻害します。

特に中長期的なメンテナンスを考えると、状態・副作用・ロジックの境界線が曖昧であることは、
新しいエンジニアが参入しにくくなる要因でもありました。
結果として、採用難易度の上昇、ドキュメントや仕様の陳腐化、セキュリティリスクの増大へとつながります。


2. 新スタックが目指す“構造的安全性”とは?

React + TypeScript + Serverless は単なる最新技術の寄せ集めではありません。
その本質は以下のような 構造設計思想の結晶 にあります:

技術 設計的意義
React UIを状態の反映として宣言的に構築
TypeScript 設計情報(型)をコードに埋め込むことで整合性を保証
Serverless 責務を最小粒度の関数に分解し、構造を明示化

このように、新スタックは「責務の分離」と「予測可能性の最大化」に特化しています。

特に注目すべきは「副作用の扱い方」です。LaravelやVue2では、ロジック・副作用・表示が同一ファイルに混在するケースが多く、
処理の追跡が困難になりがちでした。それに対してReact Hooksでは副作用(useEffectなど)を明示的に分離し、
TypeScriptで型を定義することで、状態やデータの流れを“設計段階”で予測可能にできます。


3. Marmaid図:構造的転換の比較

この図からわかるように、
旧構成は責務が集約・混在しているのに対し、
新構成は機能ごとに構造的に分離されており、保守性・拡張性・採用のしやすさが大きく改善されます。


4. コードで見る構造の違い

Laravel + Vue2 の登録処理

// Laravel Controller
public function register(Request $request) {
  $user = User::create($request->all());
  Mail::to($user->email)->send(new WelcomeMail($user));
  return response()->json($user);
}
<template>
  <form @submit.prevent="register">
    <input v-model="name" />
    <input v-model="email" />
  </form>
</template>

<script>
export default {
  data() {
    return { name: '', email: '' };
  },
  methods: {
    async register() {
      await axios.post('/api/register', { name: this.name, email: this.email });
    }
  }
}
</script>

React + Serverless の登録処理

// RegisterForm.tsx
const RegisterForm = () => {
  const [form, setForm] = useState({ name: '', email: '' });

  const onChange = (e: React.ChangeEvent<HTMLInputElement>) =>
    setForm({ ...form, [e.target.name]: e.target.value });

  const onSubmit = async () => {
    await fetch('/api/register', {
      method: 'POST',
      body: JSON.stringify(form),
    });
  };

  return (
    <form onSubmit={(e) => { e.preventDefault(); onSubmit(); }}>
      <input name="name" onChange={onChange} />
      <input name="email" onChange={onChange} />
    </form>
  );
};
// serverless/api/register.ts
export const handler = async (event) => {
  const { name, email } = JSON.parse(event.body);
  await saveUserToDB(name, email);
  await sendWelcomeEmail(email);
  return { statusCode: 200 };
};

ここで注目すべきは、UI・ロジック・副作用の完全な責務分離です。
React側は状態管理とUIだけに専念し、Serverless Functionが副作用(メール送信・DB操作)を受け持ちます。


5. 採用・育成観点からの効果

新しい技術スタックは、学習曲線がある一方で、設計が明示的であるがゆえに属人化しにくいという利点があります。

TypeScriptの導入により、チーム内での設計共有がコード上で成立し、PRレビューやオンボーディングもスムーズになります。
また、ReactやServerlessはエコシステムとしても拡張性が高く、モジュール分割・再利用性・テスト容易性にも優れます。

採用面でも、「モダンな構成を使っているチーム」としての訴求力は大きく、エンジニアからの注目度も高まります。


結論:移行とは「再構成」であり「再解釈」である

  • Laravel + Vue2 の構造は「一箇所で全てやる」思想に基づく
  • React + Serverless は「責務を分け、明示する」思想に基づく
  • よって、移行とは単なる技術刷新ではなく、「思想の乗り換え」である

技術選定とは、チームがどう世界を捉えるかの哲学的選択なのです。


おわりに:思想に気づくことで移行が“納得”になる

レガシーからモダンへの移行を成功させる最大の鍵は、
「なぜこれが良いのか」を構造として理解することです。

そしてその理解は、単なる技術ドキュメントではなく、
価値観・設計思想・構造的安全性といった観点から深めることで、
チーム全体の納得感・実装精度・採用戦略すらも変えていくことができます。

移行を“刷新”ではなく、“再構成”として考え直してみましょう。


付録:技術選定チェックリスト(簡易)

観点 Laravel + Vue2 React + Serverless
状態管理 コンポーネント内部 or Vuex useState / Zustand / Redux
UI構築 v-model命令型 JSX宣言型
副作用制御 methods内部 useEffect + 外部関数
型の扱い 動的 静的(TS)
テスト容易性 難(密結合) 高(分離)

この表を元に、自プロジェクトが「どこに移行の障壁を感じているか」を整理してみるのもおすすめです。

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?