بعد عام كامل من تشغيل تطبيقات Dioxus Fullstack في بيئة الإنتاج، يشارك مطور خبرته، مؤكداً أن جزء Rust البرمجي أصبح الأكثر استقراراً في عمله. على الجانب الآخر، يشكل التكامل المستمر (CI) التحدي الأكبر، حيث يستغرق بناء الإصدار حوالي 90 دقيقة على خوادم GitHub.
بدأت هذه التجربة في وظيفته السابقة واستمرت مع منتجاته الخاصة، مثل SeggWat، وهي أداة لجمع الملاحظات داخل التطبيقات، و infra.page. تعتمد هذه المنتجات على نفس الحزمة البرمجية (Stack): تطبيق Dioxus 0.7 Fullstack ضمن مساحة عمل Cargo، مكوناً من عدة «Crates» (وحدات برمجية) للواجهة الخلفية والمصادقة والواجهات الرسومية، وكل ذلك يستند إلى قاعدة بيانات PostgreSQL.
«Dioxus»: لغة واحدة لتجربة متكاملة
من أبرز إيجابيات Dioxus Fullstack، حسب المطور، هو استخدام لغة برمجة واحدة، وهي Rust، في كل جوانب التطبيق: من استعلامات قاعدة البيانات إلى قواعد العمل، ووظائف الخادم، وحتى مكونات الواجهة الأمامية. هذا يقلل من التعقيد ويجعل عملية التطوير أكثر سلاسة للمطورين المنفردين.
كما أن مشاركة أنواع البيانات (Types) بين الواجهة الأمامية والخلفية تسهل عملية إعادة هيكلة الكود (Refactoring)، حيث يمكن لأداة «cargo check» اكتشاف جميع الأماكن التي تحتاج إلى تعديل عند تغيير حقل في بنية بيانات معينة، مما يوفر الوقت ويلغي الحاجة إلى تحديث مواصفات OpenAPI أو واجهات TypeScript بشكل منفصل.
بالإضافة إلى ذلك، تفتح Dioxus الباب أمام تطوير تطبيقات لسطح المكتب والأجهزة المحمولة، بما في ذلك iOS، باستخدام نفس نموذج المكونات. ورغم أن منتجاته الحالية لا تتطلب تطبيقات native، فإن هذه الإمكانية كانت عاملاً مهماً في قراره بالاستثمار في Dioxus.
أعباء الكومبايل و«CI»: الثمن الذي يدفعه المطورون
تأتي هذه المزايا مع تحديات، أبرزها أوقات الكومبايل الطويلة. يحتاج لوحة التحكم إلى الكومبايل مرتين: مرة للخادم ومرة لـ WebAssembly (wasm32) للمتصفح. يستغرق بناء WebAssembly وحده حوالي 22 دقيقة على 6 أنوية، ويصل بناء الإصدار الكامل إلى 90 دقيقة على خوادم GitHub ذات النواتين، وتنخفض إلى 40 دقيقة على خادم خاص.
لمواجهة هذه المشكلة، جرب المطور حلولاً مثل التخزين المؤقت باستخدام «Swatinem/rust-cache» واستخدام «mold linker» وتشغيل عمليات البناء والاختبار في خطوة واحدة لإعادة استخدام المخرجات المترجمة. لكن أكبر تحسن جاء من استخدام خادم بناء خاص، مما خفض وقت البناء بشكل كبير، لكنه أضاف مهمة صيانة خادم بناء.
أشار المطور أيضاً إلى أن فلسفة «Rust بالكامل» ليست مطبقة بشكل صارم في جميع الجوانب، حيث اضطر إلى استخدام مكتبات JavaScript مثل Chart.js للرسوم البيانية، و Tailwind للأنماط، مما يعني تضمين «Bun» و«Tailwind CLI» في عملية CI إلى جانب أدوات Rust.
المستقبل: الانتقال إلى «Topcoat»
بناءً على تجربته، قرر المطور أن مشروعه التالي سيستخدم إطار عمل جديد يسمى Topcoat، وهو إطار Fullstack آخر من منظمة «tokio-rs». يتخذ Topcoat نهجاً معاكساً لـ Dioxus، حيث يتم تقديم كل شيء على جانب الخادم، وتكون المكونات وظائف غير متزامنة يمكنها الاستعلام من قاعدة البيانات مباشرة.
للتفاعل، يعتمد Topcoat على تعابير Rust التي يتم تقييمها على الخادم للعرض الأولي وتُترجم أيضاً إلى JavaScript لتشغيل فوري في المتصفح. هذا يلغي الحاجة إلى حزمة WebAssembly أو هدف كومبايل ثانٍ، وهو ما يأمل المطور أن يقلل أوقات الكومبايل بشكل كبير.
ماذا يعني هذا للمطورين؟
تُظهر تجربة هذا المطور أن استخدام Rust كـ Fullstack يوفر فوائد كبيرة من حيث توحيد اللغة وسلامة الأنواع، مما يسهل الصيانة وإعادة الهيكلة. ومع ذلك، تأتي هذه المزايا بتكلفة تتمثل في أوقات الكومبايل الطويلة وتعقيدات إعداد مسارات التكامل المستمر، خاصة عند بناء تطبيقات WebAssembly.
برأينا، يجب على المطورين تقييم متطلبات مشاريعهم بعناية عند اختيار إطار عمل Fullstack قائم على Rust. إذا كان المشروع يتطلب تفاعلية عالية على جانب العميل أو دعمًا للتطبيقات الأصلية (Native apps)، فقد تكون Dioxus خياراً جيداً. أما للمشاريع التي تركز على لوحات التحكم والواجهات التي تعتمد على النماذج والجداول، فقد يكون نهج الخادم أولاً مثل Topcoat أكثر فعالية، خاصة في تقليل أوقات البناء وزيادة إنتاجية المطور.
المصدر: oxidt.com