Axum vs Actix-web: أي إطار عمل Rust قيد الإنتاج؟

يعمل كل من Axum وActix-web على Tokio، وهو وقت التشغيل المرجعي غير المتزامن في Rust. ينص ملف Actix-web README على ذلك بصراحة - "التوافق الكامل مع Tokio" - ولا يستخدم مثال الكود الرسمي الخاص به أي ممثل من إطار عمل actix التاريخي: معالج async fn الكلاسيكي، المشروح #[get(...)]، كافٍ. لم يعد الارتباك "يتطلب Actix-web بالضرورة جهات فاعلة" يتوافق مع واجهة برمجة التطبيقات الحالية.

وُلد أكسوم في المدار المباشر لطوكيو: المستودع ينتمي إلى منظمة GitHub tokio-rs، ووثائقه الرسمية لا لبس فيها - "تم تصميم axum للعمل مع tokio وhyper. إن استقلالية وقت التشغيل وطبقة النقل ليست هدفًا، على الأقل في الوقت الحالي. "

لذا، فهو ليس خيارًا بين وقتي تشغيل متنافسين، ولكن بين طريقتين لإنشاء واجهة برمجة تطبيقات HTTP فوق نفس المحرك غير المتزامن. تغطي هذه المقارنة أربعة مجالات يمكن التحقق منها - نموذج البرمجيات الوسيطة، وأمان الذاكرة المعلن، وسطح HTTP الأصلي، والاعتماد الذي تم قياسه على صناديق.io وGitHub - ثم تشرح، مع التعليمات البرمجية الداعمة، سبب اختيار نواة Rust لـ Aurabase لـ Axum.

لا تقوم شركة Axum ببناء أي أنظمة برمجيات وسيطة خاصة بها. إنه يعتمد كليًا على tower::Service: المهلات، والتتبع، والضغط، والترخيص - كل شيء يأتي "مجانًا" عبر نظام Tower البيئي، وفقًا لملف README الخاص به. يمكن إعادة استخدام البرامج الوسيطة المكتوبة لتطبيق Hyper أو Tonic كما هو الحال في تطبيق Axum، بدون تعديل.

يأخذ Actix-web المسار المعاكس: فهو يقوم بتضمين نظام البرامج الوسيطة الخاص به (Logger، Session، CORS، وما إلى ذلك)، الموثق في دليل المستخدم الخاص به، مع عميل HTTP المرتبط به (awc). إنها منصة أكثر تكاملاً - عدد أقل من الأجزاء التي يمكن تجميعها، ولكنها أيضًا أقل إعادة استخدام مباشرة مع بقية النظام البيئي العام لـ Rust async.

يتبع التوجيه نفس منطق التركيب الصريح. تدعي Axum "واجهة برمجة تطبيقات خالية من وحدات الماكرو" للإعلان عن المسارات - تظل Router::new().route(...) قيمة Rust عادية - حيث يعتمد Actix-web على وحدات ماكرو مخصصة بواسطة طريقة HTTP (#[get(...)]) الموضوعة مباشرة فوق المعالج. أسلوبان بيان، وليس الفرق في القدرة.

يدعي Axum #![forbid(unsafe_code)] في الكود المصدري الخاص به: 100% من إطار العمل مكتوب بلغة Rust الآمنة، دون أي ثغرات. لا يقدم Actix-web بيانًا مماثلاً في ملف README الخاص به - وهذا لا يعني أن إطار العمل خطير، ولكن لا يتم عرض مثل هذا الضمان علنًا بواسطة المشروع.

يحدد الإطاران حدًا أدنى مختلفًا لإصدار Rust: Axum متوافق مع Rust 1.80، ويتطلب Actix-web Rust 1.88. نافذة أضيق لـ Actix-web، والتي قد تكون مهمة إذا كانت سلسلة الأدوات الخاصة بك عالقة في إصدار أقدم.

يسرد Actix-web سطح HTTP كبيرًا مباشرة في صندوقه: HTTP/1.x وHTTP/2، WebSockets، الضغط الشفاف (br، gzip، deflate، zstd)، TLS عبر OpenSSL أو Rustls. كل شيء يأتي معًا، دون أي تبعيات إضافية للاختيار من بينها.

يظل Axum في حده الأدنى عمدًا: التوجيه، والمستخرجات، ومعالجة الأخطاء - أما الباقي (الضغط، CORS، تحديد الطلب، التتبع) فيأتي من tower-http، وهو صندوق مصاحب من نفس النظام البيئي. Aurabase، على سبيل المثال، يمكّن فقط ميزات corsو traceو compression-gzipو request-idو timeout و limit الخاصة بـ tower-http - وهو اختيار متعمد، وليس الحزمة بأكملها.

تدعي Actix-web سرعتها من خلال الاستشهاد بمصدر خارجي دقيق: "واحدة من أسرع أطر عمل الويب المتاحة وفقًا لمعيار TechEmpower Framework Benchmark"(R21، مركب)، مع رابط مباشر إلى techempower.com في الملف التمهيدي الخاص به. هذا هو نوع الاقتباس الذي يمكنك التحقق منه بنفسك.

لا يقدم أكسوم أي مطالبة مماثلة. يقتصر ملف README الخاص به على عبارة أكثر تواضعًا - "axum عبارة عن طبقة رقيقة نسبيًا فوق الطبقة الفائقة ولا تضيف سوى القليل جدًا من الحمل" - مع رابطين لمعايير مجتمع الطرف الثالث، وليس رقمًا رسميًا للمشروع.

على crates.io، حصل Axum على 436,464,896 تنزيلات إجمالاً، بما في ذلك 109,000,226 على مدار آخر 90 يومًا. Actix-web يتراكم 78,074,020 إجمالي التنزيلات، بما في ذلك 9,730,975 على نفس النافذة الأخيرة (crates.io، تم الوصول إليه في 23 أغسطس 2026). فيما يتعلق بهذه النقطة، فإن الفجوة واضحة: يتلقى Axum اليوم تنزيلات أكثر حداثة بحوالي 11 مرة من Actix-web.

المفارقة: Actix-web هو الأقدم بين الاثنين، وتم نشره على crates.io منذ أكتوبر 2017، مقارنة بيوليو 2021 لـ Axum. على GitHub، أصبحت فجوة الشعبية أضيق — 26,931 نجمة لـ tokio-rs/axum مقابل 24,793 لـ actix/actix-web (GitHub، تم الوصول إليه في 23 أغسطس 2026) - وتحتفظ Actix-web بمزيد من التفرعات (1880 مقارنة بـ 1462)، وهي علامة على أن قاعدة المساهمين التاريخية لا تزال نشطة.

لا يزال Actix-web بعيدًا عن التخلي عنه: فقد تم نشر نسخته 4.15.0 في 21 أغسطس 2026، أي قبل ثلاثة أيام من كتابة هذا المقال. في قائمة انتظار إصدار GitHub، يعرض Axum 75 تذكرة مفتوحة مقارنة بـ 192 تذكرة لـ Actix-web - وهي إشارة صيانة يجب قراءتها بحذر: التاريخ الأطول بحوالي أربع سنوات يؤدي إلى طابور انتظار أطول، وهذا ليس دليلاً على مشروع أقل حذرًا.

تحتوي مساحة عمل Aurabase root Cargo على إحدى عشرة خدمة. عشرة تعتمد مباشرة على Axum - من بوابة API (aura-gateway) إلى محرك الذكاء الاصطناعي الأصلي (aura-ai)، بما في ذلك المصادقة والتخزين. الحادي عشر، aura-migrator، عبارة عن أداة ترحيل CLI بدون خادم HTTP: فهو ببساطة ليس لديه أي شيء للاختيار من بينها. لا يوجد Cargo.toml في المستودع - ولا أي إدخال في الجذر Cargo.lock - يعلن عن actix-web، حتى في التبعية المتعدية؛ ولا يوجد ملف .rs يحتوي على تعليمات use actix_web::.

axum       = { version = "0.8", features = ["ws", "multipart", "macros"] }
tower      = { version = "0.5", features = ["full"] }
tower-http = { version = "0.6", features = ["cors", "trace", "compression-gzip", "request-id", "timeout", "limit"] }
hyper      = { version = "1", features = ["full"] }

هذا الاختيار ليس تجميليًا: تقوم بوابة Aurabase (aura-gateway) بتجميع برامجها الوسيطة مع tower::ServiceBuilder و Layer Tower — TraceLayer, TimeoutLayer, RequestBodyLimitLayer - تكملها طبقات داخلية عبر axum::middleware::from_fn لمعرف الطلب والمصادقة ورؤوس الأمان. هذا هو بالضبط نموذج التركيب الذي يسلط الضوء عليه ملف README الخاص بـ Axum: يتم تجميع البرامج الوسيطة للبرج واختبارها وإعادة استخدامها بشكل مستقل عن بقية جهاز التوجيه.

المصادر: واجهة برمجة تطبيقات crates.io (/api/v1/crates/axum, /api/v1/crates/actix-web) وواجهة برمجة تطبيقات GitHub، تم الوصول إليها في 23 أغسطس 2026. القراءات الرسمية tokio-rs/axum وactix/actix-web للباقي.

تبدأ واجهة Rust الخلفية المعيارية ومتعددة الخدمات. يعد Axum مناسبًا بشكل طبيعي - حيث تسهل تركيبة Tower الخاصة به مشاركة البرامج الوسيطة بين الخدمات، كما تفعل Aurabase بين خدمات HTTP العشرة.

لديك قاعدة أكواد Actix-web موجودة وعاملة. ليس هناك اندفاع للهجرة. تظل Actix-web تتم صيانتها بشكل نشط وتغطي HTTP/2 وWebSockets والضغط محليًا، دون تبعيات إضافية.

أنت تريد تسليم أكبر قدر ممكن من وظائف HTTP في صندوق واحد، دون تجميع tower-http بنفسك. يستجيب Actix-web مباشرة لهذه الحاجة.

أنت بالفعل تشارك البرامج الوسيطة لـ Tower مع خدمات Hyper أو Tonic (gRPC) الأخرى. يعيد Axum استخدام هذه الطبقات كما هي – وهذه هي الحجة التي تم وزنها في Aurabase.