Django で「2010 年代風」バックエンドサイト構築への挑戦：良い点と課題

現在、2010 年代風のスタイル（SQL データベースを利用し、バックエンドで HTML をレンダリングするアプローチ）のウェブサイト作成を学習中です。 過去にそのような環境構築の経験がなく、学ぶべきことが山積みでしたが、Go や Flask で試行錯誤して挫折した際と比較すると、Django は難易度を低下させる強力な機能を持っています。一方で、いくつかの問題点も存在します。

なぜ「2010 年代風」のウェブサイトを学ぶのか？

以前は以下のフロントエンド中心のアプローチに自信がありました：

• スティックサイトジェネレーター（例：このブログ）
• JavaScript でインタラクティブな要素を追加したサイト（例：SQL プレイグラウンド）
• AWS Lambda/Go バックエンドの簡素な Vue.js SSG（例：mess with dns）

**「単一のページ」だけでなく「多数のページ」**を作る際に、大量のフロントエンドコードが必要になることに嫌気が差し、バックエンド中心の構築に挑戦しました。本質的にはどちらも「ロジックを一つの場所に集約しようとする」点で同じです。

Django の素晴らしい機能 4 選

1. クエリビルダーの利用が楽しい

QuerySet

WHERE

Events.objects.approved() \
    .for_tab(tab) \
    .with_festivals(tab_params.festival_slugs) \
    .is_free(tab_params.free) \
    .is_outdoors(tab_params.outdoors)

具体的な実装例（クラス定義）：

class EventQuerySet(SearchableQuerySetMixin, models.QuerySet):
    def approved(self):
        return self.filter(approved_at__isnull=False)

    def future(self):
        today = timezone.localdate()
        return self.filter(end__gt=self._midnight(today))

    def with_tags(self, tags):
        if tags:
            return self.filter(tags__name__in=tags).distinct()
        return self

構文は完璧ではありませんが、実際に使う際の可読性と使いやすさに非常に満足しています。将来はよりミニマルなクエリビルダーを検討したいです。

2. テンプレートフィルタが素晴らしい

HTML 生成に役立つ小さなフィルタが用意されています。特に以下は重宝しています：

• URL/改行の処理: プレーンテキストをリンクや

  <br>

  タグに変換（例：

  {{ event.description|urlize|linebreaksbr }}

  ）
• 日付フォーマット: 柔軟な形式での表示（例：

  {{ row.date|date:"M j" }}

  ）
• JSON 挿入: Python オブジェクトを安全に JSON/Script タグへ変換（

  json_script

  フィルタ）

これらは単発機能ですが、組み合わせることで大きな違いを生んでいます。

3. クエリストリング処理が面白い

表示内容を変えつつも同じクエリ文字列を持つリンクを作成できる

querystring

• パラメータ値の変更: 日付を前日に変更する場合

  <a href="{% querystring date=nav.prev_date %}">昨日へ</a>
  

• パラメータの削除: 「屋外」パラメータを解除する場合

  <a href="{% querystring outdoors=None %}">屋内のみを表示</a>
  

4. 自動データベースマイグレーションが優秀

モデル（Python コード）を変更すると、Django が自動的にマイグレーションファイルを生成してくれます。これによりデータベースの構造変更が非常に容易で、学習コストを大幅に下げてくれました（現在までに 19 ファイル作成済み）。

気になる点と課題

コード整理には継承は不要

ドキュメントではビューを整理するために「クラスベースビュー + 継承」を推奨していますが、実際の開発では関数ベースのアプローチの方が直感的で好みました。Python で継承を使う機会はないため、あえて使用しません。ただし、Django のインターフェース拡張（上記の QuerySet クラス定義など）には問題なく使えます。

パフォーマンスの不明瞭さ

Go 開発者にとってはパフォーマンスが「自明」でしたが、Django は異なります。LLM スクレイパーによる高負荷（1 秒あたり 10 リクエスト）に直面した際、月額約

$10

まだ解決すべき疑問点：

• 間欠的なトラフィック増大への対策が必要か？
• キャッシュ設定は必須だが、設定自体が非常に面倒。
• ドキュメントで Jinja テンプレートの方が高速とあるが、変更すべきか？

• {% block %}

  と

  {% include %}

  の性能差は実用上有意か？

テンプレートキャッシングの重要性

誤ってデフォルト有効だった「キャッシュ化されたテンプレートローダー」を無効にしてしまい、その影響を痛感しました。有効化すると以下の改善が確認できました：

• コンパイルコストの回避: テンプレートごとに毎回コンパイルする必要が消える。
• 性能向上: CPU を最大限使用せずに、処理能力が大幅に向上（約 1 秒あたり 12 リクエストへ）。

これはCPU プロファイリングから気づいた重要な問題です。通常は「DB クエリの最適化」が先とされますが、今回のように SQLite を使用している場合やテンプレート処理がボトルネックになる場合は、キャッシュ設定の確認が最優先課題です。

Django の設定ファイルへの慣れが必要ですが、ここを理解すればパフォーマンスは劇的に変わります。