عندما تسبب تحديث بسيط في تعطل تطبيقنا
اكتشفنا خطأً برمجياً. المسارات الرئيسية كانت تعمل بشكل جيد. المسارات العميقة كانت تتسبب في إعادة تحميل الصفحة بالكامل. كان الشريط الجانبي (sidebar) يعاد ضبطه في كل مرة. بدا التطبيق غير مستقر.
كان يعمل محلياً. لكنه فشل في بيئة الإنتاج (production).
استخدمنا Next.js static export على Azure Static Web Apps. هذا الإعداد لا يحتوي على بيئة تشغيل خادم (server runtime). فهو يقوم بتقديم ملفات ثابتة فقط.
كانت المشكلة في التنقل السلس (soft navigation). يحتاج Next.js إلى بيانات حمولة المسار (route payload data) لضمان انتقالات سلسة. ويحتاج إلى HTML عند التحميل الأول.
كانت قواعد إعادة الكتابة (rewrite rules) في Azure واسعة النطاق للغاية. كان Azure يرسل HTML عندما يطلب Next.js بيانات الحمولة (payload data). فشل الموجه (router). وأعيد تحميل التطبيق.
قمنا بإصلاح ذلك باستخدام الأتمتة. قمنا ببناء أداة لإنشاء قواعد إعادة الكتابة من مخرجات البناء (build output). الأداة الآن تقوم بـ:
- فحص ملفات المسارات الديناميكية.
- إنشاء قواعد محددة لملفات HTML والحمولات (payloads).
- ترتيب القواعد حسب الأولوية.
- كتابة ملف الإعدادات النهائي.
أدى ذلك إلى التخلص من الأخطاء اليدوية.
إذا كنت تستخدم static export على Azure:
- قم بأتمتة ملفات الإعدادات الخاصة بك.
- اختبر التنقل السلس (soft navigation).
- تحقق مما إذا كانت طلبات الحمولة (payload requests) تعيد HTML.
- تعامل مع قواعد إعادة الكتابة (rewrite rules) كبنية تحتية حيوية.
غالباً ما تكمن أخطاء الواجهة الأمامية (frontend) الصعبة في الفجوة بين مخرجات البناء وقواعد الاستضافة.