AURA&CO: تطوير واجهة متجر أزياء متعددة المناطق على Medusa

المنصة

Medusa 2.18

واجهة المتجر

Next.js 15 · React 19

طبقة البيانات

PostgreSQL · Redis · Meilisearch

المناطق

الهند (₹) والولايات المتحدة ($)

الموقع المباشر

واجهة متجر AURA&CO

توفّر Medusa العناصر الأساسية للتجارة الإلكترونية — مثل المنتجات، المتغيرات، السلال، الطلبات، المخزون، المدفوعات، المناطق — على شكل وحدات خلف واجهة API، وتتوقف عند هذا الحد عن قصد. ما لا توفره هو كل ما يعتبره بائع الأزياء جزءًا من المتجر: قائمة رئيسية من ثلاثة مستويات، خصائص الملابس القابلة للتصفية، أدلة المقاسات، أقسام تحريرية في الصفحة الرئيسية، البحث في رصيد المتجر، التقييمات. مشروع AURA&CO هو نموذجنا المرجعي لسد هذه الفجوة تحديدًا — كتالوج من خمسة أقسام للأزياء، الأدوات المنزلية، وملابس الأطفال يعمل في منطقتين، حيث كل سلوك خاص بالتجزئة هو وحدة قمنا بتطويرها، وليس إضافة اعتمدنا على استمرار عملها.

لماذا Medusa لمتاجر تعتمد على الكتالوج بشكل كبير

ميزة Medusa هي تحقيق الملكية دون البدء من الصفر. منصات SaaS تمنحك عملية دفع لا يمكنك تعديلها ونموذج بيانات يجب أن تعدل كتالوجك ليتناسب معه. الأطر البرمجية تعطيك كل شيء للبناء من البداية. Medusa تقع في المنتصف: النواة التجارية جاهزة، مجربة وصيانتها ليست مسؤوليتك، بينما كل ما هو خاص بنطاق عملك هو وحدة تقوم بتعريفها — مع جداولها، وترحيلاتها وخدمتها — ويتعامل معها النظام كبنية أساسية.

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

الخلفية: سبع وحدات تنجز العمل التجاري

الكتالوج: الخصائص، المعايير وأدلة المقاسات

منتجات الأزياء تحمل خصائص لا يحددها Medusa — مثل القَصّة، شكل الياقة، طول الكم، طول القطعة، الخامة، النقشة، المناسبة، الاستدامة. قمنا بنمذجتها كنظام خصائص أقرب إلى EAV في Magento: تعريف برمز آلي code، ونوع إدخال ومجموعة قيم، مرتبطة بالمنتجات ومقيدة حسب التصنيف.

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

• معايير تصفية حسب التصنيف — الفلاتر المعروضة على فئة الفساتين تختلف عن تلك المعروضة على فئة المفروشات، لأن الخصائص مرتبطة بالتصنيفات وليست عامة على جميع المنتجات
• أدلة المقاسات — جداول القياسات محفوظة كسجلات، مرتبطة بكل تصنيف، وتظهر من صفحة المنتج
• تجاوزات لكل منتج — قيم خصائص نصية حرة للحالات التي لا يمكن التعبير عنها بقائمة قيم ثابتة

المحتوى والتنقّل: الأجزاء التي يديرها مسؤولو التسويق

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

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

تحتوي وحدة التنقّل على قائمة ميجا مكوّنة من ثلاث مستويات: قسم رئيسي، عنوان عمود، ورابط. يمكن للروابط أن تشير إلى فئة أو إلى عنوان URL مباشر، ويمكن تمييز أي عنصر ليظهر باللون المميز، ولوحة الصورة الترويجية على يمين كل قائمة جزء من نفس البيانات — صورة، عنوان رئيسي، ودعوة لاتخاذ إجراء.

قائمة الرغبات، التقييمات، ورصيد المتجر الفعلي

كل وحدة من الوحدات المتبقية تحل مشكلة تبدو بسيطة حتى تبدأ في تنفيذها.

• قائمة الرغبات — تعمل للزوار باستخدام رمز مجهول، ثم تندمج مع قائمة العميل عند تسجيل الدخول. بدون هذا الدمج، كل ما تم حفظه قبل التسجيل يضيع بصمت في اللحظة التي يقرر فيها المتسوّق المتابعة.
• التقييمات — تُربط بالمنتج وليس بالمتغير، حتى لا تتوزع خمسة تقييمات على خمسة مقاسات. التقييمات الجديدة تُسجّل كـ قيد الانتظار وتظهر في واجهة المتجر فقط بعد موافقة المشرف؛ شارة المشتري الموثوق يتم التحقق منها مقابل سجل الطلبات عند الإرسال وتخزينها، فلا يمكن لتعديل لاحق أو استرداد أن يغيّرها.
• محدد مواقع المتاجر — كل متجر مرتبط بموقع مخزون في Medusa، لذا وظيفة "البحث في المتجر" تقرأ نفس مستويات المخزون التي يعتمد عليها الدفع، بدلاً من جدول مخزون منفصل قد يتغير بشكل مستقل.

توضح فهارس قاعدة البيانات نفس منطق الكود: التقييمات مفهرسة في المسار السريع للواجهة (التقييمات المعتمدة لمنتج واحد)، وفي قائمة الانتظار للمراجعة، ومع فهرس فريد جزئي يسمح بتقييم واحد لكل عميل لكل منتج مع إبقاء الزوار غير مقيدين — لأن الزوار ليس لديهم هوية يمكن تقييدها.

واجهة المتجر: البنية والتوجيه

واجهة المتجر مبنية باستخدام Next.js 15 على App Router، وتُعرض الصفحات افتراضياً من الخادم. كل مسار يأتي تحت جزء خاص بالدولة، بحيث يتم تحديد المنطقة والعملة وطرق الدفع المتاحة من عنوان URL وليس من ملف تعريف ارتباط لن يتم تعيينه بواسطة محرك البحث — /in/ تعرض الأسعار بالروبية، /us/ بالدولار، وكلاهما قابل للفهرسة بالكامل.

عناوين الفئات مسطحة عمداً: /ladies-dresses.html، وليست /categories/ladies-dresses. مسار شامل يعالجها بعد المسارات المسماة، بحيث تظل /cart و/account لها الأولوية. المنتجات توجد فقط في الفئات الفرعية، لذا عند عرض قسم رئيسي يتم تجميع كل الفئات الفرعية — يتم بناء الشجرة من قائمة الفئات المسطحة، لأن واجهة البرمجة لا توفر سوى العلاقات المباشرة بين الفئات.

• الصفحة الرئيسية — أقسام مركبة من الإدارة، مرتبة ومجدولة
• قوائم الأقسام والفئات — 36 منتجاً في الصفحة، مع تصفية حسب السمات، ومربعات للفئات الفرعية ونصوص SEO
• صفحات المنتجات — اختيار المتغير والمقاس، دليل المقاسات، أقسام السمات، التقييمات والمراجعات، البحث في المتجر، "اشترى أيضاً"، المنتجات التي تم عرضها مؤخراً
• البحث — صفحة نتائج كاملة بالإضافة إلى الإكمال التلقائي في رأس الصفحة
• المفضلات، المتاجر وصفحات CMS — محدد مواقع المتاجر، قائمة الرغبات والمحتوى التحريري
• عربة التسوق، الدفع بثلاث خطوات والحسابات — العناوين، سجل الطلبات، تفاصيل الطلب ونقل الطلبات بين الحسابات

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

البحث، التصفية وإدارة المنتجات

العرض والبحث يتمان عبر نفس الاستعلام إلى فهرس Meilisearch. تُعرض البطاقات مباشرة من المستندات المسترجعة، لذا صفحة من 36 منتجاً تتطلب طلباً واحداً فقط بدلاً من بحث متبوع بجلب لكل بطاقة، وتصل أعداد السمات مع النتائج دون الحاجة إلى تجميع إضافي. الأسعار بالعملتين، المخزون حسب المقاس، تجميع الألوان، العلامات والتقييمات كلها ضمن المستند؛ الترتيب حسب التقييم يعمل لأن المنتجات غير المقيمة تُسجّل بقيمة صفر وتظهر تلقائياً في الأسفل دون الحاجة لتصفية إضافية.

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

الأداء: ما تقدمه البنية

الصفحات المعروضة من الخادم، طلب بحث واحد لكل قائمة، تحسين الصور عند حافة الإطار، وعدم وجود تسلسل بيانات من جهة العميل — كل ذلك يؤدي إلى نتائج قابلة للقياس. تم القياس على الصفحة الرئيسية باستخدام Google PageSpeed Insights:

تحقيق قيمة صفرية في Cumulative Layout Shift على صفحة رئيسية تعتمد على الصور ليس صدفة — يتم حجز أبعاد كل وسائط قبل تحميل الصورة. Total Blocking Time بقيمة 40ms على جهاز Android متوسط الأداء هو نتيجة العرض من الخادم: لا يتبقى سوى القليل من JavaScript للتنفيذ، لأن الصفحة لم تصل كقالب فارغ ينتظر التهيئة. هذا النهج هو نفسه الذي نعتمده في أعمال تحسين سرعة الصفحات على جميع المنصات.

ما الذي يحصل عليه فريق الإدارة فعلياً

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

صفحات المنتجات والفئات تكتسب عناصر تفاعلية في مكانها — قيم السمات على صفحة المنتج، وتكوين المحتوى والخصائص على صفحة الفئة — بحيث يتم العمل حيث يوجد مسؤول الترويج فعلياً. هذا هو الاختبار العملي للبناء القابل للتكوين: فريق المشتريات يغيّر المتجر دون الحاجة لفتح تذكرة دعم، وفريق الهندسة لا يكون عنق الزجاجة عند تحديث لافتة.

المقايضات التي تستحق الذكر

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

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

هل تفكر في Medusa لإدارة الكتالوج الخاص بك؟

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