العودة إلى المشاريع

دراسة مشروع باك إند

واصل فلسطين

ذكاء للمسارات يتعامل مع بيانات تنقل متغيرة واعتماديات خارجية قد تفشل

واصل فلسطين مشروع جامعي جماعي ركز على هندسة الباك إند. يشمل النظام ككل بيانات التنقل والمصادقة والإشراف والتنبيهات والتكاملات الخارجية والتوثيق واختبارات الأداء. تركزت مساهمتي الموثقة على منطق المسارات والتوجيه الخارجي وإعداداته وتوثيق API المرتبط بالمسارات وتدفق تسجيل المستخدم.

المشكلة

صُمم واصل فلسطين كمنصة تنقل تعتمد على الـ API لتقديم معلومات منظمة عن نقاط التفتيش والحوادث والبلاغات المجتمعية والتنبيهات وظروف المسارات. كانت واجهة المستخدم خارج نطاق المساق حتى يركز الفريق على بنية الباك إند والـ APIs ونمذجة البيانات والتكاملات والاعتمادية والأداء.

المشروع ككل — عمل الفريق

بنى الفريق باك إند modular باستخدام NestJS وTypeScript مع REST endpoints بإصدار /api/v1، وTypeORM مع PostgreSQL، ومصادقة JWT، والتحقق عبر DTOs، وتكاملات للطقس والتوجيه، وتوثيق Swagger/OpenAPI، وإعداد عبر Docker.

العمل على نقاط التفتيش والحوادث والبلاغات المجتمعية والإشراف والتنبيهات والاختبارات الأوسع هو جزء من عمل الفريق ككل، ولا أعرضه هنا على أنه عمل نفذته وحدي.

القرار 1 — إبقاء ذكاء المسار في طبقة حساب مستقلة

نفذت ميزة route-mobility كطبقة حساب بدلاً من إنشاء نموذج دائم جديد للمسارات. يمكن أن تبدأ من تقدير مسار خارجي ثم تطبق عوامل خاصة بواصل مثل نمط الرحلة ونقاط التفتيش القريبة والحوادث الموثقة والمناطق المطلوب تجنبها.

السبب: تقدير المسار مشتق من ظروف التنقل الحالية، لذلك حسابه من البيانات الموجودة يفصل الميزة عن مخاوف التخزين. المقابل: البديل المحلي heuristic ولا يدعي دقة خريطة طرق كاملة.

القرار 2 — عزل خدمة التوجيه الخارجية والتعامل الآمن مع فشلها

دمجت OpenRouteService خلف طبقة الـ external API بدلاً من ربط منطق المسارات مباشرة بالمزوّد. يستخدم التكامل إعدادات من متغيرات البيئة ونتائج routes مخزنة مؤقتاً وtimeouts قابلة للإعداد وبديل heuristic محلي عندما تكون الخدمة غير متاحة أو غير مهيأة.

السبب: مزود التوجيه الخارجي قد يكون بطيئاً أو غير متاح أو محدوداً بالحصص. المقابل هو دقة أقل أثناء استخدام البديل، لكن طلب تقدير المسار يستطيع إرجاع نتيجة مفيدة بدلاً من الفشل الكامل.

القرار 3 — التحقق من المدخلات وتوثيق حدود الـ API

يستخدم عمل المسارات DTOs typed مع قيود class-validator للمدخلات الجغرافية إلى جانب validation pipe العام للمشروع. كما ساهمت في توثيق Swagger حول endpoints وDTOs المرتبطة بـ route-mobility حتى تكون توقعات الـ API واضحة في التوثيق المولد.

السبب: رفض المدخلات غير الصالحة قبل وصولها إلى منطق العمل يجعل الخدمة أوضح وأسهل للاختبار. المقابل هو بعض الـ boilerplate في DTOs وdecorators، لكنه يبقي قواعد التحقق وعقد الـ API صريحة.

النتيجة والحدود

يمكن لـ endpoint المسارات الناتج دمج تقدير قيادة خارجي مع عوامل التنقل الخاصة بواصل وشرح العوامل التي أثرت في النتيجة. يحتوي المستودع أيضاً على اختبارات آلية واختبارات أداء k6 على مستوى الفريق، لكنني لا أنسبها إلى نفسي بشكل فردي.

البديل الخاص بالمسارات heuristic بشكل مقصود، ويُعرض المشروع كدليل على هندسة باك إند جامعية وليس كخدمة ملاحة جاهزة للإنتاج.