لماذا يوجد هذا الموقع؟

مشكلة قديمة عند تعلّم أي تقنية جديدة هي أن معظم الوثائق والأمثلة التي قد تجدها على الإنترنت أو تحصل عليها من أدوات الذكاء الاصطناعي تكون سطحية جداً لدرجة أنها لا تعطيك أي فكرة عمّا إذا كانت التقنية — أو تطبيقك لها — ستصمد أمام عبء عمل حقيقي ومعقّد. مثال على ذلك هو كثرة أمثلة قوائم المهام (to-do list).

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

Cloudflare كهدف للنشر

تبدو Cloudflare Workers https://workers.cloudflare.com/ للوهلة الأولى طريقة رخيصة للغاية لنشر تطبيق معقّد. تطوير الـ back-end يبدو بسيطاً ومتيناً، وحزمة OpenNext https://opennext.js.org/ تبدو وكأنها توفّر طريقة فعّالة لتطوير الواجهة الأمامية باستخدام Next.js https://nextjs.org/ والنشر إلى Cloudflare.

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

اجعل هذا الموقع أكثر تعقيداً مما ينبغي

خلفية إدارة المحتوى (CMS)

بكل صراحة، هذا الموقع، بوضعه الحالي، يمكن ترقيعه وتجميعه بواسطة وكيل برمجي خلال بضع ساعات؛ ولكن النظام الجاد لا ينبغي أن يحتاج إلى عملية نشر لتغيير المحتوى الأساسي. لذلك، يستخدم هذا الموقع نظام CMS كاملاً مبنياً على Payload CMS (https://payloadcms.com/) ويتم نشره كـ Cloudflare Worker منفصل.

يستخدم Payload نفسه قاعدة بيانات SQL، والتي بدورها تحتاج إلى النشر كنسخة CloudFlare D1 SQLite database instance https://developers.cloudflare.com/d1/، وإدارتها بشكل صحيح عبر ترحيلات قاعدة البيانات (database migrations) لدعم دورة حياة التطوير.

الترجمات المؤتمتة

هذا الموقع يدعم 20 لغة. وبما أن الموقع مجرد هيكل بسيط لمحتوى الـ CMS، فإن جانب i18n يتم التعامل معه بواسطة وكيل برمجي (Co-pilot وClaude Opus 4.5) أثناء التطوير.

يبقى أن كل محتوى الـ CMS الحالي والمستقبلي يحتاج إلى الترجمة تلقائياً كلما تم تغيير أي محتوى باللغة الإنجليزية.

عامل مبني على الطوابير وCron

متطلب الترجمة يتطلب عملية معقّدة بشكل معقول تقوم بـ:

• سيتم تشغيلها على مؤقّت Cron.
• تحديد أي محتوى يحتاج إلى ترجمة جديدة.
• تنفيذ الترجمة بشكل موثوق.
• التعافي بشكل موثوق من الفشل.

لذلك، يتم استخدام نسخة CloudFlare D1 أخرى لتتبّع أعمال الترجمة، وتُستخدم Cloudflare queues (https://developers.cloudflare.com/queues/) مع نمط منتِج-مستهلك مبني على cron لإدارة المهام وتوسيعها. يتم استدعاء واجهة OpenAI’s gpt-5.2 API لإجراء الترجمات، وتقوم AI.SDK https://ai-sdk.dev/ بربط كل ذلك معاً.

بالنسبة لهذا الموقع، هذا مبالغة؛ لكن أي نظام إنتاجي، بأي حجم كان، يحتاج إلى نمط متين لتنظيم المعالجة في الخلفية.

الإصدارات السابقة من هذا الموقع

لقد نفذت هذا الموقع مرتين من قبل كأداة لتعلّم تقنيات جديدة:

2013 - تعلّم Ruby وAWS

• Ruby on Rails v4.0.0.
• تنسيق Bootstrap v3.
• CoffeeScript لواجهة المستخدم.
• نمط الواجهة الأمامية Backbone Marionette VMC.
• تم نشره على مضيف AWS.

2017 - تعلّم React

• React v16.0.0 لواجهة المستخدم.
• Redux وThunk للعمليات غير المتزامنة.
• Semantic UI للتنسيق.

ما التالي

الموقع موصول بشكل صحيح لتحسين محركات البحث (SEO)، وهناك حاجة إلى وتيرة منتظمة من المحتوى الجديد لزيادة حركة الزواحف. سأقوم بنشر مقالات أكثر تفصيلاً حول التقنيات والحلول المختلفة المستخدمة.