Lovable ने डेटा अनुमतियों को एक जगह प्रबंधित करने वाली रीयल-टाइम सेवा बनाई

Lovable ने 9 नवंबर 2026 को बताया कि Lovable Realtime की पूर्ण तैनाती के साथ उसका फ्रंटएंड Firestore से हट गया है। यह कस्टम सेवा प्राधिकरण को एक जगह प्रबंधित करती है और 30 दिनों की मापन अवधि के दौरान एक समय में अधिकतम 2.06 मिलियन समवर्ती सब्सक्रिप्शन तक पहुँची।

इस माइग्रेशन से पहुँच और दिखाई देने वाले फ़ील्ड से जुड़े निर्णय Lovable के Go बैकएंड में लिए जाते हैं। कंपनी के AI ऐप-निर्माण प्लेटफ़ॉर्म के लिए, यह सेवा Firestore और Spanner के डेटा को एक साथ इस्तेमाल करने और अंतर्निहित जानकारी या उपयोगकर्ता की अनुमतियों में बदलाव होने पर उसकी स्क्रीन पर दिखने वाले डेटा को अपडेट करने का एक तरीका देती है।

अनुमतियों और लाइव डेटा का केंद्रीकरण

Lovable के कुछ हिस्से पहले ब्राउज़र-आधारित Firestore का इस्तेमाल करते थे onSnapshot लिसनरों का इस्तेमाल करते थे। ब्राउज़र को पूरे दस्तावेज़ मिलते थे, जबकि Firestore के नियमों को Go API के अनुमति मॉडल के अनुरूप रखना पड़ता था। इस व्यवस्था में दस्तावेज़ों में होने वाले सामान्य बदलावों के साथ डेटा का खुलासा होने का जोखिम भी जुड़ा था: कोई व्यक्ति फ़ील्ड जोड़कर यह तय कर सकता था कि उपयोगकर्ताओं के ब्राउज़र तक कौन-सा डेटा पहुँचेगा, और उसे इस नतीजे का एहसास भी शायद न हो।

Firestore के नियम Firebase डेटा पर क्वेरी कर सकते हैं, लेकिन Spanner पर नहीं। इससे उन बड़े उद्यमी समूहों के लिए प्राधिकरण अपडेट करना मुश्किल होता है जिन्हें SCIM के ज़रिए सिंक किया जाता है। SCIM, उपयोगकर्ताओं और समूहों को Lovable वर्कस्पेस में सिंक करता है। बिज़नेस और एंटरप्राइज़ ग्राहकों के लिए Go API के ज़रिए बनाई गई एक अस्थायी प्रॉक्सी ने API की अनुमति-जाँचों का फिर से इस्तेमाल किया। इसने हर क्लाइंट की निर्भरताओं के लिए अलग-अलग अपस्ट्रीम Firestore लिसनर भी खोले, जिससे डेटा स्ट्रीम दोहराई गईं और उस कनेक्शन पूल की क्षमता खर्च हुई जिसे सामान्य डेटाबेस अनुरोधों के साथ साझा किया जाता है।

Lovable चाहता था कि नया समाधान दोनों मौजूदा डेटाबेस के साथ काम करे, लगातार पहुँच की फिर से जाँच करे और किसी उपयोगकर्ता की अनुमति रद्द होने पर सत्र के बीच में ही उसकी स्ट्रीम बंद कर दे। कंपनी यह भी चाहती थी कि अनधिकृत फ़ील्ड सर्वर से कोई भी डेटा बाहर जाने से पहले ही रोक दिए जाएँ। कंपनी के आकलन के मुताबिक, जिन ट्रांसपोर्ट, सिंक्रनाइज़ेशन और डेटाबेस-एकीकृत विकल्पों का उसने मूल्यांकन किया, उनमें से कोई भी पर्याप्त एकीकरण कार्य, डेटाबेस बदलने या डेटा को Postgres में दोहराने के बिना इन सभी ज़रूरतों को पूरा नहीं करता था।

तैयार Go सेवा GKE पर चलती है और हर ब्राउज़र टैब के लिए एक WebSocket खोलती है; उसी कनेक्शन पर कई सब्सक्रिप्शन एक साथ चलाए जाते हैं। चेंज-डेटा-कैप्चर फ़ीड, Firestore और Spanner में हुए बदलावों को एक ब्रिज के ज़रिए सेवा के मैसेज बस NATS तक पहुँचाती हैं। मेल खाने वाले सब्सक्रिप्शन अपने दृश्य फिर से तैयार करते हैं, xxh3-128 हैश की तुलना करते हैं और आउटपुट बदलने पर ही अंतर भेजते हैं। एक सब्सक्रिप्शन दोनों डेटाबेस से डेटा ले सकता है और साथ ही API का अनुमति ढाँचा लागू कर सकता है।

प्राधिकरण को एक अन्य प्रतिक्रियाशील डेटा स्रोत माना जाता है, जिससे अनुमति में बदलाव सामान्य दस्तावेज़ संपादन से अलग, नए नतीजे पाने की प्रक्रिया शुरू कर सकते हैं। Lovable ने बताया कि हर संबंधित दस्तावेज़ अपडेट पर दोबारा गणना करने के बजाय, केवल पहुँच के निर्णयों में शामिल फ़ील्ड बदलने पर गणना करने से अनुमतियों की पुनर्गणना में लगभग 84% की कमी आई। इस सेवा में सब्सक्रिप्शन के लगभग 40 प्रकार हैं, जिनका स्वामित्व सात टीमों के पास है। इसमें टाइपयुक्त इंटरफ़ेस, साझा सर्वर-साइड सब्सक्रिप्शन और संबंधित टीमों तक पहुँचाए जाने वाले अलर्ट शामिल हैं।

शैडो ट्रैफ़िक से रोलआउट की पुष्टि

Lovable ने पहले सेवा को शैडो मोड में चलाया: फ्रंटएंड ने नया पूरा पथ इस्तेमाल किया, लेकिन उसके पेलोड छोड़ दिए और Firestore से रेंडर करना जारी रखा। वास्तविक ट्रैफ़िक और डेटा संरचनाओं के इस्तेमाल से तैनाती के बाद बार-बार कनेक्शन जुड़ने की समस्या, त्रुटियों का गलत वर्गीकरण और वास्तविक डेटा के लिए बहुत छोटी पेलोड सीमा सामने आई। इसके बाद फ़ीचर फ़्लैग के ज़रिए कई दिनों में उपलब्धता को उपयोगकर्ताओं के 1% से बढ़ाकर 10%, 50% और फिर 100% तक किया गया। Lovable ने कहा कि इस रोलआउट के दौरान उपयोगकर्ताओं को दिखने वाली कोई घटना नहीं हुई और निगरानी वाले मेट्रिक्स में कोई गिरावट नहीं आई।

WebSocket कनेक्शन एक ही सर्वर से जुड़े रहते हैं और कई घंटे तक चल सकते हैं, इसलिए केवल पॉड बढ़ाने से मौजूदा लोड अपने आप दूसरी जगह नहीं जाता। Lovable कनेक्शनों की संख्या के आधार पर लोड बाँटता है, CPU और मेमोरी के साथ-साथ कनेक्शनों का उपयोग करके स्केल करता है और दोबारा कनेक्शन बनाने की लहरों को सीमित करने के लिए हर पॉड पर कनेक्शनों की अधिकतम संख्या तय करता है। दोबारा कनेक्ट होने के बाद क्लाइंट अपने कैश किए गए डेटा का फ़िंगरप्रिंट भेजते हैं। इससे सर्वर प्राधिकरण की फिर से जाँच करके पुष्टि कर सकता है कि डेटा में बदलाव नहीं हुआ है और उसे दोबारा भेजने की ज़रूरत नहीं है।

पोस्ट के लेखक ने कहा कि मुख्य सेवा बनाने में 40 दिन का व्यावहारिक काम लगा और आर्किटेक्चर तथा जटिल किनारी स्थितियों पर विचार कर लेने के बाद, अधिकांश कार्यान्वयन कोडिंग एजेंटों ने किया। एकीकरण परीक्षण व्यवस्था में Firestore, Auth और Spanner एमुलेटर, एम्बेडेड NATS सर्वर और वास्तविक एमुलेटर से बनाए गए ID टोकन शामिल थे। इससे एजेंटों को पूरे स्टैक में बदलावों का परीक्षण करने की सुविधा मिली।

उत्पादन के नतीजे और ऐप्स के लिए संभावित सहायता

5 सितंबर से 5 अक्टूबर 2026 की अवधि के लिए, Lovable ने 2.61 अरब डेटा और पैच फ़्रेम दर्ज किए। इसमें फिर से शुरू किए गए कंट्रोल फ़्रेम शामिल नहीं हैं। कंपनी का अनुमान था कि हर गणना किए गए नतीजे के लिए पूरा स्नैपशॉट भेजने पर ऐप्लिकेशन पेलोड 40 TB होता। डुप्लिकेशन हटाने, अंतर भेजने और दोबारा कनेक्शन पर कैश का फिर से इस्तेमाल करने से वास्तव में भेजा गया पेलोड 1.11 TB रहा, जो उस आधार-स्तर से अनुमानित 97% की कमी है। पेलोड के आँकड़ों में प्रोटोकॉल और ट्रांसपोर्ट का अतिरिक्त डेटा शामिल नहीं है।

Lovable ने स्रोत डेटाबेस में लिखे जाने से लेकर आउटगोइंग फ़्रेम भेजने के लिए तैयार होने तक का अंतराल p50 पर 66 मिलीसेकंड और p99 पर 249 मिलीसेकंड मापा। इन मापों में सॉकेट पर लिखने, नेटवर्क में लगने वाले समय और क्लाइंट की प्रोसेसिंग का समय शामिल नहीं है, इसलिए ये उपयोगकर्ता को महसूस होने वाले अपडेट के पूरे समय को नहीं दर्शाते।

Lovable ने कहा कि वह उन मामलों के लिए डोमेन-इवेंट के मूलभूत घटक सक्रिय रूप से जोड़ रहा है, जहाँ डेटा का उपयोग करने वालों को डेटा स्नैपशॉट के बजाय किसी घटना के घटित होने की सूचना चाहिए। उसने यह भी कहा कि आगे चलकर यह सेवा Lovable से बनाए गए ऐप्स के भीतर एक सुविधा बन सकती है। ऐसा विस्तार ग्राहकों द्वारा बनाए गए ऐप्लिकेशनों में बैकएंड-नियंत्रित अनुमतियाँ और लाइव दृश्य उपलब्ध कराएगा। मौजूदा परिनियोजन पहले से ही Lovable की टीमों को साझा आधार प्रदान करता है, जिससे उनका डेटा इन्फ्रास्ट्रक्चर विकसित होने के साथ वे अधिक सहयोग कर सकें।