Vercel أم Netlify: أين يُخدَّم الواجهة

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

ما الذي يُنشر فعلًا؟

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

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

هل تحتاجون دوال خادم أم ملفات فقط؟

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

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

أي نموذج دفع يناسب طريقة عملكم؟

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

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

هل تستحق المعاينة لكل فرع الانتقال وحده؟

لفريق من أكثر من شخص، نعم. كل فرع وكل طلب دمج يحصل على عنوان خاص، مبني من ذلك الالتزام، ببيئته الخاصة، فيفتح العميل الصفحة العربية للتغيير على هاتفه قبل الدمج.

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

أين يقع الارتباط الحقيقي؟

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

لا واحد من هذه فخ بذاته، ومجموعها يحدد ثمن المغادرة. موقع من HTML وأمر البناء واحد ينتقل في ظهيرة؛ وموقع قواعده كلها إعداد عند المورّد ينتقل بإعادة كتابة، وتُسعَّر إعادة الكتابة بأسعار وكالة لأنها كذلك.

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

كيف يبدو الأداء من الجزائر؟

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

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

كيف تختلفان في القرار الذي يهم؟

القرار	Vercel	Netlify
الأنسب لـ	تطبيق إطار عمل طبقة خادمه جزء من المنتج	صفحات ونماذج وتحويلات، والبيانات في نظام آخر
كود الخادم	مصمم داخل النشر، يتقاسم معه التوجيه والتخزين المؤقت	دالة إلى جانب الناتج الثابت
المعاينات	لكل فرع وطلب دمج	لكل فرع وطلب دمج
الخروج	إعادة بناء طبقة الخادم عند مستضيف آخر	نقل الملفات وإعادة كتابة المعالجات

اقرؤوا الجدول صفًا صفًا. إن كان الصف الأول يصف موقع تعريف، فالصف الرابع وحده سيكلفكم لاحقًا.

كيف تقررون في ظهيرة؟

1. اكتبوا صفحات الموقع، وأشيروا إلى ما يجب أن يقرأ بيانات لحظة الطلب.
2. إن لم توجد صفحة كذلك، فالقرار قرار استضافة ثابتة: المعاينات وDNS والدعم، لا الدوال.
3. إن وُجدت، فاكتبوا الدالة الواحدة التي لا مفر منها، واختبروها على الحدود التي توثقها كل منصة: مدة التنفيذ والذاكرة والبداية الباردة.
4. عدّوا الإعدادات التي ستسكن ملفًا خاصًا بالمورّد. هذا العدد هو فاتورة الخروج.
5. انشروا الفرع نفسه على المنصتين، وافتحوا الصفحة العربية على هاتف، وقارنوا ما ينزّله المتصفح فعلًا.
6. اكتبوا صفحة الخروج قبل التوقيع: أمر البناء، والمتغيرات، وسجلات DNS، واسم من يستطيع تنفيذها.

أين يخطئ هذا؟

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

ما لا يغطيه هذا المقال

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

نبني واجهات يمكن إعادة بنائها في مكان آخر، بالمستودع وإعدادات البناء والمتغيرات وسجلات DNS مكتوبة، فيكون النشر الثاني ظهيرة لا مشروعًا.