28 คะแนน โดย GN⁺ 2024-08-23 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นฐานข้อมูลฝั่งไคลเอนต์ที่ช่วยให้สร้างแอปทำงานร่วมกันแบบเรียลไทม์อย่าง 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 ความคิดเห็น

 
stargt 2024-08-23

ดูเป็นโปรเจกต์ที่น่าคาดหวังมากจริง ๆ ในสายเดียวกับ Supabase

 
GN⁺ 2024-08-23
ความคิดเห็นจาก 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

    • Datomic
    • XTDB
    • Datascript
    • Datalevin
    • datahike
    • Naga
  • ต้องการประสบการณ์แบบ ActiveRecord: อยากทำงานใน React/Vue/Solid แบบเดียวกับ ActiveRecord ต้องการ API แบบ object graph ไม่ต้องการ API แบบ SQL อยากให้ ORM ทำงานเหมือนมี object graph ทั้งหมดอยู่ในหน่วยความจำ

  • ปัญหาประสิทธิภาพของ triple store: เมื่อคิวรีส่วนใหญ่ดึงทั้งอ็อบเจ็กต์หรือหลายฟิลด์ของอ็อบเจ็กต์เดียวกัน triple store มักมีประสิทธิภาพไม่ดี Postgres เองก็ไม่ได้โดดเด่นนัก กำลังถามถึงประสบการณ์ที่เกี่ยวข้อง