私は、特に DjangoCon Europe 2022 の講演 現実世界の SaaS プロジェクトでの React から HTMX へ を見てから、HTMX に興味を持ち始めました。私は最近、日々の仕事で HTMX と Alpine を使用していますが、これらを併用すると、特にフロントエンド開発があまり好きではない人にとって、インタラクティブな Web アプリの開発がずっと楽しくなりました。

私は Django テンプレートの大ファンではありませんでしたが、HTMX、Alpine.js、および Django Cotton によって私の見方が変わり始めました。そして、Tailwind CSS を最上位に据えることで、これまで私が取り組んだ中で最高のスタックの 1 つになりました。

このプロジェクトは、Plaid を統合して銀行口座をリンクし、財務上の洞察を提供する個人財務管理アプリです。 Plaid のリポジトリにある公式の例を参照として使用しました。

コードの概要を簡単に知りたいですか? GitHub で確認してください

特徴

• Plaid の統合により、銀行口座をリンクし、リアルタイムの口座データを取得し、取引を追跡します。
• 自動化された Webhook の目的:
  • 新しい取引が可能になるたびに銀行データを自動的に同期および更新します。
  • アカウントが不正な状態になった場合（ログインが必要な場合など）、アカウントを簡単に更新して再認証します。
  • 新しい銀行口座を自動的に検出し、新しく検出された口座を追加するようユーザーに促します。
• 純資産、アカウント固有の詳細、カテゴリベースの支出の内訳などの財務上の洞察を提供します。
• 認証アプリを使用した 2 要素認証 (2FA) によりセキュリティ層が強化されます。

詩による依存関係管理

このプロジェクトの依存関係を管理するために、Poetry を使用しました。 Poetry はパッケージ管理プロセスを簡素化し、依存関係に伴う重労働の多くを自動化します。これは、現代の Python プロジェクトでビルド要件を定義するための標準となっている pyproject.toml ファイルに依存しています。

なぜ詩なのか?

• 依存関係の解決が簡単になりました。
• 仮想環境を作成および管理するため、仮想環境の作成やアクティブ化を忘れた場合でも、Poetry がサポートします。
• パッケージの正確なバージョンをロックダウンし、環境が再現可能であることを確認します。これは、特に大規模なチームで作業する場合に非常に役立ちます。

ラフとプリコミット

私は Ruff を使用しています。これは、Rust に組み込まれた非常に高速な Python リンターおよびコード フォーマッタです。 Black、isort などの多数のツールを 1 つで処理します。

ラフの好きなところ:

• pyproject.toml を使用して設定できます。これにより、物事をクリーンかつ一元的に保つことができます。
• オールインワンなので、Black、isort などの個別のツールを管理する必要はありません。

Django テンプレートのリンティングに djlint も使用しました。それはまともですが、私はまだもっと良いものを探しています。何か良い代替案をご存知の場合は、お気軽に共有してください!

Django でのコードのフォーマットと lint のための Pre-commit フックの設定の詳細については、こちらの記事をご覧ください。

プロジェクトの構造

django_finance/
├── apps/
│   ├── accounts/
│   ├── common/
│   └── plaid/
├── config/
│   ├── app_template/
│   ├── settings/
│   ├── asgi.py
│   ├── celery.py
│   ├── urls.py
│   └── wsgi.py
├── static/
│   ├── css/
│   ├── images/
│   └── js/
├── templates/
│   ├── account/
│   ├── components/
│   ├── errors/
│   ├── layouts/
│   ├── mfa/
│   ├── plaid/
│   ├── _base_dashboard.html
│   ├── _base.html
│   └── index.html
├── tests/
│   ├── accounts/
│   ├── common/
│   ├── plaid/
│   └── conftest.py
├── theme/
├── .pre-commit-config.yaml
├── db.sqlite3
├── manage.py
├── poetry.lock
├── pyproject.toml
└── README.md

共通アプリでは、管理コマンド、検証、ベースモデル、テンプレートタグなどを追加します。BaseModel は次のようになります:

class BaseModel(models.Model):
    """
    Base model for common fields and methods.
    """

    id = models.AutoField(primary_key=True)
    uuid = models.UUIDField(default=uuid.uuid4, unique=True, editable=False)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)
    is_active = models.BooleanField(default=True, db_index=True, help_text="Used for soft deleting records.")

    objects = BaseModelManager()

    class Meta:
        abstract = True

    def soft_delete(self):
        self.is_active = False
        self.save()

    def restore(self):
        self.is_active = True
        self.save()

ユースケースに適した事前定義されたファイルとコンテンツを含む Django アプリを生成するためのカスタム startapp コマンドも作成しました。

テスト

テストを作成する場合、factory_boy と一緒に pytest を使用します。これにより、テスト固有のフィールドの宣言とテスト データの作成が簡単になります。

当初、私は各 Django アプリ内に test フォルダーを配置していました。ただし、それ以来、プロジェクトのルートに 1 つのテスト フォルダーを置き、アプリごとにサブフォルダーを置くように変更しました。このアプローチにより、ナビゲーションがはるかにスムーズになり、すべてが整理された状態になります。さらに、共通のフィクスチャをより高いレベルで定義し、複数のテスト モジュール間で再利用できるため、共有がはるかに簡単になります。

tests/
├── accounts/
│   ├── __init__.py
│   ├── factories.py
│   ├── test_managers.py
│   ├── test_models.py
├── common/
│   ├── __init__.py
│   ├── test_validators.py
├── plaid/
│   ├── conftest.py
│   ├── dummy_data.py
│   ├── factories.py
│   ├── test_models.py
│   ├── test_services.py
│   ├── test_tasks.py
│   ├── test_views.py
│   ├── test_webhooks.py
├── __init__.py/
└── conftest.py

サンプルテスト:

class TestCreatePlaidLinkToken:
    LINK_TOKEN = "link_token"

    class MockLinkTokenResponse:
        def to_dict(self):
            return {
                "link_token": TestCreatePlaidLinkToken.LINK_TOKEN,
                "expiration": "2020-03-27T12:56:34Z",
                "request_id": "request_id",
            }

    @pytest.fixture
    def setup_mocks(self, mocker):
        return {
            "mock_link_token": mocker.patch(
                "django_finance.apps.plaid.views.plaid_config.client.link_token_create",
                return_value=self.MockLinkTokenResponse(),
            ),
            "mock_logger": mocker.patch("django_finance.apps.plaid.views.logger"),
        }

    @pytest.fixture
    def create_link_token(self, client):
        def _create_link_token(data=None):
            return client.post(
                reverse("create_link_token"),
                json.dumps(data) if data else None,
                content_type="application/json",
            )

        return _create_link_token

    def test_create_plaid_link_token_success(self, login, setup_mocks, create_link_token):
        login()
        response = create_link_token()
        assert response.status_code == 201
        data = json.loads(response.content)
        assert "link_token" in data
        assert data["link_token"] == self.LINK_TOKEN
        setup_mocks["mock_link_token"].assert_called_once()

フロントエンド

このプロジェクトは、次のフロントエンド ツールを組み合わせます:

HTMX を使用すると、重い JavaScript フレームワークを必要とせずに、動的なインタラクションをプロジェクトに追加できます。小さくて再利用可能な HTMX スニペットを使用して Django テンプレートを整理できます。これにより、ページ全体をリロードすることなく、ユーザーのアクションに基づいてページの特定の部分を更新できます。このパターンは、各コンテンツを独自のビューとして扱い、DOM に動的に挿入できるため、Django のビューでうまく機能します。

Alpine.js は、インタラクティブ性を追加するために使用されるもう 1 つの軽量 JavaScript フレームワークです。 Django のテンプレート構造とうまく連携し、モーダル、ドロップダウン、トグルなどに迅速な宣言的な動作を提供します。 Alpine を HTMX と組み合わせると、React や Vue などを扱うことなく、UX を強化するのに十分な JavaScript を提供できます。たとえば、Alpine を使用すると、モーダルの開閉やクライアント側の検証の処理など、フロントエンドで状態を管理できます。

Tailwind CSS はこのプロジェクトのスタイルを処理し、クリーンで応答性の高い UI の開発をスピードアップします。このプロジェクトでは、モーダル、ツールチップ、ボタンなどの事前に構築された UI コンポーネントにも Flowbite を使用しています。 Flowbite は Tailwind とうまく統合しており、一般的な UI 要素の車輪の再発明を避けるのに役立ちます。

Django Cotton を使用すると、再利用可能な Django テンプレートを作成できます。私はプロジェクトの途中でモーダルを再利用可能にしようとしていたときに、この素​​晴らしいライブラリを発見しました。最初は Django の include template タグを使用しようとしましたが、大量のコンテキスト データを渡すとすぐに乱雑になってしまいました。 Django-Cotton を使用すると、HTML タグのような構文で HTMX および Tailwind と適切にバインドする、再利用性の高いコンポーネントを作成できます。例えば：

AllAuth による 2 要素認証

このプロジェクトで認証を実装するために、多要素認証 (MFA) のサポートも提供する AllAuth ライブラリを使用しました。既存のユーザー認証設定とシームレスに統合する MFA モジュールを提供します。認証アプリを介して 2FA を有効にして、セキュリティ層を追加できます。 AllAuth が提供するテンプレートをアプリの外観と雰囲気に合わせて簡単にカスタマイズすることもできます。

結論

全体的に、このプロジェクトは主に教育目的であり、Django、HTMX、Alpine.js、Tailwind、および Plaid の統合を開始するのに十分な機能が備わっています。

とはいえ、あちこちにいくつかのバグがある可能性があり、コンポーネントには改善と再利用の余地が常にあることに注意してください。しかし全体として、これはこれらのテクノロジーを探求しようとしている人にとって強固な基盤となります。

GitHub でプロジェクトをチェックアウトします

ここで言及されているトピックについてさらに詳しく知りたい場合は、コメント欄でお知らせください。

コーディングを楽しんでください! ?