هذا هو الجزء الهندسي المرافق لدراسة الحالة عن نقل G.R.A.M.S Styling من WooCommerce. الانتقال قيد التنفيذ: البنية الموضحة أدناه جاهزة، ومحمّلة بالبيانات الحقيقية، وتعمل خلف Cloudflare Access حتى الإطلاق.
قبل وبعد
في WooCommerce كان خادم PHP واحد يتولى كل شيء: يعرض كل صفحة، ويشغّل قاعدة البيانات، ويستضيف عشرات الإضافات للعملات والشحن وملحقات المنتجات والتخزين المؤقت والبحث والبريد ومزامنة المنصات وغيرها. كل ميزة كانت شيفرة كتبها شخص آخر، تتشارك عملية واحدة وجدول خيارات واحدًا في قاعدة البيانات، وكل زائر كان ينتظر ذلك الخادم.
تفصل البنية الجديدة بين ثلاثة أشياء. واجهة المتجر تعمل على Cloudflare Workers قريبًا من الزائر، وتقدّم صفحات مخزنة مؤقتًا. ومحرك التجارة Medusa يعمل على خادم صغير، ولا يستقبل إلا الطلبات التي تحتاج إليه: السلال، والدفع، والحسابات، ولوحة الإدارة. وكل ما يخص هذا المتجر مكتوب على شكل وحدات Medusa، تُدار إصداراتها وتُختبر مثل أي شيفرة أخرى. يعرض المخطط أعلاه الإعدادين جنبًا إلى جنب.
محرك التجارة: Medusa v2
وفّر لنا Medusa ما يحتاجه المتجر ولا شيء غيره: المناطق والعملات، والسلال، والطلبات، وتنفيذ الشحنات، والعملاء، وواجهة إدارة، ونظام وحدات لتوسيع كل ذلك. يعمل كحزمة Docker Compose مع Postgres و Redis، يديرها Coolify على خادم بسعة 2 vCPU. يبني سير عمل GitHub Actions الصورة ويفحصها عند كل دمج، والخادم يكتفي بسحبها، لذلك يستغرق النشر نحو دقيقة ونصف. تُفرَّغ قاعدة البيانات كل ساعة وتُنسخ خارج الموقع، وقد اختُبرت الاستعادة.
يعيش سلوك المتجر الخاص في مجموعة وحدات برخصة MIT كتبناها لتكون قابلة لإعادة الاستخدام في متاجر Medusa أخرى:
- أسعار التوصيل حسب وزن السلة وجدول أسعار لكل بلد، وهي القواعد نفسها التي اعتمدها المتجر دائمًا.
- ملحقات المنتجات (أطقم التركيب، والألواح الطرفية، والإكسسوارات) كمتغيرات حقيقية لكل منها سعره.
- مدفوعات PayPal و Revolut عبر حزم SDK الرسمية، مع إشعارات webhook موثّقة واسترداد للمبالغ.
- التحقق من كلمات مرور العملاء مقابل تجزئات WordPress عند أول تسجيل دخول وترقيتها بصمت، فلا يحتاج أحد إلى إعادة تعيين أي شيء.
- رسائل المعاملات عبر صندوق البريد الذي يستخدمه المتجر أصلًا.
- Cloudflare Turnstile على كل نموذج عام، مع الرفض الافتراضي عند الفشل في بيئة الإنتاج.
- أدوات الطلبات: تحصيل الدفعة، والشحن مع رقم التتبع، وقوالب جاهزة للصناديق، وعدة طرود لكل طلب، وملاحظات الفريق.
- لوحة إنتاج للورشة في كل موقع، تصل إليها طلبات المنصات على شكل بطاقات.
- عروض أسعار مباشرة من شركات الشحن، وحجز بنقرة واحدة، وتخزين الملصقات.
- نظام إدارة محتوى صغير للصفحات ونصوص الموقع والمدونة ومعرض سيارات العملاء، مع الترجمات.
- خلاصات منتجات لـ Google Merchant Center و Meta و Pinterest.
- مساعد تسوق بالذكاء الاصطناعي يربط السيارة والقطعة بالفئة والمتغيرات الصحيحة، مع أداة اختيار بسيطة كبديل.
واجهة المتجر: Next.js 16 على Cloudflare Workers
واجهة المتجر تطبيق Next.js بنظام App Router منشور كـ Cloudflare Worker، تُخزَّن صفحاته مؤقتًا على الحافة ويُعاد التحقق منها في الخلفية، فلا يصل إلى محرك التجارة إلا جزء صغير من الزيارات. يحمل الرابط السوق (/uk و /eu و /us، ومتغيرات لغوية مثل /eu-fr)، مع رابط canonical ووسوم hreflang لكل سوق. تتولى الطبقة الوسيطة (Middleware) التحويلات من المتجر القديم، واقتراح المنطقة حسب البلد، وملف تعريف ارتباط اللغة، وترويسات الأمان.
المدونة موقع ثابت منفصل يُعاد بناؤه تلقائيًا عندما يحفظ محرر مقالًا في لوحة إدارة Medusa. ولوحة الورشة صفحة ثابتة خلف Cloudflare Access.
كيف انتقلت البيانات
كل سجل مستورد من WooCommerce يحتفظ بمعرّفه الأصلي في البيانات الوصفية، لذلك يمكن إعادة المقارنة بين المتجر القديم والجديد في أي وقت: جرى التحقق بالمعرّف من المنتجات، والمتغيرات، والأسعار، والأوزان، والعملاء، والطلبات، والمدفوعات، والمبالغ المستردة، وأرقام التتبع، ولم يُظهر آخر تشغيل أي فرق في الأسعار. أما الطلبات التي تُسجَّل في المتجر القديم قبل الإطلاق فتُستورد واحدًا تلو الآخر.
ما سنكرره
هذه هي البنية التي نقترحها الآن على أي شركة تحتاج إلى متجر بانتشار عالمي، وسرعة على الحافة، واستهداف لكل سوق، بجودة متاجر Shopify ودون نسبة تُقتطع من كل عملية بيع. كان خيار headless هو الصحيح لهذا الكتالوج. قواعد الشحن والملحقات والتشطيبات الخاصة بالمالك لم تناسب أي منصة مستضافة، وكتابتها كوحدات صغيرة أبقت كل واحدة منها قابلة للاختبار. ونقل واجهة المتجر إلى Workers ألغى فئة كاملة من أعمال الاستضافة. والاحتفاظ بالمعرّفات القديمة جعل كل تدقيق سكربتًا بدل التخمين.