منتج يقبض بـ Stripe مبني بلغة C وقاعدة SQLite وملف تنفيذي واحد دون framework
المغزى: كثير من الطبقات التي تُعدّ ضرورية في بناء منتج ويب هي حلول لمشكلات حجم لم يصل إليها المنتج بعد، والثمن الحقيقي للتخلي عنها هو كتابة الحمايات يدويًا.
نشر المطوّر Corey Prophitt مقالة يشرح فيها كيف بنى منتجه marketyour.games، وهو منتج يعمل ويقبض المدفوعات عبر Stripe، فيه حسابات مستخدمين، ولوحة بحث لصنّاع المحتوى، ومجلدات، ورسائل بريد معاملات عبر Postmark. ولا تحمل المقالة تاريخ نشر على الصفحة.
والمكدّس كله يُعرف باختصار BCHS: نظام OpenBSD، ولغة C، وخادم httpd، وقاعدة SQLite. فلا framework، ولا لغة قوالب، ولا خادم قاعدة بيانات منفصل، ولا container. والتطبيق ملف تنفيذي واحد مربوط استاتيكيًا، واعتمادياته ثلاث فقط: libcurl وlibsodium وlibcjson. ويعمل بأسلوب progressive enhancement دون أن يحتاج إلى JavaScript.
ويعتمد على CGI، وهي طريقة قديمة يفتح فيها كل طلب process جديدة، تقرأ بيانات الطلب من متغيرات البيئة، وتكتب HTML، ثم تنتهي. والنتيجة العملية أن نشر نسخة جديدة يعني استبدال ملف واحد، دون إعادة تشغيل ولا فترة انقطاع ولا نسخة قديمة باقية. والصور والملفات مترجمة داخل الملف التنفيذي نفسه وتُخدم من الذاكرة.
ولا تقدّم المقالة أرقامًا عن زمن الاستجابة أو عدد الطلبات في الثانية أو حجم الملف التنفيذي، فالدعوى فيها عن عدد الأجزاء المتحركة لا عن السرعة. والرقمان الوحيدان أن البناء النظيف يستغرق ثواني قليلة، وإعادة البناء أقل من نصف ثانية.
ويذكر الكاتب العيوب بنفسه. فـ CGI لا يوفر أي مساعدة في الكوكيز، ولا في تحليل الـ query والنماذج، ولا في التحقق من المدخلات، ولا في تهريب المخرجات. فكتب ملف cgi.h بنفسه، ونظر في مكتبة kcgi لكنه تحفّظ على واجهتها ونموذجها الأمني. أي أن الحمايات التي يقدمها الـ framework عادة صارت مسؤوليته وحده.
والتجربة لا تعني أن كتابة المنتجات بلغة C هي الخيار الصحيح. لكنها تجعل سؤال حجم المكدّس سؤالًا مشروعًا، خصوصًا للمبتدئين الذين يُقال لهم إن الـ container وقاعدة البيانات المُدارة ضرورة من اليوم الأول.