تطوّر Lovable خدمة آنية لتوحيد أذونات البيانات

أفادت Lovable في 9 نوفمبر 2026 بأن واجهتها الأمامية انتقلت من Firestore مع النشر الكامل لخدمة Lovable Realtime، وهي خدمة مخصصة توحّد إدارة التفويض، وبلغت ذروة الاشتراكات المتزامنة فيها 2.06 مليون خلال فترة قياس مدتها 30 يومًا.

تنقل هذه الهجرة قرارات الوصول والحقول الظاهرة إلى الواجهة الخلفية لـ Go لدى Lovable. وبالنسبة إلى منصة الشركة لإنشاء التطبيقات بالذكاء الاصطناعي، تتيح الخدمة طريقة واحدة للجمع بين بيانات Firestore وSpanner، وتحديث ما يراه المستخدم عند تغيّر المعلومات الأساسية أو أذوناته.

توحيد الأذونات والبيانات المباشرة

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

يمكن لقواعد Firestore الاستعلام عن بيانات Firebase، لكن ليس عن Spanner، ما يشكل عقبة أمام تحديثات التفويض التي تؤثر في مجموعات مؤسسية كبيرة تتم مزامنتها عبر SCIM، الذي يزامن المستخدمين والمجموعات مع مساحة عمل في Lovable. وأعاد وكيل مؤقت عبر واجهة Go البرمجية، مخصص لعملاء الأعمال والمؤسسات، استخدام عمليات التحقق من الأذونات في الواجهة البرمجية. كما فتح مستمعي Firestore منفصلين في المصدر لكل عميل من أجل تبعياته، ما أدى إلى تكرار التدفقات واستهلاك سعة من مجموعة اتصالات مشتركة مع طلبات قاعدة البيانات العادية.

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

تعمل خدمة Go الناتجة على GKE، وتفتح اتصال WebSocket واحدًا لكل علامة تبويب في المتصفح، مع تعدد إرسال الاشتراكات عبر ذلك الاتصال. وتنقل تدفقات التقاط تغييرات البيانات تغييرات Firestore وSpanner عبر جسر إلى NATS، حافلة الرسائل الخاصة بالخدمة. وتعمد الاشتراكات المطابقة إلى إعادة احتساب طرق عرضها، ومقارنة تجزئات xxh3-128، وإرسال الفروق فقط عند تغيّر المخرجات. ويمكن لاشتراك واحد استقاء البيانات من كلتا قاعدتي البيانات مع تطبيق إطار الأذونات الخاص بواجهة برمجة التطبيقات.

يُتعامل مع التفويض بوصفه مصدرًا تفاعليًا آخر للبيانات، ما يتيح لتغييرات الأذونات استثارة نتائج جديدة بمعزل عن التعديلات العادية على المستندات. وأفادت Lovable بأن إعادة الاحتساب فقط عند تغيّر الحقول الداخلة في قرارات الوصول، بدلًا من إجرائها عند كل تحديث ذي صلة بالمستندات، خفّضت عمليات إعادة احتساب الأذونات بنحو 84%. وتضم الخدمة نحو 40 نوعًا من الاشتراكات تديرها سبعة فرق، مع واجهات محددة الأنواع واشتراكات مشتركة على جانب الخادم وتنبيهات موجّهة إلى الفرق.

التحقق من الإطلاق عبر حركة مرور ظلّية

شغّلت Lovable الخدمة أولًا في وضع الظل: إذ استخدمت الواجهة الأمامية المسار الجديد كاملًا، لكنها أهملت حمولاته وواصلت عرض البيانات من Firestore. وكشف استخدام حركة المرور الفعلية وأشكال البيانات الحقيقية عن موجات متكررة من إعادة الاتصال بعد عمليات النشر، وأخطاء صُنفت على نحو خاطئ، وحد أقصى للحمولة كان صغيرًا جدًا للبيانات الفعلية. ثم رفع مفتاح ميزة الإتاحة تدريجيًا من 1% إلى 10%، ثم 50%، وصولًا إلى 100% من المستخدمين على مدى عدة أيام. وقالت Lovable إن الإطلاق لم يسفر عن أي حادثة ظاهرة للمستخدمين، ولم يتسبب في أي تراجع في المقاييس التي تراقبها.

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

ذكر كاتب المنشور أن بناء النواة استغرق 40 يوم عمل فعلي، وأن وكلاء البرمجة تولوا معظم التنفيذ بعد استكمال العمل على البنية المعمارية والحالات الحدّية. وجمع نظام اختبار التكامل بين محاكيات Firestore وAuth وSpanner، وخادم NATS مضمّن، ورموز ID حقيقية أصدرتها المحاكيات، ما أتاح للوكلاء اختبار التغييرات عبر المكدس الكامل.

نتائج الإنتاج وإمكانية دعم التطبيقات

أفادت Lovable بأنه خلال الفترة من 5 سبتمبر إلى 5 أكتوبر 2026، بلغ عدد إطارات البيانات والتعديلات 2.61 مليار، باستثناء إطارات التحكم المستأنفة، وقدّرت أن إرسال لقطات كاملة لكل نتيجة محتسبة كان سيولد 40 TB من حمولات التطبيق. وخفّض إزالة التكرار وإرسال الفروق وإعادة استخدام البيانات عند الاتصال مجددًا الحمولة الفعلية المرسلة إلى 1.11 TB، أي انخفاضًا مقدرًا بنسبة 97% مقارنة بخط الأساس هذا. ولا تشمل أرقام الحمولات النفقات الإضافية للبروتوكول والنقل.

قاست Lovable الفترة بين كتابة البيانات في قاعدة البيانات المصدرية وجهوزية إطار صادر للإرسال، فبلغت 66 مللي ثانية عند p50 و249 مللي ثانية عند p99. ولا تشمل هذه القياسات عمليات الكتابة عبر المقبس، أو الوقت المستغرق في الشبكة، أو معالجة العميل؛ لذا فهي لا تمثل الزمن الكامل الذي يستغرقه التحديث كما يدركه المستخدم.

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