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







متجر الملابس يحتاج أكثر من صفحات منتجات. عملية الطلب يجب أن تعتمد على بيانات السيرفر الحالية، والمخزون يرتبط باختيارات مقاس/لون محددة، والطلبات القديمة تحتاج بيانات شراء ثابتة، وإجراءات الأدمن يجب أن تتبع قواعد لا يمكن تجاوزها من المتصفح.
مسار إنشاء الطلب لا يقبل أسعار المنتجات أو التوصيل من المتصفح. يعيد تحميل العميل المسجل والسلة، يتحقق من منطقة التوصيل، يعيد حساب الأسعار الفعلية، يفحص المتغيرات النشطة، ويخصم المخزون داخل Prisma transaction واحدة.
كل طلب يحفظ snapshots للمنتج والسعر والمتغير والعميل والتوصيل. مفتاح idempotency لكل مستخدم يمنع نفس طلب الـ checkout من إنشاء طلب ثانٍ، بينما فشل حجز المخزون يوقف إنشاء الطلب ويترك السلة كما هي.
المقاس واللون مخزنان في سجلات ProductVariant بدلاً من أن يكونا labels في الواجهة فقط. مفاتيح المقاس/اللون الموحدة تشكل قيد uniqueness في قاعدة البيانات، ولكل متغير مخزونه وحالته النشطة.
الـ checkout يتطلب متغيراً نشطاً ومختاراً، ويخصم منه فقط إذا كان المخزون كافياً. إلغاء طلب سبق حجز مخزونه يعيد الكمية، وتغييرات حالة الطلب من الأدمن مقيدة بانتقالات مسموحة بشكل صريح.
Products API يتحقق من شكل وحدود الاستعلام ثم ينفذ البحث والتصفية والترتيب والـ pagination المحدود عبر Prisma. الاستجابة تستنتج التوفر من مخزون المتغيرات النشطة بدلاً من إرسال كتالوج غير محدود لتصفيته في المتصفح.
المصادقة تستخدم Better Auth مع جلسات محفوظة عبر Prisma. تعديلات Admin API تتطلب دور ADMIN وتستخدم فحوصات same-origin ويمكنها تطبيق rate limits عبر Redis عند إعداد Upstash؛ والـ limiter مصمم ليمرر الطلب عند تعذر Redis بدلاً من تعطيل المتجر.
اختبارات Vitest/API تغطي تحقق الطلب، فشل حجز المخزون، رفض سعر توصيل مرسل من العميل، سلوك rate limiting، تحقق المتغيرات، وانتقالات حالة الطلب. كما يختبر Playwright تدفق طلب حقيقي ويتحقق من snapshot السعر وتغير المخزون.
GitHub Actions يشغل type checking وlinting والاختبارات وبناء production وفحص تراخيص المستودع عند pull requests وpush إلى main. مجموعة Playwright موجودة بشكل منفصل ولا أعتبرها هنا جزءاً من مهمة CI هذه.
النتيجة مشروع Full-stack بتركيز خلفي وقواعد متجر واضحة بدلاً من ادعاء أنه متجر إنتاجي. الدفع الإلكتروني خارج النطاق بشكل مقصود—والنموذج يدعم الدفع عند الاستلام فقط—والنسخة المستضافة بيئة عرض للملف الشخصي وليست دليلاً على جاهزية إنتاجية أو حجم استخدام فعلي.