Shopify أم Next.js: ليس الاختيار الذي يبدو عليه

صياغة هذا السؤال خاطئة بطريقة تكلّف مالًا، فلنصلحها قبل كل شيء.

Shopify وNext.js ليسا طريقتين لإدارة متجر. ففي كل صيغ هذا القرار تقريبًا يبقى Shopify: يحتفظ بالمنتجات والطلبات وصفحة الدفع وامتثال المدفوعات ولوحة الإدارة التي يعرفها فريقكم. وما هو مطروح فعلًا أضيق وأرخص مما يبدو: من يعرض واجهة المتجر.

ما تشتريه واجهة متجر منفصلة

ثلاثة أشياء، وتستحق تسمية دقيقة لأن التسويق حولها مبهم.

عرضٌ تتحكمون فيه. أي الصفحات ثابت، وأيها يُعاد التحقق منه، وأيها ديناميكي، وما الذي يُبثّ. قالب Liquid له نموذج عرض واحد ولا تستطيعون تغييره. وهذا هو النموذج كله، وفي صفحة منتج هو الفرق بين أن يبدأ طلب الصورة داخل HTML أو أن يبدأ بعد سكربت.

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

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

ما يكلّفكم إياه

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

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

صفحة الدفع، غالبًا. تبقى صفحة الدفع على Shopify، وهذه هي النتيجة الصحيحة وتستحق القول بوضوح. أنتم لا تعيدون بناء الجزء المنظَّم.

Hydrogen أم Next.js، وهي المفترق الحقيقي

بعد أن تقرروا امتلاك واجهة المتجر، يصير هذا هو الاختيار الفعلي.

Hydrogen إطار Shopify نفسه، مبنيٌّ على Remix، وافتراضات Shopify فيه محسومة سلفًا، ومعه Oxygen للنشر. وإن كانت الواجهة ستبقى واجهة متجر فحسب، فهو خيار افتراضي وجيه وأمامكم قرارات أقل.

ويستحق Next.js مكانه حين يكون الموقع أكثر من المتجر: صفحات تسويقية لها احتياجات عرض خاصة، ومحتوى لا ينتمي إلى Shopify، ونظام تصميم مشترك مع تطبيق، ومصدر بيانات ثانٍ. عند تلك النقطة تبدأ افتراضات Hydrogen في التكليف بدل المساعدة.

اختبار الزيارات، قبل هذا كله

خذوا القوالب التي تحمل إيراداتكم. عادةً الصفحة الرئيسية، ومجموعة واحدة، وصفحة منتج.

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

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

متى يكون القالب هو الصواب ببساطة

متجر هو متجر. وفريق بلا مطوّر واجهات. ومسار عرض بضائع يعتمد على محرر القوالب. وكتالوج يتغير أكثر مما تتغير الشيفرة.

نحن نبني واجهات منفصلة ونقول هذا رغم ذلك: قالب Liquid مصان جيدًا يتفوق على واجهة منفصلة لا يعتني بها أحد، والثانية هي ما يبقى حين ترحل الشركة ولم يُسلَّم شيء. وما يشمله البناء فعلًا هو السؤال الذي يُطرح قبل التوقيع مع أي جهة، ونحن منها.