أولا وقبل كل شيء: كيف انتهى كل شيء
إذا كنت ترغب في تخطي القصة كاملة ومشاهدة النتيجة مباشرة، ها هي:
- تمت إعادة كتابة flaming.codes من الصفر (ومن هنا فصاعدًا سيشار إليها بالإصدار الثاني) والآن تستخدم Qwik و Qwik City كإطار عمل أساسي، حيث كانت تستخدم Next.js سابقًا
- أزلت جميع الاعتماديات المتعلقة بنظام إدارة المحتوى الخارجي وطبقة التخزين المؤقت وأصبحت أستضيف جميع المحتويات في مستودع Github الخاص بهذا التطبيق الويب التقدمي (PWA)
- قمت بذلك عندما لاحظت أن الاحتفاظ بكل تلك الطبقات من الإصدار الأول ل flaming.codes كان عملاً شاقاً - القشة التي قصمت ظهر البعير كانت عندما احتجت لتحديث نظام إدارة المحتوى (Sanity) وكنت سأضطر لإعادة كتابة بعض الأشياء على أي حال
- تم استبدال مكون الترجمة في الإصدار الأول والذي كان يتضمن محلل مخصص للمستندات والترجمة عبر Google Translate بمحتوى markdown البحت و OpenAI's GPT-4 على التوالي
- لم أقم بعد بتنفيذ ميزة TTS (تحويل النص إلى كلام)، لكني سأفعل ذلك في المستقبل القريب باستخدام نموذج Whisper الخاص بـ OpenAI
- ما زال موقع flaming.codes يستضاف على Vercel، لكنه يستخدم الآن Edge Functions لخدمة الموقع، بدلًا من Build Output API، حيث ليس هناك حاليًا أداة نشر متاحة من Qwik City
- تم تحديث التصميم أيضًا وأصبح الآن يدعم كل من الوضع الليلي والوضع الساطع باستخدام ألوان Windy Radix لتتوفر ألوان Radix كفئات Tailwind
غادر نظام إدارة المحتوى، عاش نظام إدارة المحتوى
السبب الرئيسي الذي دفعني لكتابة الإصدار الثاني من flaming.codes كان لتقليل الاعتماد على خدمات أخرى:
- إزالة نظام إدارة المحتوى (وخدمة CDN الخاصة به) وإدارة واستضافة جميع المحتويات (المقالات، الفئات، المواد الأخرى، إلخ) مباشرة في المستودع، والذي سيتم أيضًا فتح مصدره
- كجزء من هذا الانتقال، إزالة طبقة التخزين المؤقت لمحتوى نظام إدارة المحتوى، حيث لم تعد هناك حاجة لذلك
- استبدال استخدام Google Translate وكذلك خدمة Microsoft text-to-speech بواجهات برمجة التطبيقات من OpenAI
الانتقال بعيدًا عن نظام إدارة المحتوى القوي مثل Sanity ومُنشئ الاستعلام الديناميكي يأتي بتكلفة الحاجة إلى تنفيذ بعض إدارة المحتوى (الخفيفة) بنفسي. لا أريد الاهتمام بضرورة تحديث وصيانة مكون أساسي من المشروع. هدفي هو أن تعمل هذه الحلول حتى لو لم أكتب مقالة لمدة عام، لأن المتطلب الوحيد يجب أن يكون فتح المستودع، كتابة مقالة ثم ببساطة دفع التغييرات على الفرع الرئيسي لإطلاق نشر جديد.
يمكنكم الاطلاع على دليل /cms في الجذر لمشروع GitHub لرؤية شيفرة المصدر بأنفسكم. تعمل بشكل جيد، وهي بسيطة ومستقلة تمامًا، لا حساب إضافي ولا تسجيل دخول لنظام إدارة المحتوى مطلوب. تجربة الخروج أصبحت الآن أكثر قوة من ذي قبل، حيث يمكنني الآن استخدام Markdown لجميع المحتويات، وهو أسهل بكثير للكتابة والصيانة من المحرر المخصص لـ Sanity. أضفت خيار إعادة التحميل الفورية لتشغيل سكريبت المحرر، حتى أتمكن من رؤية التغييرات في الوقت الفعلي - إذا أردت حتى لأكثر من لغة واحدة في وقت واحد.
سأدخل في مزيد من التفاصيل حول نظام إدارة المحتوى في مقال منفصل.
لماذا اخترت Qwik و Qwik City بدلًا من Next.js
كان Qwik وإطار العمل الشامل الخاص به المسمى "Qwik City" مثيرة للاهتمام بالنسبة لي منذ البداية: تحميل كسول لأي JS تلقائيًا حتى يكون هناك حاجة فعلية له دون أي تجديد. في سياق flaming.codes، تكون المكاسب من هذه الهندسة تتناقص، حيث أن موقعي في جوهره مدونة. كلما زادت عناصر وتفاعلات تطبيق الويب، كانت التحسينات الناتجة عن استخدام Qwik أكبر. ومع ذلك، كنت فضوليًا وأردت اكتساب بعض الخبرة العملية معه.
التدويل (i18n) في Qwik مقارنةً بـ Next.js
يتم ترجمة موقع flaming.codes إلى 14 لغة، بما في ذلك بعض اللغات التي تُكتب من اليمين إلى اليسار. عندما نظرت إلى Qwik للمرة الأولى في بداية عام 2023 (حوالي 10 أشهر قبل أن أقوم بإعادة كتابة الإصدار الثاني فعليًا)، شعرت بأنه لا توجد حل حقيقي للتدويل، وتلاشت جهودي بعد بعض الاختبارات الأولية.
عند النظر إليه مرة أخرى في ديسمبر، كانت qwik-speak هي الحل المطلوب لتمكين الترجمات في flaming.codes، لذلك قمت بتنظيف النسخة القديمة من قاعدة البيانات وبدأت الإعادة الكتابة.
مترجم جديد
استخدمت الحزمة القديمة Google Translate API، التي خدمتني بشكل جيد، لكن المكون بأكمله جاء ببعض التعقيدات:
- تم جلب المحتوى باللغة الأصلية من نظام إدارة المحتوى Sanity، وتحليله وتقسيمه إلى كتل وسيطة
- تم ترجمة كل كتلة إلى لغات الهدف المتاحة
- تم إعادة بناء الكتل المترجمة بحيث يتم استعادة المحتوى الأصلي، بما في ذلك التنسيق، وتوفيره لواجهة المستخدم الأمامية ليتم استخدامه
عمل الأمر بشكل كافٍ، ولكن الكود كان صعب القراءة والصيانة نسبيًا.
يستخدم موقع flaming.codes الآن OpenAI لترجمة جميع المحتويات. الإعداد بأكمله أبسط بكثير:
- يتم كتابة مقال جديد بوضوح باستخدام Markdown
- يتم إرسال المقال إلى OpenAI وترجمته بالكامل
- النماذج اللغوية الكبيرة ذكية بما يكفي لترجمة الأجزاء ذات الصلة فقط، وليس على سبيل المثال ترجمة كل الفرونتماتر (يعطي المطالب توجيهات للنموذج اللغوي بشأن الحقول التي لا ينبغي اعتبارها جزءًا من الإجراء)
النشر على فيرسل
يمكن تصدير Qwik City كموقع ثابت (SSG)، لكن هذا يعني أني لا أستطيع استخدام نقاط النهاية الديناميكية، وبالتالي يستخدم flaming.codes "Vercel Edge" المحول للاستمرار في النشر والاستضافة من خلال Vercel. كنت أود أن يكون "Build Output API" من Vercel متاحًا أيضًا كمحول، ولكن الآن هذا كافٍ.
استخدم flaming.codes سابقًا Build Output API، الذي يعني أن الكود الجانبي للخادم استخدم واجهات برمجة تطبيقات Node.js - على Vercel Edge، لم يعد هذا ممكنًا بعد الآن، حيث أنه خليط غريب ومربك بين واجهات برمجة تطبيقات الويب و Node.js. هذا تطلب مني إعادة كتابة بعض المكونات لتحقيق التوافق.
الذكاء الاصطناعي والشفافية
بينما لا يكون جاهزًا للإصدار الأولي من الإصدار الثاني، سأحدث قريبًا خصائص البيانات الوصفية للمقالات الجديدة لتحتوي على مزيد من المعلومات حول الجوانب التي تم إنشاؤها باستخدام الذكاء الاصطناعي.
في نفس الخطوة، سأجعل أيضًا تحليلات الموقع متاحة للجمهور لزيادة الشفافية. يستخدم flaming.codes Plausible.io، خدمة تحليل احترام الخصوصية لتجميع الاستخدام الأساسي.
تصميم جديد
كج
