Lovable สร้างบริการเรียลไทม์เพื่อรวมศูนย์การกำหนดสิทธิ์เข้าถึงข้อมูล

Lovable รายงานเมื่อวันที่ 9 พฤศจิกายน 2026 ว่าส่วนหน้าของระบบได้เลิกใช้ Firestore แล้ว หลังติดตั้งใช้งาน Lovable Realtime ซึ่งเป็นบริการที่พัฒนาขึ้นเองเพื่อรวมศูนย์การอนุญาตเข้าถึงอย่างเต็มรูปแบบ โดยมีจำนวนการสมัครรับข้อมูลพร้อมกันสูงสุด 2.06 ล้านรายการในช่วงการวัดผล 30 วัน

การย้ายระบบทำให้การตัดสินใจเรื่องสิทธิ์เข้าถึงและฟิลด์ที่ผู้ใช้มองเห็นอยู่ในแบ็กเอนด์ Go ของ Lovable สำหรับแพลตฟอร์มสร้างแอป AI ของบริษัท บริการนี้เป็นช่องทางหนึ่งในการรวมข้อมูลจาก Firestore และ Spanner และอัปเดตมุมมองของผู้ใช้เมื่อข้อมูลต้นทางหรือสิทธิ์ของผู้ใช้รายนั้นเปลี่ยนแปลง

รวมศูนย์สิทธิ์และข้อมูลแบบเรียลไทม์

ก่อนหน้านี้ บางส่วนของ Lovable ใช้ Firestore ที่ทำงานบนเบราว์เซอร์ onSnapshot เพื่อรับการอัปเดต เบราว์เซอร์ได้รับเอกสารทั้งฉบับ ขณะที่กฎของ Firestore ต้องจำลองรูปแบบการกำหนดสิทธิ์ของ Go API การออกแบบนี้ยังทำให้การเปิดเผยข้อมูลกลายเป็นส่วนหนึ่งของการแก้ไขเอกสารตามปกติ กล่าวคือ ผู้ที่เพิ่มฟิลด์อาจเป็นผู้กำหนดว่าข้อมูลใดจะไปถึงเบราว์เซอร์ของผู้ใช้ โดยไม่จำเป็นต้องตระหนักถึงผลที่ตามมา

กฎของ Firestore สามารถค้นหาข้อมูลใน Firebase ได้ แต่ค้นหาใน Spanner ไม่ได้ จึงเป็นอุปสรรคต่อการอัปเดตสิทธิ์ที่มีผลกับกลุ่มองค์กรขนาดใหญ่ซึ่งซิงก์ผ่าน SCIM ซึ่งซิงก์ผู้ใช้และกลุ่มไปยังพื้นที่ทำงานของ Lovable พร็อกซีชั่วคราวที่ส่งคำขอของลูกค้าธุรกิจและองค์กรผ่าน Go API นำการตรวจสอบสิทธิ์ของ API กลับมาใช้ แต่ก็เปิดตัวรับฟังข้อมูลจาก Firestore ต้นทางแยกกันสำหรับการพึ่งพาข้อมูลของลูกค้าแต่ละราย ทำให้มีสตรีมซ้ำซ้อนและใช้ความจุของพูลการเชื่อมต่อร่วมกับคำขอฐานข้อมูลทั่วไป

Lovable กำหนดให้ระบบที่มาแทนต้องทำงานร่วมกับฐานข้อมูลเดิมทั้งสองระบบ ประเมินสิทธิ์เข้าถึงใหม่อย่างต่อเนื่อง และปิดสตรีมของผู้ใช้ที่ถูกเพิกถอนสิทธิ์ได้ระหว่างเซสชัน นอกจากนี้ บริษัทยังต้องการระงับฟิลด์ที่ผู้ใช้ไม่มีสิทธิ์เข้าถึงก่อนที่ข้อมูลใด ๆ จะออกจากเซิร์ฟเวอร์ บริษัทประเมินว่าตัวเลือกด้านการรับส่งข้อมูล การซิงโครไนซ์ และการผสานรวมกับฐานข้อมูลที่พิจารณา ไม่สามารถให้ความสามารถดังกล่าวได้หากไม่มีการผสานระบบครั้งใหญ่ การเปลี่ยนฐานข้อมูล หรือการจำลองข้อมูลไปยัง Postgres

บริการ Go ที่พัฒนาขึ้นทำงานบน GKE และเปิด WebSocket หนึ่งรายการต่อแท็บเบราว์เซอร์ โดยรวมการสมัครรับข้อมูลหลายรายการไว้ในการเชื่อมต่อนั้น ฟีดการดักจับการเปลี่ยนแปลงข้อมูลส่งการเปลี่ยนแปลงจาก Firestore และ Spanner ผ่านบริดจ์ไปยัง NATS ซึ่งเป็นระบบส่งข้อความของบริการ การสมัครรับข้อมูลที่ตรงกันจะคำนวณมุมมองใหม่ เปรียบเทียบแฮช xxh3-128 และส่งเฉพาะส่วนต่างเมื่อผลลัพธ์เปลี่ยนแปลง การสมัครรับข้อมูลรายการเดียวสามารถดึงข้อมูลจากฐานข้อมูลทั้งสองระบบ พร้อมใช้กรอบการกำหนดสิทธิ์ของ API

ระบบถือว่าการอนุญาตเข้าถึงเป็นแหล่งข้อมูลแบบรีแอกทีฟอีกแหล่งหนึ่ง จึงสามารถคำนวณผลลัพธ์ใหม่เมื่อสิทธิ์เปลี่ยนแปลง โดยไม่ขึ้นกับการแก้ไขเอกสารตามปกติ Lovable รายงานว่า การคำนวณสิทธิ์ใหม่เฉพาะเมื่อฟิลด์ที่เกี่ยวข้องกับการตัดสินใจเรื่องสิทธิ์เปลี่ยนแปลง แทนที่จะคำนวณทุกครั้งที่เอกสารที่เกี่ยวข้องได้รับการอัปเดต ช่วยลดการคำนวณสิทธิ์ใหม่ได้ประมาณ 84% บริการนี้มีประเภทการสมัครรับข้อมูลประมาณ 40 ประเภท ซึ่งดูแลโดย 7 ทีม พร้อมอินเทอร์เฟซที่ระบุชนิดข้อมูล การสมัครรับข้อมูลฝั่งเซิร์ฟเวอร์ที่ใช้ร่วมกัน และการแจ้งเตือนที่ส่งไปยังทีมที่รับผิดชอบ

ตรวจสอบความถูกต้องของการทยอยเปิดใช้งานด้วยทราฟฟิกเงา

ช่วงแรก 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 วัดช่วงเวลาตั้งแต่มีการเขียนข้อมูลลงฐานข้อมูลต้นทางจนเฟรมขาออกพร้อมส่งได้ 66 มิลลิวินาทีที่ p50 และ 249 มิลลิวินาทีที่ p99 การวัดนี้ไม่รวมการเขียนผ่านซ็อกเก็ต เวลาที่ใช้ในเครือข่าย และการประมวลผลของไคลเอนต์ จึงไม่ใช่เวลาทั้งหมดที่ผู้ใช้รับรู้ตั้งแต่ข้อมูลอัปเดต

Lovable ระบุว่ากำลังเพิ่มองค์ประกอบพื้นฐานสำหรับเหตุการณ์ระดับโดเมน เพื่อรองรับกรณีที่ผู้เรียกใช้บริการต้องการรับแจ้งว่าเกิดเหตุการณ์บางอย่างขึ้น แทนที่จะรับเพียงภาพข้อมูล ณ ช่วงเวลาหนึ่ง และบริการนี้อาจกลายเป็นความสามารถภายในแอปที่สร้างด้วย Lovable ในภายหลัง การต่อยอดดังกล่าวจะนำสิทธิ์ที่ควบคุมจากแบ็กเอนด์และมุมมองข้อมูลแบบเรียลไทม์มาสู่แอปพลิเคชันที่ลูกค้าสร้างขึ้น การติดตั้งใช้งานในปัจจุบันช่วยให้ทีมของ Lovable มีรากฐานร่วมกันสำหรับการทำงานร่วมกันที่มีประสิทธิภาพยิ่งขึ้น ขณะที่โครงสร้างพื้นฐานด้านข้อมูลของพวกเขาพัฒนาต่อไป