Η Lovable δημιουργεί υπηρεσία πραγματικού χρόνου για την κεντρική διαχείριση των δικαιωμάτων πρόσβασης στα δεδομένα

Η Lovable ανέφερε στις 9 Νοεμβρίου 2026 ότι, με την πλήρη ανάπτυξη του Lovable Realtime, του προσαρμοσμένου συστήματος που συγκεντρώνει σε ένα σημείο τη διαχείριση των δικαιωμάτων πρόσβασης, το frontend της έπαψε να χρησιμοποιεί το Firestore. Κατά τη διάρκεια μιας περιόδου μέτρησης 30 ημερών, η υπηρεσία έφτασε στο ανώτατο όριο των 2,06 εκατομμυρίων ταυτόχρονων συνδρομών.

Η μετάβαση μεταφέρει τις αποφάσεις σχετικά με την πρόσβαση και τα ορατά πεδία στο backend της Lovable, το οποίο είναι γραμμένο σε Go. Για την πλατφόρμα της εταιρείας, όπου δημιουργούνται εφαρμογές με τεχνητή νοημοσύνη, η υπηρεσία προσφέρει έναν τρόπο συνδυασμού δεδομένων από το Firestore και το Spanner, καθώς και ενημέρωσης της προβολής κάθε χρήστη όταν αλλάζουν είτε τα υποκείμενα δεδομένα είτε τα δικαιώματα πρόσβασης του συγκεκριμένου χρήστη.

Κεντρική διαχείριση δικαιωμάτων πρόσβασης και ζωντανών δεδομένων

Ορισμένα τμήματα του Lovable χρησιμοποιούσαν προηγουμένως το Firestore μέσω του προγράμματος περιήγησης onSnapshot για την ακρόαση ενημερώσεων. Το πρόγραμμα περιήγησης λάμβανε ολόκληρα τα έγγραφα, ενώ οι κανόνες του Firestore έπρεπε να αντικατοπτρίζουν το μοντέλο δικαιωμάτων πρόσβασης του Go API. Με αυτήν τη σχεδίαση, η έκθεση δεδομένων μπορούσε επίσης να προκύψει στο πλαίσιο συνηθισμένων αλλαγών σε έγγραφα: όποιος πρόσθετε ένα πεδίο μπορούσε να καθορίσει τι θα εμφανιζόταν στα προγράμματα περιήγησης των χρηστών, χωρίς κατ’ ανάγκη να αντιληφθεί αυτήν τη συνέπεια.

Οι κανόνες του Firestore μπορούν να υποβάλλουν ερωτήματα σε δεδομένα του Firebase, όχι όμως στο Spanner, γεγονός που δημιουργούσε εμπόδιο για ενημερώσεις εξουσιοδότησης που επηρέαζαν μεγάλες εταιρικές ομάδες και συγχρονίζονταν μέσω SCIM, το οποίο συγχρονίζει χρήστες και ομάδες με έναν χώρο εργασίας της Lovable. Για τους εταιρικούς πελάτες και τις επιχειρήσεις, μια προσωρινή διαμεσολάβηση μέσω του Go API επαναχρησιμοποιούσε τους ελέγχους δικαιωμάτων πρόσβασης του API. Άνοιγε επίσης ξεχωριστούς ακροατές Firestore upstream για τις εξαρτήσεις κάθε πελάτη, με αποτέλεσμα να διπλασιάζονται οι ροές και να καταναλώνεται χωρητικότητα από μια δεξαμενή συνδέσεων που εξυπηρετούσε και τα συνήθη αιτήματα προς τη βάση δεδομένων.

Η Lovable απαιτούσε η αντικατάσταση να λειτουργεί και με τις δύο υφιστάμενες βάσεις δεδομένων, να επανεξετάζει συνεχώς την πρόσβαση και να διακόπτει τη ροή ενός χρήστη του οποίου τα δικαιώματα είχαν ανακληθεί, ακόμη και στη μέση μιας συνεδρίας. Ήθελε επίσης να αποκλείονται τα μη εξουσιοδοτημένα πεδία πριν φύγουν δεδομένα από τον διακομιστή. Η εταιρεία έκρινε ότι οι επιλογές μεταφοράς, συγχρονισμού και ενσωμάτωσης με τη βάση δεδομένων που αξιολόγησε δεν προσέφεραν αυτόν τον συνδυασμό χωρίς εκτεταμένες εργασίες ενσωμάτωσης, αλλαγή βάσης δεδομένων ή αναπαραγωγή των δεδομένων σε Postgres.

Η υπηρεσία Go που προέκυψε εκτελείται στο GKE και ανοίγει ένα WebSocket για κάθε καρτέλα του προγράμματος περιήγησης, με τις συνδρομές να πολυπλέκονται μέσω αυτής της σύνδεσης. Οι ροές καταγραφής αλλαγών μεταφέρουν τις αλλαγές του Firestore και του Spanner μέσω μιας γέφυρας στο NATS, τον δίαυλο μηνυμάτων της υπηρεσίας. Οι συνδρομές που αντιστοιχούν στα σχετικά δεδομένα επανυπολογίζουν τις προβολές τους, συγκρίνουν κατακερματισμούς xxh3-128 και στέλνουν μόνο τις διαφορές όταν αλλάζει το αποτέλεσμα. Μία συνδρομή μπορεί να αντλεί δεδομένα και από τις δύο βάσεις δεδομένων, εφαρμόζοντας παράλληλα το πλαίσιο δικαιωμάτων πρόσβασης του API.

Η εξουσιοδότηση αντιμετωπίζεται ως ακόμη μία αντιδραστική πηγή δεδομένων, ώστε οι αλλαγές στα δικαιώματα πρόσβασης να ενεργοποιούν την παραγωγή νέων αποτελεσμάτων ανεξάρτητα από τις συνήθεις αλλαγές σε έγγραφα. Η Lovable ανέφερε ότι ο επανυπολογισμός μόνο όταν άλλαζαν πεδία που συμμετείχαν στις αποφάσεις πρόσβασης, αντί σε κάθε σχετική ενημέρωση εγγράφου, μείωσε τους επανυπολογισμούς δικαιωμάτων κατά περίπου 84%. Η υπηρεσία διαθέτει περίπου 40 τύπους συνδρομών, τους οποίους διαχειρίζονται επτά ομάδες, με τυποποιημένες διεπαφές, κοινόχρηστες συνδρομές στην πλευρά του διακομιστή και ειδοποιήσεις που δρομολογούνται στις αντίστοιχες ομάδες.

Η κίνηση σε λειτουργία σκιάς επικύρωσε τη σταδιακή διάθεση

Αρχικά, η Lovable εκτέλεσε την υπηρεσία σε λειτουργία σκιάς: το frontend ακολουθούσε ολόκληρη τη νέα διαδρομή, αλλά απέρριπτε τα δεδομένα που λάμβανε και συνέχιζε να εμφανίζει περιεχόμενο από το Firestore. Η χρήση πραγματικής κίνησης και πραγματικών δομών δεδομένων αποκάλυψε καταιγισμό επανασυνδέσεων μετά τις αναπτύξεις, εσφαλμένη ταξινόμηση σφαλμάτων και όριο μεγέθους δεδομένων που ήταν πολύ χαμηλό για τα πραγματικά δεδομένα. Στη συνέχεια, μια σημαία λειτουργίας αύξησε σταδιακά τη διαθεσιμότητα για τους χρήστες από 1% σε 10%, 50% και 100% μέσα σε αρκετές ημέρες. Η Lovable δήλωσε ότι η διάθεση δεν προκάλεσε κανένα περιστατικό ορατό στους χρήστες ούτε υποχώρηση στις μετρικές που παρακολουθούσε.

Επειδή οι συνδέσεις WebSocket παραμένουν σταθερές και μπορεί να διαρκούν ώρες, η προσθήκη pod δεν μεταφέρει από μόνη της το υφιστάμενο φορτίο. Η Lovable κατανέμει το φορτίο με βάση τον αριθμό συνδέσεων, κλιμακώνει την υποδομή λαμβάνοντας υπόψη τις συνδέσεις μαζί με τη χρήση CPU και μνήμης και θέτει ανώτατο όριο στις συνδέσεις ανά pod για να περιορίσει τα κύματα επανασυνδέσεων. Μετά την επανασύνδεση, οι πελάτες στέλνουν ένα αποτύπωμα της αποθηκευμένης κατάστασής τους, επιτρέποντας στον διακομιστή να επιβεβαιώσει, αφού επανελέγξει την εξουσιοδότηση, ότι τα δεδομένα δεν έχουν αλλάξει, αντί να τα μεταδώσει ξανά.

Ο συντάκτης της ανάρτησης ανέφερε ότι η βασική υλοποίηση χρειάστηκε 40 ημέρες ενεργού εργασίας και ότι οι πράκτορες κώδικα ανέλαβαν το μεγαλύτερο μέρος της υλοποίησης, αφού πρώτα είχαν εξεταστεί διεξοδικά η αρχιτεκτονική και οι οριακές περιπτώσεις. Ένα σύστημα δοκιμών ενσωμάτωσης συνδύαζε εξομοιωτές Firestore, Auth και Spanner με ενσωματωμένο διακομιστή NATS και πραγματικά διακριτικά ID που είχαν δημιουργηθεί από εξομοιωτή, επιτρέποντας στους πράκτορες να δοκιμάζουν αλλαγές σε ολόκληρη τη στοίβα.

Αποτελέσματα στην παραγωγή και δυνατότητα υποστήριξης εφαρμογών στο μέλλον

Για την περίοδο από τις 5 Σεπτεμβρίου έως τις 5 Οκτωβρίου 2026, η Lovable ανέφερε 2,61 δισεκατομμύρια πλαίσια δεδομένων και επιδιορθώσεων, χωρίς να υπολογίζονται τα πλαίσια ελέγχου που επαναλήφθηκαν κατά την επανασύνδεση. Εκτίμησε ότι η αποστολή πλήρων στιγμιότυπων για κάθε υπολογισμένο αποτέλεσμα θα είχε δημιουργήσει 40 TB δεδομένων εφαρμογής. Η αποδιπλοποίηση, οι διαφορές και η επαναχρησιμοποίηση κατά την επανασύνδεση μείωσαν τα δεδομένα που μεταδόθηκαν στην πράξη στα 1,11 TB, δηλαδή κατά 97% σε σχέση με εκείνη τη γραμμή βάσης, σύμφωνα με την εκτίμηση. Τα στοιχεία για τον όγκο των δεδομένων δεν περιλαμβάνουν την επιβάρυνση από τα πρωτόκολλα και τη μεταφορά.

Η Lovable μέτρησε το χρονικό διάστημα από την εγγραφή σε μια βάση δεδομένων προέλευσης έως τη στιγμή που ένα εξερχόμενο πλαίσιο ήταν έτοιμο για αποστολή: 66 χιλιοστά του δευτερολέπτου στο p50 και 249 χιλιοστά του δευτερολέπτου στο p99. Οι μετρήσεις αυτές δεν περιλαμβάνουν τις εγγραφές στην υποδοχή, τον χρόνο δικτύου και την επεξεργασία από τον πελάτη, επομένως δεν αντιπροσωπεύουν τον συνολικό χρόνο ενημέρωσης όπως τον αντιλαμβάνεται ο χρήστης.

Η Lovable δήλωσε ότι προσθέτει ενεργά δομικά στοιχεία για συμβάντα τομέα, για περιπτώσεις όπου οι καταναλωτές χρειάζεται να ενημερώνονται ότι συνέβη κάτι, αντί να λαμβάνουν ένα στιγμιότυπο δεδομένων, και ότι η υπηρεσία ενδέχεται αργότερα να αποτελέσει δυνατότητα των εφαρμογών που δημιουργούνται με τη Lovable. Μια τέτοια επέκταση θα έφερνε στις εφαρμογές που δημιουργούν οι πελάτες δικαιώματα πρόσβασης ελεγχόμενα από το backend και ζωντανές προβολές. Η τρέχουσα υλοποίηση παρέχει ήδη στις ομάδες της Lovable μια κοινή βάση για πιο ουσιαστική συνεργασία, καθώς εξελίσσεται η υποδομή δεδομένων τους.