Lecture 01: Full-Stack SPA Architecture & System Overview
はじめに：なぜ今「DRF × Vue.js」なのか
Web開発において、フロントエンドとバックエンドを明確に分離する SPA（Single Page Application）+ REST API の構成は、現代のデファクトスタンダードの一つです。
中でも、Pythonの堅牢なエコシステムと強力なORMを持つ Django REST Framework (DRF) と、学習コストが低く柔軟でリアクティブなUI構築が得意な Vue 3 (Composition API / Vite) の組み合わせは、スピーディなプロトタイピングから中大規模の業務システムまで幅広く採用されています。
本連載では、実務でそのまま役立つ「認証（JWT）付きフルスタックSPA」をゼロから構築できる実践的なスキルを体系的に学びます。
1. システム構成図（全体アーキテクチャの理解）
本講座で目指すフルスタックなシステム構成の全体像は以下の通りです。
■ 各レイヤーの役割と採用技術
| レイヤー / 分類 | 採用技術・ライブラリ | 主な役割と特徴 |
|---|---|---|
| フロントエンド (SPA) |
Vue.js | コアフレームワーク。リアクティブで高速なUIコンポーネントを構築 |
| Vue Router | クライアントサイドでのページ遷移・ルーティングとガード機能 | |
| Pinia | 認証トークンやユーザー情報などのグローバル状態管理 | |
| Axios | バックエンド（DRF）に対する非同期HTTPリクエスト送信 | |
| サーバー周り (Web / ASGI) |
NGINX | Webサーバー。リバースプロキシ、SSL終端、静的アセットの高速配信 |
| Uvicorn | 高速なASGIサーバー。PythonバックエンドとNGINXを接続 | |
| バックエンド (APIサーバー) |
Django / DRF | コアフレームワーク。RESTful API設計、強力なORM、バリデーション |
| django-filter | クエリパラメータによる柔軟で高度な検索・フィルタリング | |
| django-allauth | ユーザー登録・ログイン・ソーシャル認証などの認証基盤 | |
| データ・キャッシュ | PostgreSQL | メインのRDBMS。堅牢なトランザクションとデータ永続化（※MySQL等も選択可） |
| Redis | インメモリデータストア。APIレスポンスのキャッシュやセッション管理 | |
| バージョン管理 | Git / GitHub | ソースコードのバージョン管理とデプロイ自動化（CI/CD） |
■ 従来のDjango（MTV）と SPA + DRF の違い
従来のDjangoでは、サーバー側でHTMLを生成してブラウザに返す「SSR（サーバーサイドレンダリング）」が基本でした。
一方、本講座で構築するアーキテクチャでは、フロントエンド（Vue.js） と バックエンド（DRF） を完全に分離し、JSON形式のデータ通信（REST API） のみでやり取りします。
| 比較項目 | 従来のDjango (Template) | DRF × Vue.js (SPA) |
|---|---|---|
| 画面の描画 | サーバー側でHTMLを組み立てて返却 | ブラウザ側でJavaScript (Vue) が動的に描画 |
| ページ遷移 | 画面全体が再読み込みされる（チラつきあり） | ページ再読み込みなし（高速で滑らかな操作感） |
| データ連携 | コンテキスト変数でテンプレートに埋め込み | JSON API 経由で非同期通信（Axios / Fetch） |
| 将来の拡張性 | Webブラウザ専用 | モバイルアプリ (iOS/Android) にも同じAPIを提供可能 |
分離構成の最大のメリット
バックエンドは「データの取得・保存・バリデーション・認証」に専念し、フロントエンドは「UI・UX・状態管理」に専念できます。責務が明確になるため、保守性や開発効率が大幅に向上します。
2. Webサーバー（NGINX）とは？ Apacheとの違い
システム構成図の中央に位置する NGINX（エンジンエックス） は、ユーザー（ブラウザ）からのリクエストを最初に受け取る Webサーバー（リバースプロキシ） です。
■ Webサーバー（NGINX）の主な役割
- リバースプロキシ（中継役）: クライアントからのリクエストを受け取り、適切なサーバー（静的配信 or Pythonアプリサーバー）へ振り分ける
- 静的ファイルの高速配信: Vue.jsのビルド成果物（HTML/CSS/JS）や画像ファイルを高速に配信する
- SSL/TLS暗号化（HTTPS化）: SSL証明書の管理と暗号化・復号処理（SSL終端）を一括して担う
- セキュリティ・負荷分散: 不正アクセスの遮断や、複数台のサーバーへの負荷分散（ロードバランシング）
■ Apache と NGINX の違い（なぜ本構成でNGINXを採用するのか？）
Webサーバーとして長年実績のある Apache HTTP Server と、現代のSPA開発やリバースプロキシで広く使われる NGINX には、アーキテクチャや設計思想に違いがあります。
| 比較項目 | Apache HTTP Server | NGINX |
|---|---|---|
| 誕生時期 | 1995年公開 | 2004年初公開（2002年頃より開発開始） |
| アーキテクチャ |
MPM（マルチプロセッシングモジュール）方式 ・ prefork（プロセス駆動）・ worker（マルチスレッド）・ event（非同期イベント駆動） |
イベント駆動型（ノンブロッキングI/O） 少数のワーカープロセスがイベントループを用いて多数の接続を並行処理 |
| メモリ消費と接続管理 | 選択するMPMや組み込みモジュールに依存。 プロセス/スレッドを割り当てるモデルでは接続数増加時にオーバーヘッドが生じやすい |
接続数が増加してもメモリ消費が安定しており、軽量に多数の接続を維持しやすい |
| C10K問題※へのアプローチ | 従来のprefork等では大量接続時の負荷が課題だったが、近年のevent MPMで非同期処理にも対応 |
設計当初からC10K問題の解決を目的に作られており、大量の同時並行接続の処理に強みを持つ |
| 静的ファイル配信・プロキシ | 汎用的で多機能。モジュールが多く柔軟だが設定に応じたオーバーヘッドがある | イベントループとゼロコピー（sendfile）の最適化により、静的配信やリバースプロキシ処理に高い適性を持つ |
| 設定の柔軟性と運用 |
.htaccess によりディレクトリ単位での動的な設定変更が可能（共有サーバー等で重宝） |
設定ファイル（nginx.conf）による一元集中管理（リクエストごとのファイル読み込みがなく高速） |
※ C10K問題（Client 10,000 Problem）とは？
ハードウェアのスペック自体は十分であるにもかかわらず、クライアントの同時接続数が1万台（10K）規模に達した際に、接続ごとのプロセス/スレッド割り当てやコンテキストスイッチの負荷によって処理能力が低下する問題。
NGINXはこの課題を解決するため、「少数のプロセスでイベント駆動・非同期に接続を処理する」設計思想で開発されました。
SPA（Vue.js）の静的アセットを効率的に配信しつつ、Django（DRF）へのAPIリクエストを軽量なリバースプロキシとして中継する本構成においては、NGINXのイベント駆動アーキテクチャが非常に相性が良いため採用しています。
3. アプリケーションサーバーとは？（WSGI と ASGI / Uvicorn）
構成図を見ると、NGINXの後ろに Uvicorn（ウビコーン） というサーバーが配置されています。
なぜ NGINX だけでなく、アプリケーションサーバーが必要なのでしょうか？
■ Webサーバー と アプリケーションサーバーの役割分担
- Webサーバー（NGINX）: HTTPリクエストを受け付け、静的ファイルを返すのは得意だが、Pythonのプログラムコードを直接実行することはできない。
- アプリケーションサーバー（Uvicorn / Gunicorn）: Pythonインタープリタを内蔵し、DjangoなどのPythonプログラムを実行して動的なレスポンスを生成する。
Django開発サーバー（runserver）を本番で使ってはいけない理由
ローカル開発で使う python manage.py runserver は簡易的なテスト用サーバーです。セキュリティ対策や同時並行処理の最適化がされていないため、本番環境では必ず NGINX ＋ アプリケーションサーバー（Uvicorn等）を組み合わせて運用します。
■ WSGI と ASGI の違い
PythonのWebフレームワーク（Django, Flask, FastAPI等）とアプリケーションサーバーをつなぐ「標準規格」には、WSGI と ASGI の2種類があります。
【従来の規格】
WSGI（Web Server Gateway Interface）
└── 同期処理（1リクエストを1つのスレッドで順番に処理）
代表的なサーバー: Gunicorn, uWSGI
【現代の次世代規格】
ASGI（Asynchronous Server Gateway Interface）
└── 非同期処理（async / await に対応、WebSocketや長時間の通信も得意）
代表的なサーバー: Uvicorn, Daphne
| 比較項目 | WSGI (例: Gunicorn) | ASGI (例: Uvicorn) |
|---|---|---|
| 処理方式 | 同期処理（Synchronous） | 非同期処理（Asynchronous） |
| Python async/await | 非対応（ブロッキング） | 標準対応（ノンブロッキング） |
| WebSocket / SSE | 不可（別サーバーが必要） | 標準対応（チャットやリアルタイム通知が容易） |
| 処理速度 | 高速 | 極めて高速（C言語拡張の uvloop により最速クラス） |
■ なぜ本構成で「Uvicorn」を採用するのか？
Uvicorn は、uvloop と httptools という高速なC言語ライブラリをベースに作られた、Python最速クラスのASGIサーバーです。
-
Djangoの最新非同期機能（Async Views）を最大限に活かせる:
近年のDjangoは非同期処理への対応が進んでおり、DRFと組み合わせる際も高スループットを発揮します。 -
リアルタイム通信（WebSocket等）への将来的な拡張が容易:
後からチャット機能やリアルタイム通知機能を追加したくなった場合も、サーバー構成を変更せずに対応できます。 -
FastAPI等とも共通する現代Pythonの標準技術:
現代のPythonバックエンド開発において最も広く支持されているスタックです。
4. 完全シーケンス：リクエストから画面描画までの通信フロー
ユーザーがブラウザでURLを開いてから、Vue.jsが初期化され、API通信（ログインやデータ取得）を経て画面が描画されるまでの一連の完全な処理フローを図解します。
■ フローの3大フェーズ解説
① 静的ファイルのロード（ブラウザ ↔ Nginx）
ユーザーがアクセスした際、Nginxは即座にVue.jsのビルド成果物（HTML/JS/CSS）を返します。この段階ではまだPythonのサーバー（Django）は動いておらず、Nginx単体で高速に画面の骨組みを返却します。
② API通信とバックエンド処理（Vue ↔ Nginx ↔ Uvicorn ↔ Django ↔ DB）
Vue.jsが初期化された後、ログイン処理やデータ取得のために Axios を使ってバックエンドへ非同期APIリクエストを送信します。
- Nginx がリクエストを判定し、アプリサーバー（Uvicorn/Gunicorn）へプロキシ転送
- Django のミドルウェア（SessionやCSRF等）で認証・セキュリティを検証
- DB から必要なレコードを操作・取得し、JSONレスポンスとしてVueへ返却
③ 状態管理とリアクティブ描画（Pinia ↔ Vue Router ↔ ブラウザ）
バックエンドからJSONデータを受け取ったVue.jsは、画面をリロードすることなく動的に更新します。
- Piniaストア: 取得したユーザー情報やログイン状態（トークン等）を保持・更新
- Vue Router: 認証成功後にホーム画面やダッシュボードへクライアントサイド遷移
- DOM更新: 必要な部分のみが瞬時に再描画され、ネイティブアプリのような滑らかなUXを実現
まとめ
第一講では、DRF × Vue.js によるフルスタック開発のシステム構成・サーバー基盤・全体の通信フローを学びました。
- SPA + REST API アーキテクチャ: フロントエンドとバックエンドの責務を分離し、JSONで連携
- NGINX（Webサーバー）: イベント駆動型でC10K問題に強く、静的配信・リバースプロキシを担う
- Uvicorn（ASGIサーバー）: Pythonコードを実行する非同期対応の超高速アプリケーションサーバー
- 完全通信フロー: 静的アセット配信 → Axiosによる非同期API通信 → Django/DB処理 → Pinia/Vue Routerによる画面更新
次回予告
次回は 【第二講】開発環境のセットアップと「生成AI時代にコーディングを学ぶ意義」 に進みます。
- 開発環境の構築: Node.js / Python のインストールと推奨環境の整備
- プロジェクト初期セットアップ: Django (DRF) と Vue 3 (Vite + TypeScript) の立ち上げ
- コラム: コードをAIが自動生成できる時代に、エンジニアがアーキテクチャやコーディングを基礎から学ぶ「本当の価値」とは？
手を動かして実際に動く環境を作りながら、フルスタック開発の第一歩を踏み出していきましょう！