الدمج لم يكن المشكلة: ماذا حدث لـCRDT في تطبيقات local-first؟

لسنوات، كان الجواب على سؤال «كيف أبني تطبيقًا يعمل بلا إنترنت ويتزامن بذكاء؟» جوابًا واحدًا تقريبًا: CRDT. بنية بيانات أنيقة رياضيًا، تضمن أن نسختين تعدّلتا بشكل مستقل ستلتقيان في النهاية على الحالة نفسها، بلا خادم يحكم ولا تنسيق بينهما. المشكلة أن الصناعة قضت عقدًا في إتقان هذا الحلّ، ثم اكتشفت في 2026 أنها كانت تحلّ المشكلة الخطأ.

انظر إلى محرّكات المزامنة الرابحة اليوم: ElectricSQL تخلّت عن نهجها الأول المبني على CRDT وأعادت البناء من الصفر بنموذج أبسط. Zero يعمل بسلطة الخادم: الخادم يقبل التعديل أو يرفضه. PowerSync يترك لك تنفيذ حلّ التعارض في واجهتك الخلفية. وحتى TanStack DB — الطبقة الأشهر في الواجهة — إعداده الافتراضي هو التراجع بعد تحقّق الخادم، بلا أي دعم مدمج لـCRDT.

ما الذي حدث؟

أولًا: ماذا يعني local-first أصلًا؟

التسمية توحي بأن الموضوع هو «العمل بلا إنترنت»، وهذا أضعف أجزائها. الفكرة الحقيقية أن النسخة الأساسية من بياناتك تعيش على جهازك، والخادم نسخة أخرى تتزامن معها — لا العكس.

الفرق يظهر في السلوك: كل قراءة تأتي من قاعدة بيانات محلّية، فتكون فورية بلا دوّارة تحميل. وكل كتابة تُطبَّق محلّيًا فورًا ثم تُرفَع في الخلفية. النتيجة تطبيق يبدو سريعًا بشكل غير طبيعي حتى مع إنترنت ممتاز — وهذا وليس العمل دون اتصال هو ما يجعل Figma وNotion وLinear تُحسّ بالشكل الذي تُحسّ به.

وفي 2026 خرج هذا النقاش من دائرة المؤتمرات: خصّص مؤتمر FOSDEM لعام 2026 مسارًا كاملًا بعنوان «Local-First، محرّكات المزامنة، وCRDT»، وصار لدى المطوّر خيارات جاهزة للإنتاج بدل مشاريع بحثية.

المفاجأة: CRDT لم يفشل تقنيًا

هنا يجب الإنصاف. CRDT يفي بوعده بدقّة: إذا كانت حالته تشكّل شبكة نصف‑اتحادية (join-semilattice)، وكانت التحديثات رتيبة، ودالة الدمج هي اتحاد الشبكة — فإن التقارب مضمون رياضيًا. لا خلاف على ذلك.

المشكلة أن الوعد نفسه أضيق ممّا افترض الجميع. فأفضل توضيح لها مثال قاسٍ ورد في الأدبيات الأكاديمية: تخيّل عدّادًا مبنيًا كـCRDT، ودالة دمجه تتجاهل مدخلاتها وتعيد صفرًا دائمًا. هذا العدّاد متقارب تمامًا بكل المعايير الرياضية — وهو في الوقت نفسه خطأ محض.

التقارب خاصية رياضية عن تساوي الحالة بين النسخ. أمّا صحّة التطبيق فخاصية أمان عن أي حالة يُسمح لها بالوجود أصلًا. الأولى لا تقول شيئًا عن الثانية.

المشكلة الحقيقية اسمها: القيود

خذ أمثلة يومية من أي تطبيق حقيقي:

• مقعد واحد متبقٍّ في الحجز، وجهازان يحجزانه في اللحظة نفسها وهما غير متصلين.
• رصيد لا يجوز أن ينزل تحت الصفر.
• اسم مستخدم يجب أن يكون فريدًا.
• كمية مخزون لا يجوز أن تصير سالبة.

هذه ليست مشكلات دمج. أي دالة دمج ذكية ستنتج حالة متّسقة بين النسختين — وقد تكون هذه الحالة «مقعد محجوز مرّتين». النسختان تقاربتا بنجاح على وضع غير قانوني.

والسبب بنيوي لا هندسي: قيود مثل التفرّد، وعدم السلبية، وحدود السعة، والتكامل المرجعي لا يمكن التعبير عنها عمومًا بلغة الشبكة الجبرية التي يقوم عليها CRDT. فرضها يتطلّب تنسيقًا، والتنسيق يتطلّب جهة تملك القرار — أي خادمًا.

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

إذن أين انتهى CRDT؟ في المكان الذي يناسبه

هذا ليس نعيًا. CRDT انتقل إلى المجال الذي تكون فيه المشكلة حفظ النية لا فرض القيود: التحرير التشاركي للنصوص والرسم.

حين يكتب اثنان في الفقرة نفسها، لا توجد «قاعدة عمل» تُنتهك. المطلوب أن تبقى تنسيقات النصّ ومواضع المؤشّرات منطقية، وألّا يصدم الناتج المستخدم. وهذا بالضبط ما تجيده مكتبات مثل Yjs وAutomerge، وهو مجال بحثي قائم بذاته (أعمال مثل Peritext تُظهر أن حفظ النية أصعب بكثير من مجرّد دمج البُنى).

القاعدة العملية صارت واضحة:

• بيانات منظّمة (سجلّات، صفوف، طلبات، مخزون) ← محرّك مزامنة بسلطة خادم.
• محتوى تشاركي حرّ (نصّ، لوح رسم، مستند) ← CRDT.

السؤال الجديد: أين يقع حدّ الكتابة؟

بعد أن سقط سؤال «أي خوارزمية دمج أختار؟»، حلّ محلّه سؤال أدقّ: أي جزء من مسار الكتابة تملكه الأداة، وأي جزء تملكه أنت؟ الفروق بين المحرّكات الثلاثة الكبرى كلّها إجابات مختلفة على هذا السؤال:

	نموذج المزامنة	من يحسم التعارض؟	التخزين على الجهاز
ElectricSQL	مزامنة مسار القراءة فقط، فوق النسخ المنطقي لـPostgres وعبر HTTP قابل للتخزين على CDN	أنت — مسار الكتابة كلّه ملكك	SQLite أو PGlite
PowerSync	يقرأ سجلّ WAL في Postgres ويرشّحه بقواعد مزامنة، ثم يدفعه إلى SQLite على الجهاز	أنت، داخل واجهة الخادم، مع طابور رفع دائم	SQLite — يتحمّل جيجابايتات
Zero	مزامنة كاملة في الاتجاهين، والخادم هو المرجع	الخادم يقبل التعديل أو يرفضه	IndexedDB — مئات الميجابايتات عادةً

ملاحظتان عمليّتان: ElectricSQL وPowerSync يفترضان وجود Postgres لديك أصلًا، بينما Zero لا يقيّدك بواجهة خلفية معيّنة. والثلاثة يمكن تبنّيهم تدريجيًا على شاشة واحدة، دون إعادة بناء التطبيق.

إشارات السوق في 2026

الاندماجات تقول شيئًا عن نضج المجال وعن مخاطره في آنٍ واحد:

• في 11 أغسطس 2026، أعلنت Electric انضمامها إلى Databricks، لتلتحق بفريق Neon هناك. الدافع المعلن ليس تطبيقات الويب بل وكلاء الذكاء الاصطناعي: أن تمتلك كل بيئة تنفيذ للوكيل نسخة Postgres محلّية خاصة بها (عبر PGlite، وهو Postgres مترجَم إلى WebAssembly)، ويتكفّل محرّك المزامنة بإبقائها متّسقة مع السجلّ المركزي. تنزيلات PGlite الأسبوعية قفزت من مليون إلى نحو 13 مليون خلال عام.
• وقبلها، استحوذت Supabase على Triplit في 2025.

الوجه الآخر للخبر يستحقّ الانتباه بالقدر نفسه: Electric أعلنت أن ما كان مفتوح المصدر يبقى مفتوحًا، لكن خدمتها المستضافة Electric Cloud تُغلق. هذا هو بالضبط نوع المخاطرة التي يجب أن تحسبها قبل أن تبني عليها.

ما لا تقوله المقالات المتحمّسة

• النضج متفاوت. TanStack DB ما زال في نطاق 0.1.x وصائنوه أنفسهم يصفونه بالتجريبي. اقرأ رقم الإصدار قبل أن تقرأ قائمة المزايا.
• حدود التخزين حقيقية. فارق «مئات الميجابايتات» و«جيجابايتات» ليس تفصيلًا تسويقيًا؛ هو الذي يقرّر هل تزامن كل البيانات أم شريحة منها.
• هجرات المخطّط تصير مشكلة جديدة كليًّا. حين تعيش قاعدة البيانات على أجهزة لا تملكها، لا تستطيع ترقية المخطّط دفعة واحدة، وعليك دعم نسخ قديمة من العميل لفترة.
• مخاطرة المورّد قائمة. التوحّد في السوق يعني أن الأداة التي تختارها اليوم قد تتغيّر ملكيتها أو تُغلق خدمتها المستضافة. فضّل ما تستطيع استضافته بنفسك — ElectricSQL مثلًا مفتوح تحت رخصة Apache 2.0 وقابل للاستضافة الذاتية.
• وأخيرًا: فروق الأداء بين المحرّكات الثلاثة أصغر من أن تحسم قرارك. ملاءمة المعمارية وتجربة التطوير أهمّ من نتائج القياس هنا.

كيف تقرّر عمليًا

1. اسأل أولًا: هل لديك قيود صارمة؟ لو تطبيقك فيه حجز أو رصيد أو تفرّد، فأنت تحتاج سلطة خادم، وانتهى النقاش حول CRDT.
2. حدّد ما يجب أن يعمل دون اتصال فعلًا. غالبًا شاشة أو اثنتان، لا التطبيق كلّه. التبنّي التدريجي هو الطريق.
3. اختر وفق واجهتك الخلفية: Postgres قائم ← ElectricSQL أو PowerSync. تطبيق جوّال أولًا ← PowerSync (SQLite أصلي بلا عبء WebAssembly). ويب تفاعلي وواجهة خلفية حرّة ← Zero.
4. للمحتوى التشاركي الحرّ فقط، أضف Yjs أو Automerge كطبقة منفصلة — لا كبديل عن محرّك المزامنة.
5. جرّب على شاشة واحدة لأسبوعين قبل أي قرار معماري، واحسب في تقديرك تكلفة الهجرات المستقبلية لا تكلفة البناء الأوّل.

أسئلة شائعة

هل معنى هذا أن CRDT صار بلا فائدة؟

لا، والعكس أصحّ في مجاله. CRDT هو الخيار الصحيح حين تكون المشكلة حفظ نيّة المستخدمين في محتوى حرّ — نصّ تشاركي، لوح رسم، مستند يحرّره عشرة في وقت واحد. ما تغيّر هو أنه لم يعد الإجابة الافتراضية للبيانات المنظّمة التي تحكمها قواعد عمل.

هل يعني local-first أن التطبيق يعمل بلا إنترنت فقط؟

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

هل أستطيع تجربته دون إعادة بناء تطبيقي؟

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

الخلاصة

القصة هنا ليست عن أداة هزمت أخرى، بل عن سؤال بحثي دقيق لم يكن هو سؤال المنتج. أثبت CRDT أن النسخ تستطيع التقارب دون تنسيق، وهذا إنجاز حقيقي. لكن التطبيقات لا تسأل «هل ستتقارب النسخ؟» بل «هل الحالة التي تقاربت عليها مسموح بها أصلًا؟» — والإجابة الثانية تحتاج جهة تملك القرار.

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