Shopify أم Laravel: أين ينكسر نموذج الطلب

معظم صفحات المقارنة في هذا الموضوع تكتبها شركات تبني متاجر مخصصة. فلنقلها بوضوح: لأغلب الأعمال التي تبحث عن هذا، Shopify هو الصحيح ولا داعي لمواصلة القراءة.

Shopify ليس إطار عمل بقيود. هو منتج تستأجره، والإيجار يشمل الاستضافة ونطاق امتثال PCI وفحص الاحتيال والإتاحة وفريقًا مهمته كلها إبقاء صفحة دفع تعمل يوم الجمعة السوداء. وإعادة بناء ذلك لتملكه تحتاج سببًا أفضل من الرغبة في تملّكه.

ما يكلّفه Shopify فعلًا

قبل أن تحكموا بأنه باهظ، اجمعوه جمعًا صحيحًا، فهذا ما لا يكاد أحد يفعله.

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

دوّنوا ذلك المجموع. أحيانًا يكون كبيرًا فعلًا وتدافع الحجة عن نفسها. وغالبًا يكون أصغر من كلفة صيانة ما سيحل محله، ومعرفة ذلك قبل البدء تستحق الساعة التي تستغرقها.

الحدّ هو الطلب لا الكتالوج

حجم الكتالوج مقياس خاطئ. فـ Shopify يتعامل مع الكتالوجات الكبيرة بارتياح، ورأينا كتالوجات صغيرة كان عليها أن ترحل.

الخط هو الطلب. إن كان طلبكم هذه الأصناف، هذا العنوان، هذه الدفعة، فـ Shopify يمثّله أصلًا وكل شيء يعمل. ويكف عن الملاءمة حين يحمل الطلب قواعد عمل لا مفهوم لها عند Shopify:

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

كلٌّ من هذه يمكن تقريبه بتطبيقات وحقول وصفية. والسؤال كم تقريبًا يشغّله العمل في آنٍ واحد، وهل ما زال أحد يستطيع أن يقول أين تعيش القاعدة، وهو السؤال نفسه الذي يحسم الأمر على أي منصة.

ما يجب أن يستحقه البناء المخصص

المتجر المخصص يبدأ متأخرًا. بلا صفحة دفع ولا فحص احتيال ولا منظومة تطبيقات ولا فريق مناوب. ولكي يستحق، عليه أن يزيل من العمل أكثر مما يُحدث.

والحالات التي يفعل فيها ذلك محددة. عملٌ يكون فيه مسار الطلب نفسه هو المنتج. وتشغيلٌ تذهب فيه ساعات موظفين يوميًا في الالتفاف حول المنصة. وشركةٌ يقيم مخزونها وتسعيرها في نظام لا يستطيع Shopify مخاطبته إلا بملف CSV ليلي. هذه حقيقية، وشائعة بما يكفي لأن نبنيها، وليست أغلب المتاجر.

الشكل الذي يُبقي Shopify

القرار نادرًا ما يكون كل شيء أو لا شيء، والخيار الأوسط مبخوس حقه.

يحتفظ Shopify بصفحة الدفع وامتثال المدفوعات والجزء من المسار الذي تكون فيه الأخطاء باهظة ومنظَّمة. ويملك تطبيق Laravel لديكم محرك التسعير والصلاحيات وحالات التجهيز وبنية حسابات الشركات - كل ما يجعل عملكم غير اعتيادي - ويخاطب Shopify عبر واجهته.

وما يلزم تصميمه عمدًا هو أي نظام يملك الحقيقة عن الطلب بعد وجوده، وماذا يحدث حين يختلف الاثنان. تلك هي التسوية، وهي العمل الذي نقضي فيه أطول وقت في أي تكامل.

إن انتقلتم فعلًا

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

وابنوا نموذج الطلب قبل واجهة المتجر. فالواجهة هي ما يريد الجميع النظر إليه، وهي الأرخص تغييرًا لاحقًا. أما الطلب فليس أيًّا من الاثنين.

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