سوريا
لماذا يبني المطورون السوريون تطبيقات offline-first أفضل
واقع الشبكات الذي يجعل المبرمجين السوريين خبراء في بنية offline-first. دروس من الشحن في أسواق اتصال منخفض.
جاري تحميل المقال…
واقع الشبكات الذي يجعل المبرمجين السوريين خبراء في بنية offline-first. دروس من الشحن في أسواق اتصال منخفض.
جاري تحميل المقال…
قضيت تلات سنين ببناء تطبيق محاسبة offline-first للسوق السعودي. التطبيق كان لازم يشتغل بمخازن ريفية بدون تغطية جوّال، بالمصاعد، بالطوابق السفلية، وخلال انقطاعات التيار المتكررة اللي لسّا بتواجه أجزاء من الخليج. الفريق اللي بناه كان مقره سوريا. بآخر المشروع، كنت مقتنع إن المطوّرين السوريين بطبيعتن أحسن ببنية offline-first من مهندسين من أي سوق تاني اشتغلت معو.
هاي ليش.
مهندس Silicon Valley بيتعلم offline-first architecture من محاضرة مؤتمر أو مقال Medium. المبرمج السوري بيتعلمها لأن تطبيقو الخاص بيوقف لما التيار بيقطع، اللي بيصير عدة مرات بالأسبوع. القيد مو نظري. هو شخصي.
هاد بيغيّر طريقة تفكيرن بإدارة الحالة. لما مطوّر Flutter سوري بيصمّم نموذج، ما بيسأل "شو بيصير لما المستخدم بيعمل submit؟" بيسأل "شو بيصير لما المستخدم بيعمل submit والشبكة مختفية؟" وبعدين بيسأل "شو بيصير لما الشبكة بترجع والسيرفر تغيّر؟" وبعدين بيسأل "شو بيصير لما المستخدم بيعمل submit مرتين لأنو ما شاف تأكيد؟"
هالأسئلة بيطلعوا بنية مختلفة. الحالة المحلية بتصير مصدر الحقيقة. السيرفر بيصير هدف للمزامنة. كل عملية بتصير idempotent. هاد مش feature. هو نظرة للعالم.
المنظر الخلوي السوري هو اختبار ضغط لتطبيقات الجوال. في تلات مشغّلين رئيسيين بخرائط تغطية غير متوافقة. التجوال بينن غير موثوق. السعة الدولية بتمر عبر كوابل بحريّة مزدحمة. النتيجة إن هاتف المهندس السوري بيعيش انتقالات شبكة أكتر بيوم واحد من اللي بيعيشها هاتف مهندس أوروبي بشهر.
هاد بيطلع مهندسين بيفهموا الحالات الحافة غريزياً. بيعرفوا إن مؤشر WiFi "متّصل" مو يعني الإنترنت متاح. بيعرفوا إن طلب HTTP ناجح ممكن يرجع بيانات قديمة من cache مشبوك. بيعرفوا إن منطق إعادة المحاولة بدون exponential backoff هو هجوم denial-of-service بانتظار حدوثو.
باستوديونا، منستعمل Drift، wrapper Dart لـ SQLite، للاستمرارية المحلية بتطبيقات Flutter. هي مش الاختيار الأكثر شيوعاً. Hive وIsar أسرع بالإعداد. بس Drift بيعطينا migrations للـ schema، type safety، وSQL خام لما بدنا ياه. هنن الميزات اللي بتفرق لتطبيقات إنتاجية بعمر طويل.
المطوّرين السوريين بيميلوا لأدوات مملة وموثوقة بدل trendy. جزئياً لأن الأدوات العصرية بتتطلّب package managers موثوقة وتوثيق، اللي مش دائماً متاح. وجزئياً لأنن تعرّضوا لـ dependency churn. النتيجة تفضيل لأسس مستقرة: SQLite بدل NoSQL، REST بدل GraphQL، Laravel بدل آخر إطار JavaScript.
أصعب مشكلة ببنية offline-first هي حلّ التعارض. شو بيصير لما جهازين بيعدّلوا نفس السجل وهنن offline؟ الجواب الساذج هو "last write wins." الجواب الصحيح هو "بيختلف حسب منطق العمل، وبدك استراتيجية."
المهندسين السوريين ما بيعاملوا حلّ التعارض كتفكير لاحق. بيعاملوا كمتطلب أساسي. بتطبيق المحاسبة، منستعمل مجموعة من vector clocks، قواعد merge دلالي، وتأكيد صريح من المستخدم للتعارضات عالية المخاطر. هالبنية صمّمها مهندس سوري سبق وخسر بيانات شخصياً بسبب منطق مزامنة ساذج بمشروع سابق.
أحسن اختبار لتطبيق offline-first هو تحطو على Android رخيص، تشغل airplane mode، تستعملو لساعة، وبعدين تطفي airplane mode وتشوف شو بيصير. الفرق السورية بيسووا هاد روتينياً، لأن أجهزتن الشخصية غالباً هي الأندرويد الرخيص.
منستعمل معمل أجهزة بيشمل هواتف معظم المطوّرين الغربيين ما شافوها: Samsung Galaxy J2 بـ 1GB RAM، Xiaomi Redmi 4A بشاشة مكسورة، وiPhone 6S لسّا بيشغّل iOS 15. إذا التطبيق بيشتغل بسلاسة على هالأجهزة، بيشتغل بكل مكان. إذا لا، منعرف قبل العميل.
إذا عم تبني تطبيق لأسواق بنية تحتية ناقصة، اللي هو معظم الأسواق خارج أوروبا الغربية وشرق آسيا، بدك مهندسين ما بيعاملوا وضع offline كحالة حافة. بدك مهندسين بيعاملوا الاتصال كالاستثناء، مو القاعدة.
المطوّرين السوريين internalized هالعقلية من خلال سنين الضرورة. ما بحتاج تقتنعن. ما بحتاج تدرّبن. بدك مواصفات واضحة، دفع موثوق، والحرية يبنوه صح. أعطن التلات أشياء، ورح يشحنو لك تطبيق بيشتغل بأوضاع ما اختبر منافسينك.