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

• การใช้ 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 ใกล้จะเป็นเรื่องสำคัญมาก