عن المشروع

Cratefield Harness هو النواة مفتوحة المصدر والمرخصة بموجب MIT خلف Cratefield، وهو إطار عمل خلفي بلغة Rust يمكنك من خلاله تجميع نظامك الخلفي الخاص. الفرضية المعلنة هي أن كل منتج يحتاج إلى نظام خلفي ولا ينبغي بناء أي منها من الصفر، لذا فإن هذا هو ذلك النظام الخلفي الموحد. يمكنك اختيار crates الوحدات، وتوصيل المحولات، وشحن Worker واحد عديم الحالة مع قاعدة بيانات خاصة به. نموذج التكوين: يعلن المشروع عن منشئ Harness بهوية المشروع، ورابط URL عام، وأصول CORS، ويضيف الوحدات، ويختار وقت التشغيل (runtime) مع ربط قاعدة البيانات ومزودي البريد الإلكتروني والـ captcha. يرفض البناء أي وحدة تتطلب منفذاً لا يوفره وقت التشغيل، أو وحدتين تدعيان نفس الجدول أو المسار، أو وحدة مبنية مقابل إصدار عقد مختلف. يقوم قالب المشروع بتشغيل التكوين تحت cargo test، لذا فإن أي خطأ في التكوين يفشل قبل النشر. الوحدات والمنافذ: الوحدة هي crate تنفذ سمة Module ويتم تثبيتها في مسار مصنف حسب إصدار اسم الوحدة. تعلن الوحدة عن اسمها، والمنافذ المطلوبة، والترحيلات (Migrations) (SQL مدمجة عبر include_str!، في مجموعة فرعية يقبلها كل من SQLite و Postgres) وموجه axum. لا تلمس الوحدات أبداً روابط الموردين أو متغيرات البيئة أو عملاء الموردين؛ بل تطلب منافذ مثل Database و Mailer و Captcha و RateLimiter و Signer و KeyValue، وتجيب المحولات على ذلك. وفقاً لملف README، فإن هذه القاعدة الوحيدة هي ما يجعل الانتقال بعيداً عن Cloudflare مجرد تغيير في crate واحدة لوقت التشغيل. الـ crates المضمنة: واجهة cratefield؛ و cratefield-core التي تحتوي على سمة Module، ومنشئ Harness، وسمات المنافذ، وأخطاء problem+json، ونطاق الطلب، وناقل الأحداث والقوالب؛ و cratefield-runtime-cloudflare؛ ومحولات لبريد Resend و captcha Turnstile و SQLite عبر rusqlite؛ ووحدات email-signup مع خيار التأكيد المزدوج وإلغاء الاشتراك وتصدير المسؤول، و waitlist مع التأكيد والموقع وأكواد الإحالة؛ و cratefield-secrets لتشفير الأسرار المغلفة عبر منفذ Database؛ و cratefield-kms لتغليف وفك تغليف مفاتيح البيانات، مع مزود ملفات محلي يرفض العمل في بيئة الإنتاج؛ و cratefield-ui التي تعرض سطح الوحدة كـ HTML في /ui؛ و cratefield-cli التي توفر الثنائي fz مع أوامر تجميع الترحيلات و doctor والوحدات؛ و cratefield-testing، وهي مجموعة مطابقة يجب أن تجتازها كل وحدة. الـ crates المخطط لها هي cratefield-adapter-postgres عبر sqlx و cratefield-runtime-native على tokio. الترحيلات والطلبات: تمر الاستعلامات عبر sea-query لذا فهي تظهر لأي من قاعدتي البيانات. روابط التأكيد وإلغاء الاشتراك هي رموز موقعة بـ HMAC مع تدوير المفاتيح، لذا لا يوجد مخزن للجلسات. ينتقل نطاق الطلب في ملحقات axum بدلاً من الحالة المشتركة، وتتضمن مجموعة المطابقة اختبار طلب متزامن للتحقق من ذلك. التثبيت: يتم إما تجميع الوحدة داخل Worker، وهو الخيار الافتراضي، أو تشغيلها كـ sidecar مع Worker خاص بها يتم بناؤه ونشره بشكل منفصل وتثبيته في نفس المسار عبر ربط خدمة مع نفس قاعدة البيانات والأسرار. يذكر ملف README أن خيار sidecar مصمم ولكن لم يتم بناؤه بعد. القابلية للملاحظة: يحمل span مهيكل واحد لكل طلب معرف الطلب (request_id)، والطريقة، والمسار، والوحدة، والحالة، والمدة بالملي ثانية، و ip_hash و ua_family، ولا يحمل أبداً عنوان بريد إلكتروني. يتم تفعيل Workers Logs في قالب wrangler.toml وتكرر الاستجابات x-request-id. يتم إنشاء تصنيف الأخطاء من سجل النواة ويتم التحقق من الانحراف في CI. خارطة الطريق كما وردت في المستودع: M0 التأسيس (أدوات مساحة العمل، النواة، وقت تشغيل Cloudflare، محولات Resend و Turnstile، محول SQLite، fz، مجموعة الاختبار)، M1 الوحدات الأولى، M2 أول مشروع مباشر مع النشر على crates.io والوثائق وإصدارات العقود (مشار إليها بأنها قيد التنفيذ)، و M3 إمكانية النقل للاستضافة الذاتية مع محول Postgres، ووقت التشغيل الأصلي، ومجموعة التكافؤ ونقل البيانات. تم تحديد ثلاث مراحل كبرى أخرى ولكن لم يتم تحديد جدول زمني لها. سلسلة الأدوات والحالة: نسخة Rust المستقرة مثبتة في rust-toolchain.toml، والهدف هو wasm32-unknown-unknown، و worker-build و wrangler؛ يقوم CI بتشغيل fmt و clippy مع رفض التحذيرات، والاختبارات، و cargo deny، وبناء المشروع التجريبي إلى wasm حتى لا يتسرب أي اعتماد خاص بالنظام الأصلي فقط إلى وحدة ما. لم يتم نشر الـ crates بعد في crates.io، لذا ينصح ملف README بالاعتماد على المستودع عبر git. يتم وضع علامة publish = false على الـ crates الخاصة بدلاً من وضعها في مستودع منفصل. الترخيص: MIT.