عندما نفكر في العمل دون إنترنت، غالبًا نتخيله كحالة طوارئ. الخدمة الأساسية موجودة على الشبكة، وعندما تختفي نحاول تشغيل نسخة محدودة منها. بعض الصفحات تعمل، بعض الملفات تكون مخزنة مؤقتًا، وبعض الوظائف تظهر أمامها رسالة تقول: «حاول مرة أخرى عند عودة الاتصال». هذا أفضل من التوقف الكامل، لكنه ما زال يبني النظام حول افتراض واحد: الإنترنت هو الحالة الطبيعية، وعدم وجوده هو الاستثناء. هناك طريقة أخرى للتفكير في المشكلة. بدل أن نسأل كيف نجعل النظام يعمل قليلًا عندما تختفي الشبكة، يمكن أن نسأل: لماذا يحتاج هذا العمل إلى الشبكة أصلًا في هذه اللحظة؟ ومن هذا السؤال تبدأ فكرة Local-First.
الجهاز المحلي ليس مجرد نافذة إلى السحابة
كثير من التطبيقات الحديثة تتعامل مع الجهاز الذي أمامنا كأنه شاشة جميلة لخدمة موجودة في مكان آخر. تكتب شيئًا، فيُرسل إلى الخادم. تفتح ملفًا، فيتم تحميله. تطلب قائمة مهام، فيتم جلبها من API. وإذا لم يستطع الجهاز الوصول إلى الخادم، تصبح الشاشة فجأة أقل فائدة بكثير. في نهج Local-First يحدث انقلاب صغير في العلاقة. النسخة المحلية من البيانات تصبح قابلة للاستخدام بذاتها. تكتب محليًا. تقرأ محليًا. تعدّل محليًا. والشبكة تُستخدم بعد ذلك للمزامنة وتبادل التغييرات. هذا لا يعني الاستغناء عن الخادم أو السحابة. بل يعني أن الخادم لم يعد يقف بينك وبين عملك في كل نقرة.
الفرق بين Offline Mode وLocal-First
قد يبدو الاثنان متشابهين، لكن بينهما فرق مهم. في Offline Mode يكون لدينا نظام متصل بالإنترنت أضفنا إليه بعض القدرات كي يتحمل الانقطاع. أما في Local-First، فإن العمل المحلي جزء من التصميم الأصلي. الفرق يشبه وجود مولد للطوارئ في مبنى، مقابل تصميم المبنى أصلًا بحيث تكون الأحمال الحرجة مستقلة ويمكنها مواصلة العمل عند تغير مصدر الطاقة. في الحالتين قد تبقى الأنوار مضاءة. لكن في الثانية، الاستمرارية ليست ترقيعًا أضيف لاحقًا. هي جزء من المعمارية.
أبسط مثال: كتابة مستند
افترض أنك تكتب تقريرًا. في نموذج يعتمد على الخادم بشكل كامل، قد يحتاج كل حفظ إلى الاتصال. إذا انقطعت الشبكة، يبدأ التطبيق في إظهار التحذيرات أو يمنع بعض العمليات. في النموذج المحلي أولًا، يحفظ التطبيق التغيير على جهازك مباشرة. أنت تواصل الكتابة. بعد عشر دقائق يعود الإنترنت. عندها يرفع النظام التغييرات الجديدة إلى الخادم. بالنسبة إليك، الانقطاع لم يكن «توقفًا». كان مجرد تأخر في المزامنة. وهذه واحدة من أجمل التحولات الذهنية في Local-First: بدل أن يكون الاتصال شرطًا لتنفيذ العمل، يصبح شرطًا لمشاركة آخر نسخة منه.
ليست كل البيانات بحاجة إلى التصميم نفسه
من الخطأ أيضًا تحويل Local-First إلى عقيدة تقنية. هناك عمليات يجب أن تبقى مرتبطة بالخادم. تحويل أموال. التأكد من مخزون عالمي مشترك. تنفيذ عملية حساسة يجب أن تحدث مرة واحدة فقط. الحصول على معلومة لحظية من مصدر خارجي. هذه الأشياء لا يمكن للجهاز أن يخترع حالتها أثناء الانقطاع. لكن كثيرًا من العمل اليومي مختلف. الملاحظات. المسودات. قوائم المهام. البيانات التي تم تنزيلها مسبقًا. السجلات الميدانية. الاستبيانات. الملفات. التعديلات على مشروع برمجي. كل هذه مرشحة بقوة للعمل محليًا ثم المزامنة لاحقًا. إذن السؤال الصحيح ليس: هل يجب أن يصبح النظام كله Local-First؟ بل: ما العمليات التي لا يوجد سبب حقيقي لجعل الشبكة شرطًا لتنفيذها؟
البيانات المحلية يجب أن تكون حقيقية، لا مجرد Cache
هناك فرق آخر مهم. الـCache عادة نسخة مؤقتة يمكن للنظام حذفها أو إعادة بنائها. أما في Local-First، فالبيانات المحلية قد تحتوي على عمل لم يصل إلى أي مكان آخر بعد. لذلك تحتاج إلى التعامل معها بجدية. يجب أن تعرف أن التغيير محفوظ. ويجب ألا يختفي لأن التطبيق أغلق. ويجب أن تستطيع معرفة ما تم مزامنته وما زال ينتظر. فإذا كتبت عشر ملاحظات أثناء الانقطاع ثم فقدها التطبيق عند إعادة التشغيل، لم نبنِ نظامًا Local-First. بنينا واجهة أعطتنا إحساسًا زائفًا بالأمان.
المزامنة هي الجزء الأصعب
حفظ البيانات محليًا سهل نسبيًا. المشكلة الممتعة تبدأ عندما يكون لدينا أكثر من نسخة. عدّلت ملفًا على الجهاز A. وفي الوقت نفسه عدّله شخص آخر على الجهاز B. ثم عاد الاتصال. أي نسخة هي الصحيحة؟ لا توجد إجابة واحدة تصلح لكل الأنظمة. يمكن أحيانًا استخدام «آخر تعديل يفوز». وفي حالات أخرى نحتاج إلى دمج التغييرات. وفي بعض البيانات نحتاج إلى إظهار تعارض للمستخدم ليختار. وفي أنظمة أكثر تعقيدًا نستخدم تقنيات صممت أصلًا للتعامل مع التحرير المتزامن والموزع. لكن حتى دون الدخول في الرياضيات أو هياكل البيانات، هناك مبدأ مهم: لا تصمم Offline أولًا ثم تؤجل سؤال التعارض إلى النهاية. إذا كان النظام سيعمل على أكثر من جهاز، فإن المزامنة والتعارض جزءان من التصميم منذ البداية.
نقطة الحقيقة قد تكون موزعة
نحن معتادون على مفهوم Single Source of Truth. قاعدة البيانات المركزية هي الحقيقة، وما سواها نسخة. هذا النموذج بسيط ومفيد جدًا في أنظمة كثيرة. لكن Local-First يضطرنا أحيانًا إلى التفكير بطريقة مختلفة. خلال الانقطاع، النسخة الموجودة على الجهاز تحمل حقيقة لم يعرف بها الخادم بعد. بعد المزامنة تصبح هذه الحقيقة جزءًا من الحالة المشتركة. ليس المطلوب إلغاء المصدر المركزي دائمًا، بل الاعتراف بأن النظام قد يعيش لفترة مع عدة حالات صحيحة جزئيًا قبل أن تتصالح. وهذه الفكرة ليست مرتبطة بالإنترنت الضعيف فقط. هي أيضًا أساس مهم لفهم الأنظمة الموزعة.
كيف نطبق الفكرة دون بناء منصة جديدة؟
لا تحتاج إلى إعادة هندسة حياتك الرقمية كلها. يمكن تطبيق التفكير Local-First على العمل الشخصي بأدوات بسيطة جدًا. اجعل المشاريع البرمجية موجودة محليًا بدل الاعتماد على محرر سحابي فقط. نزّل المراجع التي تعمل عليها بدل إعادة فتحها من الإنترنت كل مرة. احتفظ بنسخ محلية من المستندات المهمة. اجعل ملاحظات المشاريع قابلة للقراءة دون شبكة. استخدم أدوات تستطيع تسجيل التغييرات ثم مزامنتها لاحقًا. وتأكد أن بيانات الاعتماد أو التعليمات التي تحتاجها للاستمرار ليست محبوسة بالكامل خلف خدمة تحتاج اتصالًا. الفكرة ليست شراء أداة تحمل كلمة Offline في صفحة التسويق. الفكرة أن تسأل عن كل جزء من سير العمل: ماذا يبقى لدي إذا اختفت الشبكة الآن؟
المزامنة يجب أن تكون مرئية
من أكثر الأشياء إزعاجًا في الأنظمة التي تعمل أحيانًا دون اتصال هو الغموض. هل تم رفع هذا الملف؟ هل هذه هي آخر نسخة؟ هل التغيير محفوظ محليًا فقط؟ هل المزامنة فشلت؟ لا ينبغي للمستخدم أن يحتاج إلى التخمين. النظام المرن يُظهر حالته بوضوح: محفوظ محليًا. بانتظار المزامنة. تمت المزامنة. يوجد تعارض. فشلت العملية وستتم إعادة المحاولة. هذه التفاصيل الصغيرة تبني الثقة. لأن العمل في بيئة متقطعة لا يحتاج فقط إلى القدرة على الاستمرار. يحتاج إلى معرفة أين توجد بياناتك الآن.
Local-First يقلل أيضًا تكلفة الانقطاع الذهنية
الفائدة ليست تقنية فقط. عندما تعرف أنك تستطيع مواصلة الكتابة أو البرمجة أو إدخال البيانات، يتغير شعورك تجاه فقدان الشبكة. لا تعود كل إشارة Wi-Fi مختفية إنذارًا صغيرًا. النظام يستمر. والتغييرات تنتظر. وعندما يعود الاتصال، تحدث المزامنة. هذا يقلل عدد المرات التي تضطر فيها إلى تغيير السياق، وإغلاق المهمة، والبحث عن عمل بديل، ثم العودة إليها لاحقًا. بمعنى آخر، Local-First لا يحمي البيانات فقط. هو يحمي تدفق العمل.
الخلاصة
العمل دون إنترنت ليس بالضرورة نسخة فقيرة من العمل الحقيقي. يمكن أن يكون العمل الحقيقي نفسه، مع تأخر بسيط في مشاركة نتائجه. وهذا هو التحول الذي يقدمه التفكير Local-First. البيانات التي تحتاجها قريبة منك. التغيير يحدث محليًا. العمل لا ينتظر الخادم. وعندما تصبح الشبكة متاحة، تربط النسخ بعضها ببعض من جديد. لا تصلح هذه الفكرة لكل عملية، ولا تلغي الحاجة إلى الخوادم والسحابة. لكنها تقدم سؤالًا تصميميًا شديد القيمة: هل نستخدم الإنترنت لأنه مطلوب فعلًا لهذه العملية، أم لأننا اعتدنا تصميم كل شيء وكأنه موجود دائمًا؟ كل مرة تكون الإجابة فيها الثانية، توجد فرصة لجعل النظام أكثر مرونة. وفي بيئة قد تظهر فيها الشبكة وتختفي، الفرق بين نظام يعتمد على الاتصال ونظام يستخدم الاتصال عند توفره ليس تفصيلًا تقنيًا صغيرًا. إنه الفرق بين أن يتوقف العمل مع الشبكة، وبين أن تقول المنظومة بهدوء: