- ชั้นข้อมูลสำหรับการจัดการสถานะ ที่ออกแบบมาเพื่อให้พัฒนาแอปพลิเคชันประสิทธิภาพสูงได้ โดยไม่ต้องแบกรับภาระในการ พัฒนา logic การซิงก์
- มีจุดเด่นคือใช้ SQLite แบบ reactive และเอนจินซิงก์ในตัว
- เป็นแบบ Local-first จึงให้ประสิทธิภาพสูงแม้อยู่ในสถานะออฟไลน์ และรองรับการซิงก์อัตโนมัติเมื่อเครือข่ายกลับมา
- การดำเนินการจัดการสถานะทั้งหมดทำงานอย่างรวดเร็วบนฐานข้อมูล SQLite ภายในเครื่อง
- สตรีมข้อมูลแบบ reactive: เมื่อข้อมูลเปลี่ยนแปลง จะส่งอีเวนต์ไปยังลิสเนอร์ที่เชื่อมกับ UI ทันที ทำให้สะท้อนการเปลี่ยนแปลงของสถานะได้แบบเรียลไทม์
- สามารถนำไปใช้ได้ในสภาพแวดล้อมหลากหลาย (เว็บ, โมบายล์, เดสก์ท็อป ฯลฯ)
- เมื่อเทียบกับ เครื่องมือจัดการสถานะ แบบเดิม ให้ผลลัพธ์ที่ดีกว่าในด้านประสิทธิภาพระดับเนทีฟและความสอดคล้องของข้อมูล
2 ความคิดเห็น
เดโมบนหน้าแรกของเว็บไซต์ทำออกมาได้ดีมากจริง ๆ พอกดเล่นเดโมไปสักพักก็ทำให้อยากลองใช้ขึ้นมาเลย
ความคิดเห็นบน Hacker News
สวัสดีครับ ผมเป็นผู้ร่วมก่อตั้งของ LiveStore เอง (ก่อนหน้านี้เคยสร้าง Prisma)
ตลอด 4 ปีที่ผ่านมา ผมพัฒนา ไคลเอนต์เพลงประสิทธิภาพสูง ระดับเนทีฟชื่อ Overtone และระหว่างทางก็ได้สร้าง LiveStore ขึ้นมาเพื่อใช้เอง
LiveStore เพิ่ม เลเยอร์ reactive signal ให้กับ SQLite และผสานเข้ากับ การซิงก์แบบ event-sourcing (คล้าย Git)
ผมลองประเมินสภาพแวดล้อม local-first มาหลายแบบแล้ว แต่แทบไม่มีโซลูชันไหนที่จัดการได้สะอาดเท่า LiveStore
เครื่องมือที่พัฒนาใกล้เคียงกันก็มี tinyBase แต่แนวทางโครงสร้างต่างกัน (CRDTs vs event sourcing)
มีเรื่องที่สงสัยคือทำไมถึงจำกัดขนาดข้อมูลไว้ที่ 1GB และจะมีตัวเลือกให้ เก็บข้อมูลใน SQLite และคงไว้บนดิสก์สำหรับข้อมูลที่ใหญ่กว่านี้ได้ไหม
มันน่าจะเปลี่ยนโหมด persistence ได้ด้วยแค่การตั้งค่าไม่ใช่หรือ?
ผมคิดว่า multi-tenancy ก็น่าจะเป็น use case ที่น่าสนใจ เช่น ถ้าแต่ละองค์กรต้องการ namespace แยกกันแบบ JIRA ก็น่าจะดีถ้าผู้ใช้แต่ละคนได้รับเฉพาะของทีม/แผนกตัวเอง ไม่ใช่ตั๋วทั้งหมด
โดยพื้นฐานแล้วมันจะเป็นโครงสร้างที่ฐานข้อมูลในเครื่องเป็น subset ของข้อมูลทั้งหมด ถ้ามีเซิร์ฟเวอร์ซิงก์ที่รันได้ตรงบน Bun/Node เลย (ไม่ต้องพึ่ง Cloudflare) มาให้ในชุดด้วยก็คงยอดเยี่ยมมาก
น่าจะเข้ากับไอเดียโปรเจกต์ที่ผมกำลังพิจารณาอยู่ตอนนี้ได้ดี โดยเฉพาะเพราะ multi-tenancy เป็นสิ่งจำเป็น
เดือนก่อนผมเข้าไปดูว่า LiveStore จะเอามาลองใช้กับโปรเจกต์งานอดิเรกได้ไหม แต่เพราะยังเป็น beta preview เลยเข้าถึงได้ยาก
หวังว่าอีกไม่นานจะได้ลองดูให้ลึกขึ้น ประทับใจที่พวกคุณ ขับเคลื่อนการพูดคุย เรื่อง local-first อย่างจริงจัง
ใครก็ตามที่เคยสร้างเว็บแอปที่ซิงก์แบบออฟไลน์ได้ จะเข้าใจทันทีว่า sync engine มีประโยชน์แค่ไหน
วันนี้ฟังการบรรยายในงาน Local-First Conf แล้ว ยอดเยี่ยมมาก
คำอธิบายเกี่ยวกับโครงสร้างที่ ทำ event sourcing บน SQLite นั้นชัดเจนและน่าเชื่อถือมาก
ขอบคุณที่ช่วยผลักดัน SQLite โดยเฉพาะ OPFS Wasm SQLite บนเว็บอย่างจริงจัง
PowerSync ก็สนับสนุน SQLite อย่างมากเช่นกัน เลยรู้สึกยินดีที่ได้เห็นตัวอย่างความสำเร็จอย่าง LiveStore
ปกติแล้วเวลา LiveStore ขยายโมเดล event sourcing ในระดับ global มักจะซิงก์ผ่าน central sync backend กับไคลเอนต์ทั้งหมด เลยสงสัยว่านี่เป็นข้อบังคับหรือไม่
อยากถามว่ามีทางรองรับ federated nodes หรือแม้แต่ โหมด P2P เต็มรูปแบบ ได้ไหม กำลังคิดถึงการประยุกต์ใช้กับกรณีโซเชียลเน็ตเวิร์กแบบกระจายศูนย์อยู่
สงสัยว่าเมื่อใช้ LiveStore ร่วมกับ React และ WASM แล้ว จะสามารถแทนที่ เฟรมเวิร์ก Juce ที่แอปเพลงส่วนใหญ่ใช้กันได้หรือไม่
ผมเป็น beatmaker และการทำงานกับ Juce + C++ มักทั้งยากและน่ากลัวเสมอ เลยอยากรู้ว่า LiveStore จะเป็นทางเลือกที่ดีสำหรับคนที่อยากเริ่มพัฒนาแอปเพลงหรือเปล่า
ผมดูการบรรยายในงาน Local-first Conf มา ช่วงนี้มี sync engine เกิดขึ้นหลากหลายมากจริง ๆ
LiveStore กำลังเจาะลึกพื้นที่ที่น่าสนใจ คือการผสาน event sourcing เข้ากับ sync engine
น่าประหลาดใจมากที่มันกลายเป็น ระบบที่แข็งแรง ได้ถึงขนาดนี้แล้ว
ไม่กี่สัปดาห์ที่ผ่านมา ผมลองใช้มันกับโปรเจกต์ใหม่ด้วยตัวเอง และมัน ทำงานลื่นไหล มาก
ขอแสดงความยินดีกับการเปิดตัว! ผมสงสัยว่าระบบนี้เข้ากับกลยุทธ์ "1. Serialization" ที่อธิบายไว้ที่นี่หรือไม่
ตามที่กล่าวถึงใน ProseMirror-collab อยากถามว่าปัญหาที่ ไคลเอนต์ความหน่วงต่ำ ซึ่งอัปเดตบ่อย อาจ ขัดขวาง การอัปเดตของไคลเอนต์ความหน่วงสูง จะเกิดขึ้นใน LiveStore ด้วยหรือไม่
ดูเหมือนว่า LiveStore จะใช้ wa-sqlite
ผมอยากทราบรายละเอียดเกี่ยวกับกลยุทธ์การทำ persistence สำหรับข้อมูลออฟไลน์ โดยเฉพาะว่าใช้ OPFS (รวมถึงสายแยกอย่าง AccessHandlePoolVFS) หรือ IndexedDB หรือใช้ทั้งสองอย่าง
และอยากรู้ว่าจัดการกับ ความไม่เสถียร ระหว่างเบราว์เซอร์ของ OPFS และ นโยบายเก็บข้อมูล 7 วัน ของ Safari IndexedDB อย่างไร
ทั้งที่ SQLite มี WASM build อย่างเป็นทางการอยู่แล้ว อยากรู้ว่าอะไรคือเหตุผลที่เลือกใช้ wa-sqlite
ไม่นานมานี้ผมพูดถึง LiveStore แบบสั้น ๆ ในพอดแคสต์ LocalFirst.fm (ดู https://www.localfirst.fm/24)
ดูเป็นโปรเจกต์ที่น่าตื่นเต้นมาก แต่ก็แอบระวังนิดหน่อยว่าจะตกอยู่ใน กับดักกระแสเกินจริง (hype trap) หรือไม่
ผมเองก็กำลังทดลองทำ แอป local-first แบบคัสตอมที่รองรับหลายอุปกรณ์ในแนวทางคล้ายกัน
สงสัยว่าจะเพิ่ม การเข้ารหัสแบบ E2E แบบเลือกใช้ได้หรือไม่ จากเอกสารดูเหมือนว่าแทบจะทำได้เลยถ้าเพิ่ม การเข้ารหัส ในระดับ event payload ยกเว้นแค่ว่าการทำ log compaction ฝั่งเซิร์ฟเวอร์จะยากขึ้น
ผมสร้าง LiveStore ขึ้นมาเองจากความจำเป็นที่เกิดระหว่างทำ Overtone
ทั้ง LiveStore และ Overtone กำลังถูกพัฒนาโดยมุ่งไปที่ ความยั่งยืนระยะยาว และโครงสร้างนี้ รองรับ E2E encryption ได้อยู่แล้ว
แม้ผมจะยังไม่ได้ลองทำด้วยตัวเอง แต่ถ้ามีปัญหาก็ยินดีช่วยเสมอ
อีกวิธีหนึ่งอาจเป็นการลองทำ log compaction เฉพาะ ฝั่งไคลเอนต์ และระหว่างทำวิศวกรรม เราจะคำนึงถึง use case นี้ไว้แน่นอน
ผม สงสัย กับคำกล่าวเรื่องการรองรับข้ามแพลตฟอร์ม เพราะอย่างแรกที่เห็นคือเว็บบน Android ยังไม่รองรับ
ดูความคืบหน้าได้ใน GitHub ทางการ (https://github.com/livestorejs/livestore/issues/321)
หวังว่าจะเข้าใจว่า การสร้าง ระบบที่ทะเยอทะยาน แบบนี้ต้องใช้ความพยายามและเวลาอย่างมาก เพราะการรองรับ Web API ของแต่ละแพลตฟอร์มยังแตกต่างกันอยู่มาก
มีจุดหนึ่งที่น่าสนใจในวิดีโอเดโม! ที่ช่วง 1 นาที 7 วินาที เสียงออกไปทางซ้าย เหมือนจะเด่นกว่า เป็นเรื่องเล็กน้อยแต่คิดว่าน่าจะเป็นประโยชน์เลยบอกไว้
น่าประทับใจที่มีเครื่องมือสำหรับนักพัฒนามาด้วย ดูเหมือนว่าคงทดสอบกับ โปรเจกต์ภายใน ของตัวเองมาพอสมควร
สิ่งที่สงสัยคือ ในระยะยาวมีแผนจะจัดการกับ compaction ของแอป/เพจที่รันต่อเนื่องนาน ๆ อย่างไร และแม้ event sourcing จะเป็นแนวคิดที่ยอดเยี่ยม แต่เมื่อชั้นแอปพลิเคชันพัฒนาไปเรื่อย ๆ เรื่อง การดูแลโค้ด (ไคลเอนต์เวอร์ชันเก่า, schema migration ฯลฯ) อาจกลายเป็นเรื่องยาก
ดูเหมือน Overtone จะรองรับหลายแหล่งข้อมูล เลยอยากรู้ว่าจะมี การเล่นแบบออฟไลน์ ด้วยหรือไม่ โดยเฉพาะเพราะ UI ของ Spotify ใช้งานไม่สะดวกมากจนผมอยากได้ตัวแทนจริง ๆ
ไอเดียหลักคือการใส่ ข้อมูลเชิงความหมาย ให้แต่ละ event มากขึ้น เพื่อให้สามารถนิยามการทับซ้อนกันระหว่าง event ได้
ตัวอย่างเช่น ในแอป todo event "todoCompleted" ของ task ID เดียวกัน สามารถ บีบอัด event "todoCompleted"/"todoUncompleted" อื่น ๆ ของ task นั้นได้
ติดตามความคืบหน้าได้ใน GitHub (https://github.com/livestorejs/livestore/issues/254)
event sourcing เป็นเรื่องที่ วินัยและการออกแบบ สำคัญมากจริง ๆ กับข้อมูลนั้นไม่มี "ของฟรี" ดังนั้น trade-off จึงเป็นหัวใจหลัก
สำหรับ use case หลักของผมอย่าง Overtone ผมรู้สึกว่า trade-off ของ event sourcing คุ้มค่ากว่า
เรื่องการรองรับเวอร์ชันเก่าและอื่น ๆ ก็มี วิธีที่ค่อนข้างตรงไปตรงมา หลายแบบ สุดท้ายก็ขึ้นอยู่กับลักษณะแอปและ trade-off ของแต่ละงาน
ขอบคุณที่สนใจ Overtone ผมเองก็เริ่มโปรเจกต์นี้เพราะไม่พอใจกับ Spotify เช่นกัน ส่วนการเล่นแบบออฟไลน์นั้นขึ้นอยู่กับ ผู้ให้บริการเพลง
ตัวอย่างเช่น อัลบั้มที่คุณเป็นเจ้าของเองผ่าน Dropbox อาจรองรับได้ แต่บริการสตรีมมิงอย่าง Spotify อาจขึ้นอยู่กับ นโยบาย ของเขา
ผมชอบสถาปัตยกรรมนี้ โดยเฉพาะ event sourcing
แต่ event sourcing ก็ต้องใช้อย่างระมัดระวัง เพราะ การ materialize view อาจช้าขึ้นตามมุมมองที่ต้องการ และจะยิ่งช้าลงเมื่อข้อมูลใหญ่ขึ้น
ทางแก้คือต้องจัดการ การอัปเดต materialization ภายใน transaction เองด้วย trigger หรือวิธีคล้ายกัน
เวลา replicate หรือ sync ก็ต้องคำนึงถึงเรื่องนี้เช่นกัน และควรทำความเข้าใจแนวคิด CRDT ให้ดีสำหรับเรื่อง การแก้ conflict
ถ้ามี ฐานข้อมูลที่คล้าย SQLite3 แต่มีความสามารถด้านภาษาแบบ Postgres ก็คงดีมาก เพราะจะทำให้สลับใช้ local-first กับ remote-first ได้ด้วยการเปลี่ยนแค่การตั้งค่า
ส่วนประเด็นหลักเรื่องต้นทุนของ materialization นั้น เราจะปรับปรุง compaction ต่อไป และ LiveStore ทั้งระบบก็เป็นเฟรมเวิร์กที่ถูกออกแบบอย่างพิถีพิถันโดยมุ่งที่ การเพิ่มประสิทธิภาพ