برمجة تطبيق توصيل بـ Flutter وNode.js: دليل هندسي كامل من الفكرة إلى Google Play وApp Store — SHAMCODE Engineering Series

هذا المقال جزء من **SHAMCODE Engineering Series** — سلسلة نشارك فيها المنهجيات الهندسية، قرارات المعمارية، وأنماط العمل التي نعتمدها فعلًا عند بناء منتجات رقمية حديثة. ليست سلسلة تسويقية ولا دروسًا للمبتدئين، بل توثيق لطريقة تفكير فريق هندسي أمام مشكلة حقيقية: كيف نصمّم، نبني، نختبر، وننشر منتجًا يصمد ويتوسّع.

الحلقة السابقة تناولت بناء تطبيق تعليمي احترافي. في هذه الحلقة نأخذ أحد أصعب أنواع التطبيقات هندسيًا: **تطبيق التوصيل**. المقال مكتوب لجمهور مزدوج — مؤسّس أو مدير منتج يريد فهم القرارات وأثرها، ومهندس أو Tech Lead يريد رؤية التفاصيل المعمارية. كل قسم يشرح *لماذا* نتّخذ القرار، لا *ماذا* نستخدم فقط.

الدليل طويل بحكم شموله. إليك المحاور للوصول السريع:

1. لماذا تطبيقات التوصيل من أصعب المنتجات؟

2. تحليل الأعمال — الأطراف الأربعة وقواعد العمل.

3. اكتشاف المنتج وتحديد الـ MVP.

4. تصميم تجربة المستخدم للأطراف الأربعة.

5. معمارية النظام الكاملة (مع مخططات).

6. لماذا Flutter؟ ولماذا Node.js؟

7. تصميم قاعدة البيانات.

8. الخرائط والتتبّع اللحظي.

9. ميزات الزمن الحقيقي عبر Socket.io.

10. الأمان، الاختبار، النشر على المتجرين، والصيانة.

11. عشرة دروس هندسية + الخاتمة + 25 سؤالًا.

للسياق التجاري (الأسعار والمراحل) راجع مقالنا المكمّل تكلفة تطبيق توصيل في سوريا؛ هذا المقال يركّز على *الهندسة*.

التحدي ليس في عدد الشاشات، بل في طبيعة المنظومة. تطبيق التوصيل نظام **موزّع، لحظي، ومتعدّد الأطراف** — وهذه الخصائص الثلاث مجتمعة نادرة في التطبيقات العادية:

**متعدّد الأطراف**: أربعة تطبيقات/واجهات (عميل، سائق، متجر، إدارة) تعمل على نفس البيانات في آنٍ واحد، ويجب أن تبقى متّسقة لحظيًا. تغيير حالة طلب واحد يجب أن ينعكس فورًا لدى الأطراف الأربعة.

**لحظي (Realtime)**: موقع السائق يتحرّك كل ثانية، وحالة الطلب تتغيّر (مقبول → قيد التحضير → في الطريق → سُلّم)، ويجب أن يرى الجميع التحديث دون تحديث يدوي.

**حسّاس للموقع (Location-heavy)**: حساب المسافات، تقدير وقت الوصول، توزيع الطلب على أقرب سائق، ورسم المسار — كلها عمليات جغرافية مستمرة ومكلفة.

**حرج للأداء تحت الحمل**: ساعات الذروة (الغداء، العشاء) تعني قفزة مفاجئة في الطلبات المتزامنة. البنية التي تعمل مع 20 طلبًا قد تنهار مع 2,000 إن لم تُصمّم للتوسّع.

**الخلاصة**: النجاح هنا قرار معماري يُتّخذ قبل الكود. هذا بالضبط ما يجعل التخطيط أهم من البرمجة، وما يفسّر لماذا كثير من مشاريع التوصيل تفشل — راجع أخطاء تؤدي إلى فشل مشاريع تطوير التطبيقات.

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

قواعد العمل (Business Rules) هي المنطق الذي يحوّل التطبيق من واجهة إلى نظام. نوثّقها بوضوح لأنها مصدر معظم التعقيد لاحقًا:

أخطر قرار في مشاريع التوصيل هو محاولة بناء كل شيء دفعة واحدة. نحن نبدأ بتحديد شخصيات المستخدمين (User Personas)، تحليل المنافسين، ثم نحدّد أصغر منتج قابل للإطلاق يثبت النموذج. الجدول يوضّح كيف نفصل الأساسي عن المؤجّل:

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

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

المعمارية هي القرار الذي يحدّد مصير المشروع. نعتمد نظامًا مفصول الطبقات (Clean Architecture) بواجهة REST API وطبقة لحظية عبر Socket.io. هذا المخطّط يوضّح التدفّق الكامل:

         ┌─────────────┐   ┌─────────────┐   ┌─────────────┐   ┌─────────────┐
         │  Customer   │   │   Driver    │   │  Merchant   │   │    Admin    │
         │  (Flutter)  │   │  (Flutter)  │   │  (Flutter)  │   │    (Web)    │
         └──────┬──────┘   └──────┬──────┘   └──────┬──────┘   └──────┬──────┘
                │                 │                 │                 │
                └────────┬────────┴────────┬────────┴────────┬────────┘
                         │  REST API        │  WebSocket      │
                         ▼  (HTTPS/JWT)     ▼  (Socket.io)    │
                 ┌───────────────────────────────────────────────────┐
                 │            Node.js  +  Express  (API Layer)         │
                 │   Controllers → Services → Repositories (Clean)     │
                 └───────┬───────────────┬───────────────┬───────────┘
                         │               │               │
                 ┌───────▼──────┐ ┌──────▼──────┐ ┌──────▼────────┐
                 │  PostgreSQL  │ │    Redis    │ │  Google Maps  │
                 │ (source of   │ │ (cache +    │ │ (routes/ETA/  │
                 │  truth)      │ │  geo/pubsub)│ │  distance)    │
                 └──────────────┘ └─────────────┘ └───────────────┘
                         │               │
                 ┌───────▼──────┐ ┌──────▼──────────┐
                 │  Cloud/S3    │ │ Firebase (FCM)  │
                 │ (images)     │ │ push notif.     │
                 └──────────────┘ └─────────────────┘

بصيغة خطّية: **Flutter → REST API (JWT) → Node.js/Express → PostgreSQL** لمصدر الحقيقة، **Redis** للتخزين المؤقت والاستعلامات الجغرافية وpub/sub، **Socket.io** للحظية، **Google Maps** للمسارات وتقدير الوصول، **Cloud Storage/S3** للصور، و**Firebase Cloud Messaging** للإشعارات. الجدول يشرح مسؤولية كل طبقة وسبب اختيارها:

نفصل الكود إلى طبقات: Controllers (تستقبل الطلب) → Services (منطق العمل) → Repositories (الوصول للبيانات). الفائدة العملية ليست نظرية:

**قابلية الاختبار**: منطق التوزيع والتسعير يُختبر معزولًا عن قاعدة البيانات والشبكة.

**قابلية التبديل**: تغيير مزوّد الخرائط أو التخزين لا يمسّ منطق العمل.

**قابلية التوسّع**: إضافة طرف جديد (مثل تطبيق ويب للعميل) يعيد استخدام نفس الطبقات دون تكرار.

**وضوح المسؤولية**: كل طبقة تعرف دورها، ما يسرّع تطوير فريق كامل بالتوازي دون تضارب.

نبني تطبيقات العميل والسائق والمتجر بـ Flutter لأسباب هندسية واقتصادية:

**تطوير عبر المنصات (Cross-Platform)**: كود واحد لأندرويد وiOS، ما يوفّر 30-40% من الكلفة والوقت — مضروبة في ثلاثة تطبيقات، التوفير كبير. تفاصيل في تطوير تطبيق Flutter في سوريا.

**الأداء**: يترجم إلى كود أصلي ويرسم بمحرّكه الخاص، فيعطي حركة سلسة (60fps) مهمّة لتحديث الخريطة والموقع لحظيًا دون تقطيع.

**Hot Reload**: يسرّع دورة التطوير بشكل كبير — نرى تغييرات الواجهة فورًا، ما يقلّل زمن بناء الشاشات المعقّدة.

**اتّساق الواجهة (UI Consistency)**: نفس التصميم بدقّة على المنصتين، ما يقلّل أخطاء الواجهة ويوحّد التجربة.

**قابلية الصيانة طويلة الأمد**: تعديل واحد ينعكس على المنصتين، ودورة إصدار موحّدة تقلّل الأخطاء والكلفة.

**الفائدة التجارية**: أسرع للسوق، أقل تكلفة، وأسهل صيانة — وهذا حاسم لمشروع بثلاثة تطبيقات.

الخادم هو العقل، ونختار Node.js مع Express لتطبيق توصيل لأسباب تقنية دقيقة:

**نموذج الحلقة الحدثية (Event Loop)**: غير حاجب، فيتعامل بكفاءة مع آلاف الاتصالات المتزامنة التي تنتظر I/O — وهو بالضبط نمط التوصيل (مئات المستخدمين يطلبون ويتتبّعون في آنٍ واحد).

**اللحظية عبر Socket.io**: Node.js بيئة طبيعية للـ WebSockets؛ تحديث موقع السائق وحالة الطلب للأطراف الأربعة يتم بكفاءة عالية.

**التوسّع (Scalability)**: خادم عديم الحالة (Stateless) يُستنسخ أفقيًا خلف موازِن حمل، مع Redis لمشاركة الحالة اللحظية بين النسخ — أساس تحمّل ذروات الطلب.

**REST APIs والمصادقة**: بيئة ناضجة لبناء واجهات نظيفة مع JWT وصلاحيات الأدوار (عميل/سائق/متجر/إدارة).

**المهام الخلفية (Background Jobs)**: إرسال إشعارات، معالجة صور، وتقارير — تُنفَّذ في طوابير منفصلة دون تعطيل الطلبات.

الجدول يوائم بين احتياج تطبيق التوصيل وقدرة Node.js:

نستخدم PostgreSQL لقوّتها العلائقية ودعمها الجغرافي (PostGIS). دون الدخول في SQL، هذه الكيانات الأساسية وعلاقاتها في تطبيق توصيل:

قلب النظام هو انتقالات حالة الطلب. نوثّقها كآلة حالات (State Machine) صريحة لأن أي غموض هنا يسبّب أخطاء خطيرة (طلب عالق، سائق مزدوج). هذا المخطّط:

  [PLACED] ──▶ [ACCEPTED] ──▶ [PREPARING] ──▶ [READY]
     │             │  (المتجر)       (المتجر)        │
     │ (العميل)     ▼                                ▼
     │        [CANCELLED]                    [DRIVER_ASSIGNED]
     │             ▲                                │  (التوزيع)
     └─────────────┘                                ▼
                                            [PICKED_UP] ──▶ [ON_THE_WAY]
                                                                 │ (السائق)
                                                                 ▼
                                                            [DELIVERED]

كل انتقال يُسجّل في `Order_Status_History` مع الوقت والفاعل، ويُبثّ لحظيًا للأطراف المعنيّة. هذا السجلّ أساسي للتقارير وحلّ النزاعات ولا يُهمَل.

الخرائط هي المكوّن الأصعب والأكثر تأثيرًا على التكلفة التشغيلية. نستخدم Google Maps Platform بحكمة لأن استدعاءاته مدفوعة:

**تحديد المواقع (GPS)**: تطبيق السائق يرسل موقعه دوريًا. التردّد قرار حسّاس: عالٍ جدًا يستنزف البطارية والبيانات، منخفض جدًا يجعل التتبّع متقطّعًا. نوازن (مثلًا كل 3-5 ثوانٍ أثناء التوصيل فقط).

**التتبّع الحيّ (Live Tracking)**: موقع السائق يُبثّ عبر Socket.io للعميل، لا عبر استدعاء الخريطة المدفوع لكل تحديث — نفصل بين *مصدر الموقع* (GPS السائق) و*عرض الخريطة* (SDK) لتقليل التكلفة.

**تحسين المسار وتقدير الوصول**: نستخدم Directions وDistance Matrix لحساب المسار وETA، ونخزّن النتائج مؤقتًا في Redis لتقليل الاستدعاءات المكرّرة لنفس المسار.

**تحسين البطارية**: نرفع تردّد التحديث فقط أثناء وجود طلب نشط، ونخفضه عند الخمول — قرار يوازن بين دقّة التتبّع وعمر بطارية السائق (الذي يعمل ساعات طويلة).

**الخصوصية**: موقع السائق يُشارَك فقط أثناء الطلب النشط ومع العميل المعني، ويُوقف بعد التسليم — قرار أمان وخصوصية لا رفاهية.

اللحظية هي ما يجعل التوصيل يشعر بأنه "حيّ". نبنيها على Socket.io فوق Node.js، مع Redis كوسيط pub/sub بين نسخ الخادم المتعددة. هذا مخطّط تدفّق التتبّع:

  Driver App ──(location every 3-5s)──▶ Socket.io Server ──▶ Redis Pub/Sub
                                              │                    │
                                              │            (fan-out to nodes)
                                              ▼                    ▼
                                     Customer App  ◀── broadcast ── Server N
                                     (live marker moves on map)

**قنوات الأحداث الرئيسية**: تحديث موقع السائق، تغيّر حالة الطلب، إسناد طلب جديد لسائق، ورسائل الدعم. كل حدث يُبثّ فقط للأطراف المعنيّة (Rooms) لا للجميع.

**استعادة الاتصال (Connection Recovery)**: الشبكات تتقطّع. نصمّم إعادة اتصال تلقائية مع إعادة مزامنة الحالة عند العودة، بحيث لا يفقد العميل تتبّعه لمجرّد انقطاع لحظي.

**التعامل مع عدم الاتصال (Offline Handling)**: تطبيق السائق يخزّن التحديثات محليًا عند انقطاع الشبكة ويرسلها دفعةً عند العودة، فلا يضيع تسلسل الأحداث.

**لماذا لا نكتفي بـ REST؟** لأن استطلاع الخادم المتكرّر (Polling) مكلف وبطيء ويستنزف البطارية. WebSocket يدفع التحديث فور حدوثه — الفرق بين تتبّع حقيقي ووهم تتبّع.

تطبيق التوصيل يتعامل مع مواقع، مدفوعات، وبيانات شخصية — الأمان فيه قرار معماري مستمر نتّبع فيه OWASP Mobile Security:

لا نطلق نظامًا موزّعًا دون كسره أولًا. نعتمد طبقات اختبار متكاملة لأن كل نوع يكشف فئة مختلفة من الأعطال:

النشر عملية دقيقة، ولتطبيق توصيل بثلاثة تطبيقات تتضاعف. الخطوات عبر Google Play Console:

**1. بناء Flutter**: نبني إصدار إنتاج مُحسّنًا (`flutter build appbundle`).

**2. Android App Bundle (.aab)**: بدل APK، ليولّد جوجل نسخًا محسّنة لكل جهاز ويقلّل حجم التنزيل.

**3. توقيع التطبيق (Signing)**: عبر Play App Signing؛ فقدان المفتاح يعني فقدان القدرة على التحديث نهائيًا.

**4. Store Listing**: عنوان، وصف، أيقونة، لقطات لكل تطبيق (عميل/سائق/متجر).

**5. سياسة الخصوصية ونموذج Data Safety**: إلزامية، خصوصًا لتطبيق يجمع مواقع ومدفوعات.

**6. اختبارات ما قبل النشر**: مسارات مغلقة/مفتوحة مع مستخدمين حقيقيين قبل الإطلاق العام.

**7. الإصدار الإنتاجي والمراقبة**: نشر تدريجي (Staged Rollout) مع مراقبة الأعطال قبل الوصول للجميع.

هذا خط أنابيب النشر المبسّط:

  Code ──▶ CI (test+lint) ──▶ flutter build appbundle ──▶ sign
                                                            │
   Monitoring ◀── Production ◀── Staged Rollout ◀── Play Review

نشر iOS أكثر صرامة. الخطوات عبر Apple Developer وApp Store Connect:

**1. حساب Apple Developer**: اشتراك سنوي مدفوع، شرط لأي نشر.

**2. الشهادات وملفات التزويد (Certificates & Provisioning Profiles)**: منظومة Apple للتوقيع؛ إعدادها الصحيح شرط للبناء، وأخطاؤها من أكثر ما يعطّل المطوّرين.

**3. App Store Connect**: إدارة التطبيق، البيانات، والأسعار.

**4. TestFlight**: توزيع نسخة تجريبية على مختبرين حقيقيين قبل التقديم.

**5. المراجعة (Review Guidelines)**: بشرية ودقيقة (24-48 ساعة عادةً)، تفحص الوظائف والخصوصية والالتزام.

**6. أسباب الرفض الشائعة**: بيانات خصوصية ناقصة، أذونات موقع غير مبرّرة بوضوح، ميزات معطّلة، أو غياب Apple Sign In عند وجود تسجيل اجتماعي آخر — نلتزم بها لتجنّب الرفض.

**7. تحديثات الإصدارات**: كل تحديث يمرّ بالمراجعة، لذا نخطّط دورات الإصدار بما يراعي زمنها.

الإطلاق بداية. النظام الموزّع يحتاج مراقبة دائمة وتطويرًا مستمرًا:

**تتبّع الأعطال (Firebase Crashlytics)**: رصد الأعطال لحظيًا مع تفاصيلها لإصلاحها قبل تفاقم الشكاوى.

**المراقبة (Monitoring)**: صحّة الخادم، زمن الاستجابة، طول طوابير الطلبات، واستهلاك Redis — لكشف المشاكل قبل المستخدم.

**CI/CD**: خطوط أنابيب آلية للاختبار والبناء والنشر، تقلّل الأخطاء البشرية وتسرّع الإصدارات — ضرورية عند إدارة ثلاثة تطبيقات وخادم.

**تحسين الأداء المستمر**: تحليل الاستعلامات البطيئة، ضبط الفهارس الجغرافية، وضبط سياسات Redis مع نمو البيانات.

**إصلاح العلل والتطوير**: دورة إصدار منتظمة تضيف الميزات المؤجّلة (محفظة، كوبونات، توزيع ذكي) بناءً على بيانات الاستخدام الحقيقية.

خلاصة تجربة عملية، لأن الدرس المكتسب يوفّر خطأً مكلفًا:

**1.** التوصيل نظام موزّع لحظي، لا تطبيق بشاشات — صمّمه على هذا الأساس من اليوم الأول.

**2.** آلة حالات الطلب (Order State Machine) يجب أن تكون صريحة وموثّقة — الغموض هنا يسبّب طلبات عالقة.

**3.** افصل *مصدر الموقع* عن *عرض الخريطة* — يوفّر تكلفة استدعاءات Maps بشكل كبير.

**4.** WebSocket لا Polling للّحظية — الفرق في التكلفة والبطارية والتجربة هائل.

**5.** Redis ليس رفاهية — التوزيع الجغرافي ومشاركة الحالة بين النسخ يعتمدان عليه.

**6.** صمّم لذروة الطلب لا لمتوسّطه — البنية تُختبر وقت الغداء والعشاء لا في الهدوء.

**7.** بطارية السائق قيد تصميمي — وازن تردّد تحديث الموقع بعناية.

**8.** خصوصية الموقع قرار معماري — شارك أثناء الطلب فقط.

**9.** أتمِت النشر (CI/CD) مبكرًا — إدارة ثلاثة تطبيقات يدويًا وصفة للأخطاء.

**10.** البنية القابلة للتوسّع تكلّف أكثر قليلًا الآن وتوفّر إعادة بناء كاملة لاحقًا. لتقدير الميزانية راجع كم تكلفة إنشاء تطبيق في سوريا وكم يستغرق تطوير تطبيق جوال.