Linear พาฉันหลงเข้าไปใน Rabbit Hole แบบ local-first

 (bytemash.net)
3 คะแนน โดย GN⁺ 2025-08-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การใช้ Linear ทำให้มุมมองต่อการพัฒนา เว็บแอปพลิเคชัน เปลี่ยนไปอย่างมาก
  • Linear ทำงานในแนวทาง local-first ทำให้ได้สัมผัส การตอบสนองทันทีและการโต้ตอบแบบไม่ต้องรอการรับส่งข้อมูลเครือข่าย
  • ในแนวทางนี้ client แต่ละตัวจะมี ฐานข้อมูลอิสระ และการเปลี่ยนแปลงจะซิงก์กับเซิร์ฟเวอร์แบบอะซิงโครนัส
  • อย่างไรก็ตาม การนำไปใช้ในความเป็นจริงมีความยาก โดยเฉพาะเรื่อง การซิงก์ในสภาพแวดล้อมกระจาย, การแก้ความขัดแย้ง, และการจัดการออฟไลน์
  • Jazz, Electric SQL, Zero และแนวทางแก้ปัญหาอื่น ๆ ของระบบนิเวศ local-first เริ่มเข้ามาแทนที่อย่างต่อเนื่อง และประสบการณ์นักพัฒนาก็กำลังดีขึ้นเรื่อย ๆ

ภาพรวม

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

ตกหลุมกระต่าย (Down the Rabbit Hole)

จากการเจาะลึกความลับเชิงเทคนิคของ Linear พบว่า พวกเขาใช้งาน IndexedDB ของเบราว์เซอร์ ราวกับเป็นฐานข้อมูลจริง ทุกการเปลี่ยนแปลงถูก ประมวลผลแบบ local ก่อนทันที แล้วจึงซิงก์เบื้องหลังผ่าน GraphQL และ Websockets

  • คำว่า local-first อาจตีความได้หลากหลายว่าเป็นกลยุทธ์ UX (ตอบสนองทันที) หรือเป็น ปรัชญาที่เก็บข้อมูลไว้ในเครื่องก่อนแล้วค่อยซิงก์กลับไป
  • ในเว็บแอปแบบดั้งเดิม เซิร์ฟเวอร์คือแหล่งข้อมูลความจริงเพียงจุดเดียว แต่ในสถาปัตยกรรม local-first แทบทุก client จะมีฐานข้อมูลของตัวเอง
  • เมื่อฐานข้อมูลถูกย้ายมาอยู่ใกล้ผู้ใช้มากขึ้น ความหน่วงจากเครือข่ายในการโต้ตอบจะถูกตัดออกไปได้เกือบทั้งหมด

ความท้าทาย: มันไม่ใช่เรื่องง่าย

เมื่อพยายามลองนำแนวทางของ Linear ไปทำเอง ก็พบว่าความซับซ้อนค่อนข้างมาก

  • การจัดการการสลับโหมด ออฟไลน์/ออนไลน์
  • การแก้ความขัดแย้งระหว่าง client ที่กระจายกันอยู่
  • การซิงก์แบบบางส่วน (ออกแบบเพื่อไม่ต้องดาวน์โหลดข้อมูลทั้งหมด)
  • การย้ายสคีมา (migration) ของข้อมูลแคช
  • ความปลอดภัยและการควบคุมสิทธิ์ ในสภาพแวดล้อมกระจาย
  • พื้นที่เหล่านี้ต้องการ เวลาและความพยายามด้านวิศวกรรมจำนวนมาก

ระบบนิเวศ Local-First ในปี 2025

ณ ปี 2025 มีทางแก้หลายตัวที่ทรงพลังในโลก local-first

  • Electric SQL: เครื่องมือซิงก์ที่อิงกับ Postgres
  • PowerSync: โซลูชันสายองค์กร
  • Jazz: เครื่องมือที่ช่วยให้สร้างแอป local-first ได้ง่ายขึ้น
  • Replicache: โซลูชันหลักเดิม (หยุดพัฒนา)
  • Zero: วิสัยทัศน์ใหม่จากทีม Replicache
  • Triplit: ซิงก์บนพื้นฐานของ TripleStore
  • Instant: เน้นประสบการณ์นักพัฒนา (DX)
  • LiveStore: ให้ชั้นการซิงก์ข้อมูลแบบ real-time

ลงลึก: Jazz

Jazz ดึงดูดความสนใจด้วยสโลแกนเฉพาะว่า ทำ สร้างแอป local-first ให้ทำได้ง่ายเท่าการอัปเดต state

โมเดลความคิด

Jazz นำแนวคิด Collaborative Values (CoValues) มาใช้เป็นโครงสร้างข้อมูลสำหรับการทำงานร่วมกันแบบ real-time

  • กำหนดสคีมาด้วย Jazz และ Zod: การนิยามนี้ไม่ใช่แค่ type ธรรมดา แต่ทำงานเป็น ออบเจกต์สด (live object) ที่ซิงก์ได้อัตโนมัติ
  • โดยไม่ต้องมี API route, ตรรกะ request/response หรือ DTO แยกต่างหาก แค่เปลี่ยนสถานะของ object ก็เกิดการซิงก์โดยอัตโนมัติทันที

วิธีที่ Jazz ทำได้

โครงสร้างภายในของ Jazz เป็นดังนี้

  • การรับประกันความเป็นเอกลักษณ์: ข้อมูลแต่ละชิ้นถูกกำหนดรหัสเฉพาะอัตโนมัติ
  • Event sourcing: บันทึกประวัติการเปลี่ยนแปลงเป็นเหตุการณ์ ทำให้ซิงก์แบบ real-time ได้มีประสิทธิภาพมากขึ้น
  • การเข้ารหัสแบบ end-to-end: เข้ารหัสฝั่ง client ก่อนซิงก์ เซิร์ฟเวอร์เห็นเฉพาะ blob ที่เข้ารหัสเท่านั้น
  • การกำหนดสิทธิ์เชิงกลุ่ม: ใช้การควบคุมสิทธิ์ตามกลุ่มแทน ACL แบบดั้งเดิม โดยแยกความเป็นเจ้าของออกชัดเจน

จุดแลกเปลี่ยน

สถาปัตยกรรมนี้มีประสิทธิภาพมากสำหรับงาน prototype และพัฒนา UI อย่างรวดเร็ว แต่ก็มีจุดที่ต้องคำนึงเป็นพิเศษตามธรรมชาติของมัน

Server ของคุณตาบอด

จากการเข้ารหัสแบบ end-to-end เซิร์ฟเวอร์อ่านข้อมูลของผู้ใช้ไม่ได้ หากไม่ได้กำหนดล่วงหน้าว่าเซิร์ฟเวอร์ควรเข้าถึงข้อมูลใดบ้าง ก็จะมีข้อจำกัดในการจัดการเรื่องการเฝ้าสังเกตหรือการป้องกันการจัดเก็บข้อมูลอันไม่ปลอดภัย/มุ่งร้าย

Time Travel เป็นสิ่งจำเป็น

ด้วย event sourcing ทำให้ ประวัติการเปลี่ยนแปลงทั้งหมดถูกเก็บอย่างถาวร ทำให้ Undo/Redo ใช้งานง่ายมาก แต่ด้านลบคือเมื่อมีข้อกำหนดทางกฎหมายเช่น GDPR การลบข้อมูลอาจทำได้ยาก

Storage Goes Brrr

เมื่อไม่มีการลบข้อมูล ทำให้ การใช้พื้นที่เก็บข้อมูลค่อย ๆ เพิ่มขึ้น โครงการขนาดเล็กอาจไม่เป็นปัญหา แต่ใน SaaS ขนาดใหญ่ต้นทุนการเก็บอาจพุ่งสูงได้มาก

Local Dev ยังมีจุดค้างคา

โหมดการยืนยันตัวตนหลักคือการใช้ Passkeys ทำให้งานพัฒนาภายในหรือการสร้างระบบเองมีความยุ่งยากตอนแรก เช่น การจัดการ HTTPS, certificate, และการย้ายคีย์ อย่างไรก็ตามคาดว่าจะมีการปรับปรุงในอนาคต เช่น การผสาน Better Auth

แต่พูดตามตรง มันยังคุ้มค่า

แม้มีข้อจำกัดเหล่านี้ ประสบการณ์และความเร็วในการพัฒนาของ Jazz ก็ยังสร้างความประทับใจอย่างมาก แม้ยังอยู่ช่วงเริ่มต้น แต่คาดว่าปัญหาหลายอย่างจะค่อย ๆ ได้รับการแก้ไขไปตามเวลา

สำรวจ: Electric SQL และ Zero

ต่างจาก Jazz, Electric SQL และ Zero ใช้แนวทางแบบค่อยเป็นค่อยไป

  • สามารถใช้ Postgres table เดิมได้เลย
  • Electric SQL ทำให้สามารถ subscribe ส่วนหนึ่งของ table เป็น reactive query (Shape) เพื่อซิงก์ไปยัง UI ได้
  • วิธีจัดการการเปลี่ยนแปลง (mutation) แตกต่างจาก Jazz และยังมีตัวเลือกหลากหลายรวมถึงการผสาน LiveStore
  • Zero คล้ายกับ Electric แต่มีการรองรับ การซิงก์การเปลี่ยนแปลง แบบ built-in

เมื่อใดจึงเหมาะกับ Local-First?

แนวทาง local-first ให้ข้อสรุปเช่นนี้

เหมาะสม:

  • เครื่องมือสร้างสรรค์ (ออกแบบ, เขียน, ทำเพลง ฯลฯ)
  • แอปที่ช่วยการทำงานร่วมกัน
  • แอปมือถือที่ต้องรองรับโหมดออฟไลน์
  • เครื่องมือสำหรับนักพัฒนา
  • แอปเพิ่มประสิทธิภาพส่วนบุคคล

เป็นความท้าทาย:

  • ตรรกะธุรกิจระดับเซิร์ฟเวอร์ขนาดใหญ่
  • ความต้องการด้าน audit ที่เข้มงวด
  • ระบบวิเคราะห์ข้อมูลปริมาณมาก
  • ระบบเดิมที่ฝังลึก (tightly-coupled)
  • ระบบที่มักปฏิเสธคำขอจากฝั่งเซิร์ฟเวอร์บ่อยครั้ง

มองไปข้างหน้า

Local-first คือสัญญาณการเปลี่ยนแปลงแบบพาราไดม์ของการพัฒนาเว็บ Linear ได้พิสูจน์แล้วว่ามันให้ผลลัพธ์เชิง UX ที่ชัดเจนมาก ผู้พัฒนาจึงต้องพิจารณาว่าทางเลือกนี้แลกเปลี่ยนอะไร และเหมาะกับโครงการของตนเองหรือไม่

ขณะทำแอปส่วนบุคคลด้วย Jazz ฉันกำลังทดลองทั้งข้อดีข้อเสียจริง ๆ และขีดจำกัดเชิง abstraction ไปพร้อมกัน ระบบนิเวศนี้ยังอยู่ในช่วงต้น แต่คาดว่าเครื่องมือและแพทเทิร์นต่าง ๆ จะค่อย ๆ พัฒนาและสมบูรณ์ขึ้น อย่างไรก็ตาม ข้อดีของการจัดเก็บข้อมูลไว้ใกล้ผู้ใช้ยังชัดเจน และดูเหมือนจะไม่หายไปเร็ว

ในโปรเจกต์ใหม่ ถ้าสามารถยอมรับข้อจำกัดได้ ก็มีคุณค่าอย่างมากในการลอง local-first ในกรณีแย่ที่สุดก็ได้เรียนรู้ pattern สถาปัตยกรรมใหม่ และในกรณีดีที่สุดก็สามารถสร้างประสบการณ์ผู้ใช้ที่เร็วเกินคาดได้ ซึ่งในการแข่งขันที่เวลาตอบสนอง 300ms ใกล้จะเป็นเรื่องสำคัญมาก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-08-09
ความคิดเห็นบน Hacker News

  • Zero ก็ให้ความสามารถคล้ายกับ Electric และรองรับการประมวลผล mutation โดยตรง จุดเด่นหลักของ Zero คือการซิงก์แบบขับเคลื่อนด้วย query เราสามารถออกแบบแอปเป็นหน่วย query ได้ โดยไม่ต้องตัดสินใจก่อนล่วงหน้าว่าจะซิงก์ข้อมูลอะไรหรือกำหนดค่าอะไร แค่รัน query ก็ซิงก์ได้เฉพาะข้อมูลที่ต้องการหรือมากเท่านั้นที่จำเป็น ถ้าข้อมูลที่ไคลเอนต์ต้องการยังไม่มี query จะถูกส่งไปยังเซิร์ฟเวอร์โดยอัตโนมัติ และเมื่อซิงก์แล้วก็พร้อมใช้ใน query ถัดไปทันที วิธีนี้ค่อนข้างปฏิบัติได้จริง

    • เหมาะกับแอปทุกขนาด (ไม่สามารถซิงก์ข้อมูลทั้งหมดไปที่ไคลเอนต์ได้)
    • ดีสำหรับการเรนเดอร์หน้าจอเริ่มต้นอย่างรวดเร็ว (โหลดหน้า public อย่างเร็ว)
    • สิทธิ์เข้าถึงก็แก้ผ่าน query อย่างเดียว โดยไม่ต้องมีระบบแยก เพราะฉะนั้นประสบการณ์การใช้งาน Zero จึงใกล้เคียงฐานข้อมูลเชิงปฏิสัมพันธ์แบบ Convex หรือ RethinkDB แต่เพราะใช้ Postgres มาตรฐาน จึงสามารถเพลิดเพลินกับการโต้ตอบทันทีของเครื่องยนต์ซิงก์ได้เช่นกัน

  • ฉันชอบ SSR ฉันเชื่อว่าไคลเอนต์ควรมี state เท่าที่จำเป็นคือ session token, URL ปัจจุบัน และ DOM เท่านั้น เครือข่ายและเซิร์ฟเวอร์ยังคงเร็วขึ้นเรื่อยๆ ความเร็วแสงนั้นคงที่ แต่เรายังใช้ประโยชน์ได้ไม่หมด มีเทคโนโลยีที่อาจลด latency ของอินเทอร์เน็ตทั้งระบบได้ถึง 30% เช่น hollow core fiber ในอนาคต แม้ RTT จะเป็น 500ms ก็ตาม ถ้า SSR ให้หน้า HTML เรนเดอร์ได้ภายใน 16ms หน้าเว็บก็จะรู้สึกตอบสนองไวกว่าหน้าเว็บส่วนใหญ่บนโลกออนไลน์ในตอนนี้มาก ฉันไม่คิดว่าเซิร์ฟเวอร์ควรใช้เวลาสร้าง HTML response นานกว่าเฟรม 60Hz เซิร์ฟเวอร์ตัวนี้ใช้ Zen5 core สามารถ serialise JSON ขนาด 30~40MB ในเวลานั้นได้ มองด้านเซิร์ฟเวอร์แล้ว มันก็แค่ UTF-8 string ที่หรูหรายิ่งกว่าปกติเพียงเท่านั้น เรื่องพวกนี้ควรวัดเป็นหน่วย μs ไม่ใช่ ms latency ที่สูงไม่ได้เป็นข้ออ้างให้ใช้เวลา CPU แบบ lazy ได้ ฉันหลุดพ้นจาก millisecond jail โดยใช้ SQLite บริการ SQL ที่จัดการโฮสต์มักเป็นเหมือนโซ่ตรวนเมื่อเราพยายามมองหา latency ต่ำกว่า 1ms มาตรฐานของเบราว์เซอร์เองก็ช่วยแก้ปัญหาความหน่วงตอนนำทางบางส่วนได้ อ้างอิง Speculation Rules API

    • การคาดหวังว่าเครือข่ายและเซิร์ฟเวอร์จะยังคงเร็วขึ้นไม่ได้เป็นหลักฐานกลางทั่วไปให้ SSR ยกตัวอย่างได้ก็แค่ข้อยกเว้นที่ SSR จำเป็น เช่น เซิร์ฟเวอร์มีพลังคำนวณมากกว่าหรือไม่สามารถแยก logic ได้ง่าย ในความเป็นจริง มีหลายกรณีที่ client-side rendering เร็วกว่า มักมีตรรกะการเรนเดอร์ที่ซับซ้อนกว่าปริมาณข้อมูล และเมื่อรวมทรัพยากรของไคลเอนต์ทั้งหมดแล้วอาจมากกว่าเซิร์ฟเวอร์อีกด้วย ถ้า SSR เป็นทางเลือกเดียว ก็คงอธิบายไม่ตกว่าความฮอตที่มีต่อ WebAssembly ในตอนนี้ได้ ลองอ่าน บทความเกี่ยวกับ local computation ดูได้ด้วย สุดท้ายแล้วเราไม่รู้ล่วงหน้าว่าวิธีไหนดีกว่า และควรเลือกได้ตามจังหวะของ request

    • Right Tool For The Right Job! ตัวอย่างเช่น จะทำงานเอกสารร่วมมืออย่าง Google Docs, Sheets ได้ด้วยแค่ server-side rendering อย่างเดียวหรือ? ถ้ายึด SSR อย่างเดียว ผู้ใช้ที่กำลังแก้ไขตอนกลางเรื่องก็อาจถูกคนอื่นแทรกแก้เนื้อหาทิ้งไป เครื่องมือเหล่านี้ใช้งานได้ดีเพราะผลกระทบการเปลี่ยนแปลงเล็ก และเมื่อผู้ใช้รับรู้ว่ากำลังร่วมมือกันก็จะรับการอัปเดตเรียลไทม์ได้ทันที ส่วนเซอร์วิสเช่นการจองโรงแรมไม่จำเป็นต้องซิงก์เรียลไทม์ นอกจากนี้ระบบที่ซิงก์สะดุดระหว่างทางหรือลงแบบไม่รีบร้อนในแอป enterprise และยังออกแบบไม่พอ จะทำให้การรักษาความสอดคล้องยากมากเมื่อเพิ่มความซับซ้อนด้านโดเมนและระบบในภายหลัง

    • ถ้ามีไลบรารีแบบนี้ที่เพิ่มเข้าไปในแอป SSR เดิมได้ง่าย ฉันก็จะใช้ทันที

      • ขนาด 50kb (gzipped)
      • ไม่ต้องเปลี่ยนโค้ดในตอนนี้หรืออนาคต
      • ซิงก์อัตโนมัติได้โดยไม่ลดคุณภาพ UX แม้ในสภาพแวดล้อมออฟไลน์/แบนด์วิดท์ต่ำ ถ้ามีของแบบนี้ ฉันจะใช้เลย สิ่งที่ผู้สนับสนุน SSR มักละเลยคือการยอมรับว่าประสบการณ์ในสภาพแวดล้อมออฟไลน์หรือแบนด์วิดท์ต่ำต้องถูกเสียสละเพื่อความสุขของนักพัฒนาและ UX ที่ดี บางครั้งยังยกการพัฒนาคุณภาพเครือข่ายในอนาคตมาเป็นเหตุผลด้วย ในทางปฏิบัติ ความต้องการแบนด์วิดท์ต่ำยังคงเป็นข้อได้เปรียบเสมอ โดยเฉพาะในพื้นที่อินเทอร์เน็ตช้า พื้นที่ห่างไกล หรือสภาพแวดล้อมแบบ Comcast เป็นต้น

    • นี่เป็นวิศวกรรมแบบ happy path ในความเป็นจริง สำหรับคนที่ไม่ได้อยู่ใน happy path มันค่อนข้างหงุดหงิดมาก

    • กรณีหลักของ SSR ในปัจจุบันและอนาคตคือการโหลดหน้าแรก โดยเฉพาะบนมือถือ หลังจากนั้นที่เหลือคือการอัปเดตสถานะบนไคลเอนต์ทั้งหมด จึงต้องเร็วขึ้น ถ้าทักษะวิศวกรรมยังไม่พอ SSR ก็แทบไม่มีความหมายอะไร

  • ฉันพัฒนาซอฟต์แวร์จัดการงานโอเพนซอร์สสถาปัตยกรรม CRDT แบบ local-first แรงผลักดันในการพัฒนาคือไม่ต้องการฟังก์ชันการทำงานร่วมกัน และเครื่องมือเช่น Linear ดูซับซ้อนเกินความจำเป็นสำหรับการใช้งานของฉัน ข้อดีของสถาปัตยกรรมนี้คือ:

    1. เก็บข้อมูลไว้ที่เครื่อง ทำให้ตอบสนองเร็วมาก
    2. การ export/import ฐานข้อมูลทั้งหมดเป็นเรื่องง่ายมาก
    3. ตรรกะฝั่งเซิร์ฟเวอร์ถูกทำให้เบาลง จึงลด overhead ด้านประสิทธิภาพและความซับซ้อนในการพัฒนา และเขียน business logic ทั้งหมดฝั่งไคลเอนต์
    4. การพัฒนาฟีเจอร์ทำได้ง่ายขึ้น (แค่เขียน logic แบบ local เท่านั้น) ข้อเสียก็มี:
    5. ใช้ได้ดีกับข้อมูลแบบข้อความเท่านั้น, ควรใช้บริการ object storage อื่นๆ สำหรับภาพหรือไฟล์ใหญ่
    6. โค้ดซิงก์ต้องรอบคอบมาก (ถ้ามีบั๊กอาจเกิดปัญหารุนแรง)
    7. E2E encryption และ collaboration ซับซ้อนค่อนข้างมาก เทคโนโลยีที่ใช้:
    8. ใช้ Loro CRDT เป็นฐานจากโอเพ่นซอร์ส ทำให้ฉันโฟกัสแค่ business logic ได้
    9. ลูปการจัดการข้อมูล: การกระทำของผู้ใช้จะอัปเดต CRDT model และ export เป็น JSON เพื่ออัปเดต UI ในเวลาเดียวกันก็เก็บใน local DB และซิงก์กับเซิร์ฟเวอร์
    10. ชั้น local storage ถูก abstract ให้เป็น interface ร่วม list/save/read และใช้ตามแพลตฟอร์มเป็น IndexedDB (เบราว์เซอร์), filesystem (Electron), Capacitor Filesystem (iOS/Android)
    11. ทำ E2E encryption และ incremental sync คำนวณความต่างตามเวอร์ชันเซิร์ฟเวอร์/ไคลเอนต์แล้วเข้ารหัสด้วย AES ก่อนอัปโหลด เซิร์ฟเวอร์เก็บ base version + incremental patch เมื่อ patch สะสมมากขึ้น ก็อัปโหลดฐานข้อมูลทั้งฉบับที่เข้ารหัสเป็น base version ใหม่ เพื่อให้ patch ถัดๆ มารับภาระน้อยลง หากสนใจโครงการนี้ ดูที่ Hamsterbase Tasks

  • Jazz ให้ความประทับใจผมมากมาก DX ดีมากจนเขียนโค้ดได้เกือบ synchronous และ imperative ทำให้งานสนุกขึ้นมาก ทุกอย่างรู้สึกทันที และยังใช้ offline ได้ จึงให้ UX ที่ยอดเยี่ยม ปัญหาสำคัญที่สุดคือการ deploy และความคงทนระยะยาว คือข้อมูลเพิ่มขึ้นเรื่อยๆ (แต่จริงๆ แล้วไม่น่าจะเป็นปัญหาสำคัญเพราะไคลเอนต์ส่วนใหญ่ไม่จำเป็นต้องเห็นทั้งหมด) ปัญหาหลักคือยังไม่มีทางแก้ที่ดีสำหรับ public index ที่เปลี่ยนบ่อย โดยทฤษฎีแล้ว list of ids ที่อ่านได้สาธารณะก็เป็นไปได้ แต่คุยกับ Anselm ตอนหลังๆ แล้ว เขาบอกว่ากำลังแก้เรื่องนี้ โดยรวมแล้ว local-first มีต้นทุนไม่ต่ำ แต่ถ้า Jazz แก้จุดอ่อนหลักของศูนย์กลางเซิร์ฟเวอร์แบบดั้งเดิมได้ ก็แทบจะมาแทน Firestore ได้เกือบทุกด้าน

    • Jazz นั้นน่าตื่นเต้นจริงๆ DX ก็เหนือชั้นมาก ตอนที่ฉันใช้ มันรองรับแต่การเข้ารหัสแบบ passkey อย่างถูกต้อง จนบน Windows ใช้แทบไม่ได้นัก คิดว่า auth แบบดั้งเดิมก็น่าจะได้รับการรองรับในเร็วๆ นี้ สิ่งที่ดีที่สุดคือ E2E encryption และประสบการณ์ใช้งานที่สนุกมาก

  • ElectricSQL และ TanStack DB ทำได้ดีมาก แต่ว่าฉันสงสัยว่าทำไม local first ถึงเน้นมากในเว็บ สำหรับมือถือ ฉันคิดว่าความจำเป็น local first สูงกว่าเพราะประเด็นออฟไลน์ เมื่อใช้งานผ่านเว็บเบราว์เซอร์โดยทั่วไปแล้วมักเชื่อมต่ออินเทอร์เน็ตอยู่แล้ว ที่น่าสนใจคือ local-first เทคโนโลยีเหล่านี้ดูดีในเชิงแนวคิด แต่หากการแก้ความขัดแย้งไม่ดีก็จะแตกง่าย เป็นบทเรียนจากการทำ local-first บนมือถือ และนั่นคือเหตุผลที่ฉันเลือกใช้ CRDT

    • การสร้างแอป local-first ด้วยเว็บเทคโนโลยียากมากเมื่อเทียบกับ native แบบแทบไม่รู้จบ แอป native แค่ติดตั้งก็รองรับออฟไลน์ได้เป็นค่าเริ่มต้น เว็บต้องพึ่งลูกเล่นงูเห่าอย่าง AppManifest, ServiceWorker เพื่อเพิ่มความสามารถออฟไลน์ ใน native มีโค้ด C อายุ 30 ปีที่อ่าน/เขียนไฟล์บนดิสก์ได้อิสระ ถือว่าเป็นมาตรฐานพื้นฐาน ในเว็บ IndexedDB เป็นฝันร้าย, localStorage ใช้ไม่ได้เมื่อข้อมูลโต, OriginPrivateFileSystem ก็มีข้อจำกัดมาก ถ้าผู้ใช้ไม่เข้าเว็บไซต์อย่างน้อยเดือนละครั้ง Safari จะลบสถานะในบราวเซอร์ท้องถิ่นทิ้งไป แม้จะลอง JavaScript หรือ Emscripten build เป็น wasm ก็ยังต้องใช้ async web API หลบๆ ไปมา Apple มีโซลูชัน local+sync ที่สมบูรณ์แบบตั้งแต่ปี 2015 ด้วย CoreData + CloudKit ฝั่ง Google น่าจะมี Firebase เป็นตัวใกล้เคียงที่สุด

    • ในฐานะผู้พัฒนา Replicache และ Zero ฉันคิดเยอะว่าทำไมมันถึงโฟกัสเว็บ ยังไม่มีคำตอบชัดเจน แต่ขอแบ่งปันความเห็นตรงนี้:

      • ข้อดีเว็บ: feedback loop เร็ว, ไม่ต้องผ่าน gatekeeper และหลายอย่าง โดยรวมฉันชอบเว็บมากกว่า
      • แทบทั้งหมดของซอฟต์แวร์เดสก์ท็อป/ความสามารถผลิตภาพเกิดบนเว็บ และฉันต้องการความโต้ตอบทันทีในแอปประเภท productivity แต่เมื่อทุกคนย้ายไป client/server latency ก็ปรากฏทุกหนทุกแห่ง ฉันอยากเปลี่ยนสิ่งนั้น
      • ระบบเหล่านี้ต้องการตรรกะฐานข้อมูลกระจายที่ซับซ้อนฝั่งไคลเอนต์ ทำให้การเลือกภาษาเป็นประเด็น ดูเหมือนว่าถ้าพอร์ต C++ หรือ Rust มาเป็น wasm ก็พอ แต่ JS จึงยังเป็นภาษาที่ใช้ได้ทั่วไปที่สุด และเข้าถึงได้ดีที่สุดทั้งเว็บและมือถือ (เช่น RN)
      • แอป productivity ที่ซับซ้อนจริงๆ มักมีระบบฝั่งไคลเอนต์ที่ซับซ้อนเช่นนั้น จึงมักใช้เทคโนโลยีเว็บและโค้ดภาษาเดียวคือ JS

    • มือถือมีฟังก์ชันออฟไลน์ดั้งเดิมที่เข้มข้นกว่าเว็บ แต่การทำงานร่วมกันและ productivity จำนวนมากเกิดบนเว็บ ซึ่งเว็บเป็น environment ที่ขัดขวางมากกว่า มีเรื่องซับซ้อนเช่นซิงก์สถานะข้ามแท็บ, การลบพื้นที่เก็บข้อมูล และอื่นๆ ดังนั้น local first จึงพัฒนาไปทางเว็บมากกว่า

    • เครื่องยนต์ซิงก์มักมุ่งที่เว็บก่อนเพราะเทคโนโลยีเหล่านี้ยังอ่อนเยาว์และยังมีการอัปเดตมาก การอัปเดตแอปมือถือเป็นงานหนักมาก ในขณะที่อัปเดตเว็บแอปทำง่ายกว่าเยอะ ความสามารถ PWA ตอนนี้ก็ค่อนข้างดีขึ้นแล้ว iOS PWA ก็มี push notification แล้ว และเว็บแอปลักษณะมือถือก็ทำให้ฉันพอใจกับมันแล้ว

    • เรื่องหลักที่นี่ไม่ใช่ว่าเราจะใช้ฟีเจอร์อะไรได้ แต่เป็น ‘ความสนุก’ ที่รู้สึกได้จากโปรดักต์ที่เร็วมากและโต้ตอบไวผิดตาทั่วไป นั่นคือเหตุผลที่ฉันมุ่ง local-first

  • มุมมองด้านการร่วมมือของ local first/sync engine ดูเหมือนถูกพูดถึงไม่มากนัก ฉันกำลังทำโปรเจกต์ด้วย Zero เพื่อแทน Google Sheet ทางธุรกิจของเพื่อน กำลังอยู่ใน Google Meet คุยและเปิด Sheet พร้อมกันแบบเรียลไทม์เพื่อจัดการข้อมูล ก่อนหน้านี้ไม่เคยนึกว่าเคยคิดว่าทำแบบเว็บแอปได้ เคยสร้าง live UI ด้วย WebSocket มาพอสมควร แต่การแมปข้อมูลที่เข้ามาให้อยู่ตำแหน่งที่ถูกต้องและจัดการมันค่อนข้างซับซ้อน ถ้าข้อมูลเป็นเซลล์ระดับร้อยหรือพัน ช่องว่างความสับสนคาดไม่ถึง กับ Zero ก็ตอบได้: query เลือกข้อมูล, mutator เปลี่ยนข้อมูล แล้วซิงก์ให้ทุกคนเห็นทันทีเหมือนกัน เพราะฉะนั้นการพัฒนาจริงๆ กลายเป็นเรื่องสนุก

  • เมื่อฉันเห็น Google Docs ตอนออกตัว (ตอนอายุ 12) ว่ามีการซิงก์เรียลไทม์และ collaborative cursor แล้วคิดทันทีว่า อนาคตประสบการณ์เว็บจะเป็นงานร่วมมือทั้งหมดแบบนี้ ตอนนั้น cloud computing เป็นคำฮอต และฉันคิดผิดไปว่า collaboration เรียลไทม์คือความหมายของ cloud computing แต่สุดท้ายอนาคตแบบนั้นก็ไม่เกิดตามจริง ผ่านไป 20 ปีแล้ว เว็บโปรดักต์ส่วนใหญ่ก็ยังเป็น CRUD experience เหมือนเดิม (ไซต์นี้ก็เช่นกัน) ทุกครั้งก็เหมือนว่าจะถึงจุดที่ปฏิวัติแล้ว แต่ Meteor.js, React ฯลฯ ก็ยังไม่เป็นค่าเริ่มต้น ฉันยังคาดหวังให้มันเป็นสตรีมหลัก และยังเชื่อว่าอีกสักวันมันจะเกิด แต่อันที่จริงยากกว่าที่คิด และ tooling ยังไม่แพง/ไม่ครบสำหรับใช้ได้ทุกบริบท

    • ตัวอย่างงานร่วมมือเรียลไทม์คือ Discord (ซึ่งโดยสารจริงแทบไม่ต่างจาก IRC ยุค 90) และ Zoom (การประชุมวิดีโอทุกแบบ) HN เป็นเว็บแอปแบบ CRUD นี่คือข้อดี การอัปเดตแบบเรียลไทม์กลับทำให้เกิดความสับสนมากเกินไปในหลายครั้ง

    • ความเร็วแสงคือข้อจำกัดจริงๆ แสงใช้เวลา 56ms ในการเดินทางครึ่งโลก แต่สัญญาณจริงใช้เส้นทางยาวกว่า และช้าลงจาก conversion และอุปสรรคเสริมอีกมาก (load balancer, DDOS protection ฯลฯ) latency ยังแย่ลงกว่ายุคก่อนด้วยซ้ำ

    • ฉันเองก็เคยเห็นเสน่ห์ยุคแรกของความ real-time แล้ว แต่ความฝันนั้นดูเหมือนยังค้างอยู่ที่ไหนสักแห่ง อย่างไรก็ตาม ฉันยังทำเครื่องมือ messaging แบบ Google Docs (ไม่มีช่องพิมพ์/ปุ่มส่ง) แบบเรียลไทม์นี้อยู่: kraa.io/hackernews

  • ฉันเชื่อมั่นในอนาคตของ Local-First และ Sync-Engines ตารางสรุป landscape ของ local-first framework มีประโยชน์มาก โดยส่วนตัวฉันชอบ Triplit.dev มากที่สุด และมันเชื่อมกับ TanStack DB ได้ด้วย PowerSync และ NextGraph ก็เป็นตัวเลือกที่อยากไปสำรวจ ตอนนี้ชอบดู talk เกี่ยวกับ NextGraph ในวิดีโอของ LocalFirst Conf: YouTube วิดีโอ

    • สนใจว่ามีการรองรับการ migration ฐานข้อมูลของเครื่องมือเหล่านี้แค่ไหน ถ้าต้องรองรับไคลเอนต์ที่อยู่แบบไม่ติดต่อเซิร์ฟเวอร์ไปนานแล้ว และต้อง roll-forward migration จาก schema สภาพเก่าๆ มันจะกลายเป็นอุปสรรคใหญ่หรือไม่ พอแก้บั๊กส่วนหน้าผู้ใช้คนเดียวก็ยากอยู่แล้ว หากต้องคิดเรื่อง schema state ด้วย ก็ดูจะซับซ้อนเกินคาด

    • ทำให้นึกถึง Meteor

    • วิธีการพวกนี้ก็เป็นแนวทางเก่าด้วยซ้ำ

    • ต้องลอง Triplit แน่นอน และอยากรู้ว่าคุณเคยลอง InstantDB หรือยัง ฉันก็สนใจอยู่ แต่ยังไม่เคยได้ลอง

  • ฉันชอบแนวทางของ Electric มาก และติดตามมานาน Electric ทำให้ความซับซ้อนในการเขียนถูกส่งให้ developer และ API รับผิดชอบ จึงดูสะอาดขึ้น โซลูชันซิงก์สองทางโดยส่วนมากมักทำงานได้ดีแค่ในระดับแอป Todo ง่ายๆ เมื่อมีเรื่องสิทธิ์, วิวัฒนาการ business logic, migration และการเติบโตของโปรดักต์เข้ามาแล้ว ความคงทนย่อมเป็นคำถาม Electric รองรับการซิงก์เฉพาะการอ่านผ่าน view และให้การเขียนผ่าน API/rest/rpc เดิม จึงนำเข้าที่ยิ่งขึ้นโครงการเดิมได้ง่าย

  • ทำไม couchdb / pouchdb จึงไม่อยู่ในรายชื่อกันนะ มันยังเป็นเครื่องมือที่ทำงานได้ค่อนข้างดีอยู่

    • เพียงประโยคว่า "ทำงานได้" เป็นการประเมินต่ำไป โดยส่วนใหญ่เครื่องมือ local-first จะสูญเสียข้อมูลในบางจังหวะเมื่อเกิด conflict ในทางกลับกัน couchdb/pouchdb จะให้สิทธิ์สุดท้ายในการแก้ conflict แก่ developer ผู้คนในแวดวง CRDT มักให้ความสำคัญกับความสะดวกของ developer มากกว่าความปลอดภัยข้อมูล ซึ่งเป็น trade-off ที่แต่ละคนเลือกได้ตามรสนิยมและวัตถุประสงค์ของตัวเอง แต่ฉันยังไม่ค่อยเข้าใจว่าทำไมเรื่องความปลอดภัยข้อมูลถึงไม่ถูกพูดถึงบ่อย