لقد كنت متشوقًا للتعمق في لغة HTMX، خاصة بعد مشاهدة حديث DjangoCon Europe 2022 من React إلى HTMX في مشروع SaaS في العالم الحقيقي. لقد كنت أستخدم HTMX وAlpine في عملي اليومي مؤخرًا، وقد جعلا معًا تطوير تطبيقات الويب التفاعلية أكثر متعة، خاصة كشخص لا يحب تطوير الواجهة الأمامية بشكل خاص.

لم أكن من أشد المعجبين بقوالب Django، لكن HTMX وAlpine.js وDjango Cotton بدأت في تغيير وجهة نظري. ومع وجود Tailwind CSS في الأعلى، فقد أصبحت واحدة من أفضل المجموعات التي عملت معها حتى الآن.

هذا المشروع عبارة عن تطبيق لإدارة التمويل الشخصي يدمج Plaid لربط الحسابات المصرفية وتقديم رؤى مالية. لقد استخدمت أمثلة Plaid الرسمية من مستودعهم كمرجع.

هل تريد نظرة عامة سريعة على الكود؟ التحقق من ذلك على جيثب

سمات

• التكامل المنقوش لربط الحسابات المصرفية، وجلب بيانات الحساب في الوقت الفعلي، وتتبع المعاملات.
• خطافات الويب التلقائية إلى:
  • مزامنة البيانات المصرفية وتحديثها تلقائيًا عند توفر معاملات جديدة.
  • يمكنك تحديث الحسابات وإعادة مصادقتها بسهولة عندما تدخل في حالة سيئة (على سبيل المثال، يلزم تسجيل الدخول).
  • اكتشاف الحسابات المصرفية الجديدة تلقائيًا ومطالبة المستخدمين بإضافة الحسابات المكتشفة حديثًا.
• يوفر رؤى مالية مثل صافي القيمة، والتفاصيل الخاصة بالحساب، وتفاصيل الإنفاق على أساس الفئة.
• المصادقة الثنائية (2FA) مع تطبيق المصادقة للحصول على طبقة إضافية من الأمان.

إدارة التبعية بالشعر

لإدارة التبعيات في هذا المشروع، استخدمت الشعر. يعمل الشعر على تبسيط عملية إدارة الحزم وأتمتة الكثير من المهام الثقيلة المتعلقة بالتبعيات. وهو يعتمد على ملف pyproject.toml، والذي أصبح الآن المعيار لتحديد متطلبات البناء في مشاريع بايثون الحديثة.

لماذا الشعر؟

• حل التبعية بشكل أسهل.
• إنه ينشئ ويدير بيئات افتراضية، لذلك إذا نسيت إنشاء/تنشيط واحدة، فإن Poetry يساندك.
• يقوم بتأمين الإصدارات الدقيقة من الحزم، والتأكد من أن البيئة قابلة للتكرار. وهذا مفيد جدًا خاصة عند العمل ضمن فريق أكبر.

راف والالتزام المسبق

لقد كنت أستخدم Ruff، وهو منسق سريع جدًا لـ Python ومنسق الأكواد، مدمج في Rust. فهو يتعامل مع مجموعة من الأدوات في أداة واحدة، مثل Black وisort والمزيد.

ما يعجبني في روف:

• يمكنك تهيئته باستخدام pyproject.toml، الذي يبقي الأمور نظيفة ومركزية.
• إنه الكل في واحد، لذلك لا داعي لإدارة أدوات منفصلة مثل Black، وisort، وما إلى ذلك.

لقد استخدمت أيضًا djlint لفحص قوالب Django. إنه أمر جيد، لكنني ما زلت أبحث عن شيء أفضل. إذا كنت تعرف أي بدائل جيدة، فلا تتردد في مشاركتها!

لمزيد من المعلومات حول إعداد خطافات الالتزام المسبق لتنسيق التعليمات البرمجية وفحصها في Django، راجع مقالتي هنا.

هيكل المشروع

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()

لقد قمت أيضًا بإنشاء أمر startapp مخصص لإنشاء تطبيقات Django بملفات محددة مسبقًا ومحتوى مناسب لحالة الاستخدام الخاصة بي.

الاختبارات

لكتابة الاختبارات، أستخدم pytest جنبًا إلى جنب مع Factory_boy، مما يجعل من السهل الإعلان عن الحقول الخاصة بالاختبار وإنشاء بيانات الاختبار.

في البداية، كنت أضع مجلد اختبارات داخل كل تطبيق من تطبيقات Django. ومع ذلك، فقد تحولت منذ ذلك الحين إلى وجود مجلد اختبارات واحد في جذر المشروع، مع مجلدات فرعية لكل تطبيق. لقد جعل هذا الأسلوب التنقل أكثر سلاسة ويحافظ على تنظيم كل شيء. بالإضافة إلى ذلك، فهو يجعل مشاركة التركيبات المشتركة أسهل بكثير حيث يمكن تعريفها على مستوى أعلى وإعادة استخدامها عبر وحدات اختبار متعددة.

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()

الواجهة

يجمع هذا المشروع بين أدوات الواجهة الأمامية التالية:

يسمح لك HTML بإضافة تفاعلات ديناميكية إلى مشروعك دون الحاجة إلى أطر عمل JavaScript ثقيلة. يمكنك تنظيم قوالب Django الخاصة بك باستخدام مقتطفات HTML صغيرة قابلة لإعادة الاستخدام. يتيح لك ذلك تحديث أجزاء معينة من الصفحة بناءً على إجراءات المستخدم، دون الحاجة إلى إعادة تحميل الصفحة بالكامل. يعمل هذا النمط بشكل رائع مع عروض Django لأنه يمكن التعامل مع كل جزء من المحتوى كعرض خاص به ثم إدراجه في DOM ديناميكيًا.

Alpine.js هو إطار عمل جافا سكريبت خفيف الوزن يستخدم لإضافة التفاعل. إنه يعمل بشكل جيد مع بنية قالب Django ويوفر سلوكًا تعريفيًا سريعًا لأشياء مثل الوسائط أو القوائم المنسدلة أو أدوات التبديل. بالاشتراك مع HTMX، يمكن أن يوفر لك Alpine ما يكفي من JavaScript لتحسين تجربة المستخدم دون الاضطرار إلى التعامل مع شيء مثل React أو Vue. على سبيل المثال، يمكنك استخدام Alpine لإدارة الحالة في الواجهة الأمامية، مثل فتح وإغلاق الوسائط أو التعامل مع التحقق من جانب العميل.

يتعامل Tailwind CSS مع التصميم في هذا المشروع، مما يؤدي إلى تسريع عملية تطوير واجهات المستخدم النظيفة والمستجيبة. يستخدم هذا المشروع أيضًا Flowbite لمكونات واجهة المستخدم المعدة مسبقًا مثل الوسائط وتلميحات الأدوات والأزرار. يتكامل Flowbite جيدًا مع Tailwind ويساعدك على تجنب إعادة اختراع العجلة لعناصر واجهة المستخدم الشائعة.

يسمح لك Django Cotton بإنشاء قوالب Django قابلة لإعادة الاستخدام. لقد اكتشفت هذه المكتبة الرائعة في منتصف المشروع أثناء محاولتي جعلها قابلة لإعادة الاستخدام. في البداية، حاولت استخدام علامة قالب التضمين الخاصة بـ Django، ولكن عند تمرير الكثير من بيانات السياق، سرعان ما أصبحت مزدحمة. يتيح لك Django-Cotton إنشاء مكونات قابلة لإعادة الاستخدام بشكل كبير وترتبط جيدًا بـ HTMX وTailwind في بناء جملة يشبه علامة HTML. على سبيل المثال:

المصادقة الثنائية مع AllAuth

لتنفيذ المصادقة في هذا المشروع، استخدمت مكتبة AllAuth، والتي توفر أيضًا دعمًا للمصادقة متعددة العوامل (MFA). فهو يقدم وحدة MFA التي تتكامل بسلاسة مع إعداد مصادقة المستخدم الحالي لديك. يمكنك تمكين المصادقة الثنائية عبر تطبيق المصادقة، مما يضيف طبقة إضافية من الأمان. يمكنك أيضًا تخصيص القوالب التي يوفرها AllAuth بسهولة لتتناسب مع شكل ومظهر تطبيقك.

خاتمة

بشكل عام، هذا المشروع تعليمي في المقام الأول ويحتوي على ميزات كافية لبدء دمج Django، وHTMX، وAlpine.js، وTailwind، وPlaid.

ومع ذلك، احذر من أنه قد يكون هناك بعض الأخطاء هنا وهناك، وهناك دائمًا مجال للتحسين وإعادة استخدام المكونات بشكل أكبر. ولكن بشكل عام، يعد هذا أساسًا متينًا لأي شخص يتطلع إلى استكشاف هذه التقنيات.

التحقق من المشروع على جيثب

إذا كنت تريد مني استكشاف المواضيع المذكورة هنا بمزيد من التفاصيل، فأخبرني بذلك في التعليقات.

ترميز سعيد! ?