العودة إلى المشاريع

دراسة مشروع مميز

قالب متجر ملابس إلكتروني

إبقاء قواعد المتجر الأساسية على السيرفر

بنيت هذا المشروع كقالب متجر ملابس Full-stack، مع تركيز العمل الخلفي على ثبات عملية الطلب، مخزون المتغيرات، حماية عمليات الإدارة، استعلامات الكتالوج على السيرفر، والاختبارات الآلية للتدفقات المهمة.

عرض المشروع

نظرة سريعة على واجهة المتجر وتجربة الاستخدام المتجاوبة

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

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

المشكلة

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

القرار 1 — جعل الـ checkout تحت تحكم السيرفر وداخل transaction

مسار إنشاء الطلب لا يقبل أسعار المنتجات أو التوصيل من المتصفح. يعيد تحميل العميل المسجل والسلة، يتحقق من منطقة التوصيل، يعيد حساب الأسعار الفعلية، يفحص المتغيرات النشطة، ويخصم المخزون داخل Prisma transaction واحدة.

كل طلب يحفظ snapshots للمنتج والسعر والمتغير والعميل والتوصيل. مفتاح idempotency لكل مستخدم يمنع نفس طلب الـ checkout من إنشاء طلب ثانٍ، بينما فشل حجز المخزون يوقف إنشاء الطلب ويترك السلة كما هي.

القرار 2 — تمثيل مخزون الملابس كمتغيرات حقيقية

المقاس واللون مخزنان في سجلات ProductVariant بدلاً من أن يكونا labels في الواجهة فقط. مفاتيح المقاس/اللون الموحدة تشكل قيد uniqueness في قاعدة البيانات، ولكل متغير مخزونه وحالته النشطة.

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

القرار 3 — إبقاء حدود الاستعلام والصلاحيات على السيرفر

Products API يتحقق من شكل وحدود الاستعلام ثم ينفذ البحث والتصفية والترتيب والـ pagination المحدود عبر Prisma. الاستجابة تستنتج التوفر من مخزون المتغيرات النشطة بدلاً من إرسال كتالوج غير محدود لتصفيته في المتصفح.

المصادقة تستخدم Better Auth مع جلسات محفوظة عبر Prisma. تعديلات Admin API تتطلب دور ADMIN وتستخدم فحوصات same-origin ويمكنها تطبيق rate limits عبر Redis عند إعداد Upstash؛ والـ limiter مصمم ليمرر الطلب عند تعذر Redis بدلاً من تعطيل المتجر.

القرار 4 — اختبار قواعد العمل وليس الواجهة فقط

اختبارات Vitest/API تغطي تحقق الطلب، فشل حجز المخزون، رفض سعر توصيل مرسل من العميل، سلوك rate limiting، تحقق المتغيرات، وانتقالات حالة الطلب. كما يختبر Playwright تدفق طلب حقيقي ويتحقق من snapshot السعر وتغير المخزون.

GitHub Actions يشغل type checking وlinting والاختبارات وبناء production وفحص تراخيص المستودع عند pull requests وpush إلى main. مجموعة Playwright موجودة بشكل منفصل ولا أعتبرها هنا جزءاً من مهمة CI هذه.

التنازلات والنتيجة

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