- เป็นฐานข้อมูลฝั่งไคลเอนต์ที่ช่วยให้สร้างแอปทำงานร่วมกันแบบเรียลไทม์อย่าง Notion หรือ Figma ได้ง่าย
- เมื่อเขียน relational query แล้ว Instant จะจัดการการดึงข้อมูล การตรวจสอบสิทธิ์ และการแคชออฟไลน์ให้
- เมื่อข้อมูลเปลี่ยนแปลง ก็จะจัดการ optimistic update และการ rollback ให้อัตโนมัติด้วย
- ทุก query รองรับการทำงานแบบ multiplayer โดยพื้นฐาน
- รองรับการอัปเดตชั่วคราวอย่างเคอร์เซอร์หรือสถานะออนไลน์ด้วย
- ขณะนี้มี SDK สำหรับ Javascript, React และ React Native
แรงจูงใจในการพัฒนา
- การพัฒนาแอปสมัยใหม่ต้องทำหลายอย่าง เช่น ตั้งค่าเซิร์ฟเวอร์ ฐานข้อมูล แคช ORM และ endpoint
- ยังต้องเขียนโค้ดฝั่งไคลเอนต์ จัดการ state และวาด UI ด้วย
- เมื่อเพิ่มฟีเจอร์ multiplayer ก็ต้องคิดถึงเซิร์ฟเวอร์เก็บ state และถ้าจะรองรับโหมดออฟไลน์ก็ต้องพิจารณา IndexedDB กับ transaction queue
- ทุกครั้งที่เพิ่มฟีเจอร์ใหม่ ก็ต้องเขียน model, endpoint, state management และ UI ซ้ำ ๆ
- ในปี 2021 พวกเขาตระหนักว่าปัญหาส่วนใหญ่ที่วิศวกร UI ต้องเผชิญนั้น แท้จริงคือปัญหาฐานข้อมูล
- ถ้ามีฐานข้อมูลฝั่งไคลเอนต์ ก็แค่เขียน query โดยไม่ต้องกังวลเรื่อง state management, endpoint หรือ local cache
- ถ้า query รองรับ multiplayer โดยพื้นฐาน ก็ไม่ต้องกังวลเรื่องเซิร์ฟเวอร์เก็บ state
- ถ้าฐานข้อมูลรองรับ rollback ก็จะได้ optimistic update ไปด้วยโดยแทบไม่ต้องทำเพิ่ม
- จึงได้พัฒนา Instant ขึ้นมา โดย Instant มอบฐานข้อมูลที่ใช้ได้บนไคลเอนต์เพื่อให้โฟกัสกับการสร้าง UX ได้
ภาพรวมสถาปัตยกรรม
- Instant เก็บข้อมูลผู้ใช้ทั้งหมดไว้ในฐานข้อมูล Postgres ขนาดใหญ่เพียงชุดเดียวในรูปแบบ triple
- ให้บริการ free tier ด้วยการตั้งค่าแบบ multi-tenant
- เซิร์ฟเวอร์ซิงก์ที่เขียนด้วย Clojure จะสื่อสารกับ Postgres
- พวกเขาสร้าง query engine ที่เข้าใจ InstaQL ซึ่งคล้าย Datalog และ GraphQL
- ได้แรงบันดาลใจจาก WorldStore ของ Asana และ LiveGraph ของ Figma โดยติดตาม WAL ของ Postgres เพื่อตรวจจับข้อมูลใหม่และทำให้ query ที่เกี่ยวข้องเป็นโมฆะ
- ฝั่งฟรอนต์เอนด์มีการสร้าง triple store ฝั่งไคลเอนต์ขึ้นมา
- SDK จะเก็บแคชของ query ล่าสุดไว้ใน IndexedDB บนเว็บ และใน AsyncStorage บน React Native
- ข้อมูลทั้งหมดถูกจัดการผ่านระบบสิทธิ์ที่ทำงานด้วยไลบรารี CEL ของ Google
สรุปโดย GN⁺
- Instant เป็นฐานข้อมูลฝั่งไคลเอนต์ที่ช่วยให้สร้างแอปทำงานร่วมกันแบบเรียลไทม์ได้ง่าย
- ผ่าน relational query ระบบจะจัดการการดึงข้อมูล การตรวจสอบสิทธิ์ และการแคชออฟไลน์ให้อัตโนมัติ
- รองรับฟีเจอร์ multiplayer, optimistic update และ rollback โดยพื้นฐาน
- ได้แรงบันดาลใจจาก Asana และ Figma โดยติดตาม WAL ของ Postgres เพื่อตรวจจับข้อมูลใหม่และทำให้ query ที่เกี่ยวข้องเป็นโมฆะ
- จัดการข้อมูลได้อย่างมีประสิทธิภาพผ่าน triple store ฝั่งไคลเอนต์และระบบสิทธิ์
2 ความคิดเห็น
ดูเป็นโปรเจกต์ที่น่าคาดหวังมากจริง ๆ ในสายเดียวกับ Supabase
ความคิดเห็นจาก Hacker News
ผู้ก่อตั้ง Firebase: ตื่นเต้นกับการผสมผสานของออฟไลน์, เรียลไทม์, relational query และโอเพนซอร์สของ Instant มีคำขอเกี่ยวกับ relational query เข้ามามาก Firebase ฝั่งไคลเอนต์เป็นโอเพนซอร์ส แต่การทำให้แบ็กเอนด์เป็นโอเพนซอร์สไม่สำเร็จ
ฟีดแบ็ก: ตัวอย่างโค้ดไม่สมบูรณ์ แหล่งที่มาของ
transactและuseQueryไม่ชัดเจน รายละเอียดเล็ก ๆ น้อย ๆ สำคัญรองรับ self-hosting หรือไม่: เครื่องมือมักมีบางส่วนที่ไม่สามารถ self-host ได้ ควรทำให้ชัดเจน
ทางเลือกของโมเดล offline-first: เลือก PowerSync แล้ว WatermelonDB ก็ใช้ได้ ElectricSQL ยังไม่สุกงอม CouchDB และ PocketDB ไม่ทันสมัยแล้ว วางแผนจะใช้ PowerSync และ Supabase เป็นแบ็กเอนด์
ความสัมพันธ์กับแอป CRUD: เข้าใจความสัมพันธ์ระหว่างแอป CRUD กับแนวคิดของ InstantDB หรือ Firebase ได้ยาก สำหรับตัวแก้ไขข้อความแบบร่วมมือกันจะใช้ implementation ของ CRDT ใน Javascript
ประสบการณ์การใช้ Instant: ใช้ Instant มา 6 เดือนและพอใจมาก ฟีเจอร์เรียลไทม์, relational และออฟไลน์มีความสำคัญ เคยลองเครื่องมืออื่นแต่ไม่สำเร็จ หลังจากใช้ Instant ก็ไม่ได้ใช้เครื่องมืออื่นอีก
สรุประบบสิทธิ์: Firebase แยกตรรกะการค้นหา/อัปเดตข้อมูลออกจากนโยบายการเข้าถึง ส่วน Instant ประเมินตรรกะสิทธิ์ตามผลลัพธ์ของคิวรี Firebase ตรวจสอบความปลอดภัยก่อนรันคิวรี
การเปิดเผย Datalog engine หรือไม่: มี Datalog engine อื่นที่รองรับ recursive query อยู่ด้วย กำลังถามว่าแคชคิวรีและการ join รองรับได้หรือไม่ ในอดีตเคยมี Java InstantDB ที่ใช้ชื่อเดียวกัน พร้อมให้รายการ Datalog engine อื่นที่พัฒนาด้วย Clojure
ต้องการประสบการณ์แบบ ActiveRecord: อยากทำงานใน React/Vue/Solid แบบเดียวกับ ActiveRecord ต้องการ API แบบ object graph ไม่ต้องการ API แบบ SQL อยากให้ ORM ทำงานเหมือนมี object graph ทั้งหมดอยู่ในหน่วยความจำ
ปัญหาประสิทธิภาพของ triple store: เมื่อคิวรีส่วนใหญ่ดึงทั้งอ็อบเจ็กต์หรือหลายฟิลด์ของอ็อบเจ็กต์เดียวกัน triple store มักมีประสิทธิภาพไม่ดี Postgres เองก็ไม่ได้โดดเด่นนัก กำลังถามถึงประสบการณ์ที่เกี่ยวข้อง