Lovable تنقل التحديثات إلى خادمها وتخفض حجم البيانات بنحو 97%

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

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

ماذا يحدث بعد سحب صلاحية الوصول؟

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

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

أفاد هذا النهج خصوصاً في مجموعات المؤسسات، إذ كانت المعلومات المطلوبة موزعة بين قاعدتي بيانات، Firestore وSpanner. ولم يكن بإمكان قواعد أمان Firestore قراءة Spanner. وأتاحت طبقة الخادم الخاصة دمج بيانات القاعدتين في استجابة واحدة وتطبيق نظام الأذونات الموحد الخاص بواجهة API.

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

كيف تصل التحديثات إلى المتصفح؟

تستخدم كل علامة تبويب اتصال WebSocket واحداً يحمل عدة اشتراكات. وتنتقل تغييرات Firestore وSpanner عبر آلية التقاط التغييرات إلى جسر، ثم إلى NATS. وتتلقى الخدمة المكتوبة بلغة Go الحدث وتعيد حساب الاشتراكات المتأثرة.

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

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

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

ما الذي يمكن تطبيقه في منتجك؟

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

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

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