Lovable, Veri İzinlerini Merkezileştiren Gerçek Zamanlı Bir Hizmet Kuruyor

Lovable, 9 Kasım 2026’da bildirdi: yetkilendirmeyi merkezileştiren özel hizmeti Lovable Realtime’ın tümüyle devreye alınmasıyla ön yüzü Firestore’dan taşındı. Hizmet, 30 günlük ölçüm döneminde eşzamanlı aboneliklerde 2,06 milyonluk zirveye ulaştı.

Bu geçişle erişim ve hangi alanların görünür olacağına ilişkin kararlar Lovable’ın Go arka ucunda alınıyor. Şirketin yapay zekâ destekli uygulama geliştirme platformunda hizmet, Firestore ve Spanner verilerini bir araya getirmenin ve altta yatan bilgiler ya da kullanıcının izinleri değiştiğinde kullanıcının görünümünü güncellemenin tek bir yolunu sunuyor.

İzinleri ve Canlı Verileri Merkezileştirme

Lovable‘ın bazı bölümleri daha önce tarayıcı tabanlı Firestore kullanıyordu onSnapshot dinleyicilerini kullanıyordu. Tarayıcıya belgelerin tamamı gönderilirken Firestore kurallarının Go API’sinin izin modelini yansıtması gerekiyordu. Bu tasarım, verilerin açığa çıkmasını rutin belge değişikliklerinin de bir parçası hâline getiriyordu: Bir alan ekleyen kişi, bunun kullanıcıların tarayıcılarına ne ulaşacağını etkileyeceğini fark etmeyebilirdi.

Firestore kuralları Firebase verilerini sorgulayabiliyor, ancak Spanner verilerini sorgulayamıyordu. Bu durum, kullanıcıları ve grupları bir Lovable çalışma alanıyla eşitleyen SCIM aracılığıyla senkronize edilen büyük kurumsal grupları etkileyen yetkilendirme güncellemelerinin önünde engel oluşturuyordu. İşletme ve kurumsal müşteriler için Go API’si üzerinden kurulan geçici bir proxy, API’nin izin denetimlerini yeniden kullanıyordu. Ayrıca her istemcinin bağımlılıkları için ayrı Firestore dinleyicileri açarak akışları çoğaltıyor ve normal veritabanı istekleriyle paylaşılan bağlantı havuzunun kapasitesini tüketiyordu.

Lovable, yeni çözümün her iki mevcut veritabanıyla da çalışmasını, erişimi sürekli olarak yeniden değerlendirmesini ve erişimi iptal edilen bir kullanıcının akışını oturum devam ederken kapatmasını istiyordu. Ayrıca yetkisiz alanların, herhangi bir veri sunucudan çıkmadan önce ayıklanmasını talep ediyordu. Şirketin değerlendirmesine göre incelediği aktarım, senkronizasyon ve veritabanıyla bütünleşik seçenekler; kapsamlı entegrasyon çalışmaları, veritabanı değişikliği ya da verilerin Postgres’e çoğaltılması olmadan bu bileşimi sunamıyordu.

Ortaya çıkan Go hizmeti GKE üzerinde çalışıyor ve her tarayıcı sekmesi için bir WebSocket bağlantısı açıyor; abonelikler bu bağlantı üzerinden çoklanıyor. Değişiklik verisi yakalama akışları, Firestore ve Spanner’daki değişiklikleri bir köprü üzerinden hizmetin mesajlaşma veri yolu olan NATS’e taşıyor. Eşleşen abonelikler görünümlerini yeniden hesaplıyor, xxh3-128 özetlerini karşılaştırıyor ve yalnızca çıktı değiştiğinde farkları gönderiyor. Tek bir abonelik, API’nin izin çerçevesini uygularken her iki veritabanından da veri alabiliyor.

Yetkilendirme, başka bir reaktif veri kaynağı olarak ele alınıyor; böylece izin değişiklikleri, olağan belge düzenlemelerinden bağımsız olarak yeni sonuçların tetiklenmesini sağlayabiliyor. Lovable, erişim kararlarında kullanılan alanlardan biri değiştiğinde yeniden hesaplama yapmanın, ilgili her belge güncellemesinde hesaplama yapmaya kıyasla izin hesaplamalarını yaklaşık %84 azalttığını bildirdi. Hizmette yedi ekibin sahibi olduğu yaklaşık 40 abonelik türü bulunuyor; ayrıca tür denetimli arayüzler, paylaşılan sunucu tarafı abonelikler ve ekiplere yönlendirilen uyarılar kullanılıyor.

Dağıtım, Gölge Trafikle Doğrulandı

Lovable önce hizmeti gölge modunda çalıştırdı: Ön yüz yeni yolun tamamını kullandı, ancak yükleri yok sayarak Firestore’dan görüntü oluşturmaya devam etti. Gerçek trafik ve veri biçimleriyle yapılan denemeler, dağıtımların ardından yeniden bağlanma fırtınalarını, yanlış sınıflandırılan hataları ve gerçek veriler için fazla küçük kalan bir yük sınırını ortaya çıkardı. Ardından bir özellik bayrağıyla hizmetin kullanılabilirliği birkaç gün içinde kullanıcıların %1’inden %10’una, %50’sine ve %100’üne çıkarıldı. Lovable, dağıtım sırasında kullanıcıları etkileyen hiçbir olay yaşanmadığını ve izlenen ölçümlerde gerileme görülmediğini belirtti.

WebSocket bağlantıları sabit kaldığı ve saatlerce açık olabildiği için yeni pod’lar eklemek mevcut yükü tek başına taşımaz. Lovable, yükü bağlantı sayısına göre dengeliyor; CPU ve belleğin yanı sıra bağlantı sayısını da kullanarak ölçeklendiriyor ve yeniden bağlantı dalgalarını sınırlamak için pod başına bağlantı sayısına üst sınır koyuyor. Yeniden bağlandıktan sonra istemciler önbelleğe alınmış durumlarının parmak izini gönderiyor. Böylece sunucu, yetkilendirmeyi yeniden denetledikten sonra verilerin değişmediğini doğrulayabiliyor ve verileri tekrar göndermesi gerekmiyor.

Yazının yazarı, çekirdek sistemin geliştirilmesinin 40 iş günü fiilî çalışma gerektirdiğini ve mimariyle uç durumlar üzerinde çalışıldıktan sonra uygulamanın büyük bölümünü kodlama ajanlarının üstlendiğini belirtti. Bir entegrasyon test düzeneği; Firestore, Auth ve Spanner emülatörlerini, gömülü bir NATS sunucusunu ve gerçek emülatörler tarafından oluşturulan kimlik belirteçlerini bir araya getirerek ajanların değişiklikleri tüm yığın boyunca sınamasına olanak tanıdı.

Üretim Sonuçları ve Uygulamalara Sunulabilecek Olası Destek

Lovable, 5 Eylül ile 5 Ekim 2026 arasındaki dönemde, devam ettirilen kontrol çerçeveleri hariç 2,61 milyar veri ve yama çerçevesi işlendiğini bildirdi. Hesaplanan her sonuç için tam anlık görüntüler gönderilseydi uygulama yükünün 40 TB olacağını tahmin etti. Tekilleştirme, farkların gönderilmesi ve yeniden bağlantıda önbelleğin yeniden kullanılması sayesinde gönderilen gerçek yük 1,11 TB’a indi; bu, söz konusu başlangıç değerine göre tahmini %97’lik bir azalmaydı. Yük rakamlarına protokol ve aktarım ek yükü dâhil değildir.

Lovable, kaynak veritabanına yazma işlemiyle giden bir çerçevenin gönderilmeye hazır hâle gelmesi arasındaki süreyi p50’de 66 milisaniye, p99’da ise 249 milisaniye olarak ölçtü. Bu ölçümlere soket yazma işlemleri, ağ süresi ve istemci tarafındaki işleme dâhil olmadığından, kullanıcının algıladığı güncelleme süresinin tamamını yansıtmıyor.

Lovable, tüketicilerin bir veri anlık görüntüsü yerine bir olayın gerçekleştiğine dair bildirim alması gereken durumlar için alan olaylarına yönelik temel yapı taşlarını etkin biçimde eklediğini ve hizmetin ileride Lovable ile oluşturulan uygulamaların içinde bir yetenek hâline gelebileceğini söyledi. Böyle bir genişletme, müşterilerin oluşturduğu uygulamalara arka uç tarafından yönetilen izinler ve canlı görünümler kazandırır. Mevcut dağıtım, veri altyapıları geliştikçe Lovable ekiplerine daha kapsamlı iş birliği için şimdiden ortak bir temel sağlıyor.