ซอฟต์แวร์แบบ Local-first: เป็นเจ้าของข้อมูลของคุณแม้ในยุคคลาวด์ (2019)

 (inkandswitch.com)
2 คะแนน โดย GN⁺ 2025-07-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แอปคลาวด์ช่วยยกระดับการทำงานร่วมกันและการเข้าถึงจากหลายอุปกรณ์ได้อย่างมาก แต่สำเนาข้อมูลที่มีอำนาจตัดสินอยู่บนเซิร์ฟเวอร์ ทำให้ ความเป็นเจ้าของและการควบคุม ของผู้ใช้อ่อนลง
  • ซอฟต์แวร์แบบ local-first ใช้ ที่จัดเก็บข้อมูลในเครื่อง ของแล็ปท็อป แท็บเล็ต และโทรศัพท์เป็นสำเนาข้อมูลหลัก และจำกัดบทบาทของเซิร์ฟเวอร์ให้เป็นตัวช่วยเสริมสำหรับการซิงก์และการสำรองข้อมูล
  • แนวทางนี้มุ่งให้ได้ทั้งการตอบสนองที่รวดเร็ว การทำงานออฟไลน์ การซิงก์หลายอุปกรณ์ การทำงานร่วมกันแบบเรียลไทม์ การเก็บรักษาระยะยาว รวมถึงความปลอดภัยและความเป็นส่วนตัวโดยปริยาย
  • ไฟล์ อีเมล เว็บแอป การซิงก์แบบ Dropbox, Git, Firebase, CloudKit, Realm และ CouchDB ต่างมีข้อดีบางอย่าง แต่ไม่สามารถตอบโจทย์ทั้ง การทำงานร่วมกันและความเป็นเจ้าของข้อมูล ได้ครบถ้วน
  • โปรโตไทป์ที่ใช้ CRDT และ Automerge แสดงให้เห็นถึงความเป็นไปได้ แต่ยังมีโจทย์ที่ต้องแก้ เช่น ประสิทธิภาพ การสื่อสารผ่านเครือข่าย ความเสถียรของ P2P และ UI สำหรับเอกสารแบบกระจายศูนย์

ความขัดแย้งระหว่างการทำงานร่วมกันบนคลาวด์กับความเป็นเจ้าของข้อมูล

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

โมเดลพื้นฐานของซอฟต์แวร์แบบ local-first

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

อุดมคติ 7 ประการของ local-first

  • 1. ทำงานได้ทันทีโดยไม่มีสปินเนอร์

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

  • 2. งานที่ไม่ถูกขังอยู่ในอุปกรณ์เครื่องเดียว

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

  • 3. เครือข่ายเป็นตัวเลือก

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

  • 4. การทำงานร่วมกับเพื่อนร่วมงานอย่างราบรื่น

    • ซอฟต์แวร์เก่าแบบใช้ไฟล์ในเครื่องมักเกิดความขัดแย้งได้ง่ายเมื่อหลายคนแก้ไขไฟล์เดียวกันพร้อมกัน
    • แอปคลาวด์อย่าง Google Docs ทำให้ประสบการณ์ที่ผู้ใช้หลายคนแก้ไขเอกสารพร้อมกันโดยไม่ต้องกังวลเรื่องความขัดแย้งกลายเป็นเรื่องแพร่หลาย
    • อุดมคติของ local-first คือการรองรับ การทำงานร่วมกันแบบเรียลไทม์ ที่เทียบเท่าหรือดีกว่าแอปคลาวด์ที่ดีที่สุดในปัจจุบัน
    • โฟลว์ที่ผู้ใช้คนหนึ่งเสนอการเปลี่ยนแปลง แล้วผู้ใช้อีกคนตรวจทานและเลือกนำไปใช้ก็สำคัญเช่นกัน
      • suggesting mode ของ Google Docs
      • pull request ของ GitHub

  • 5. Long Now: การเข้าถึงได้ในระยะยาว

    • แง่มุมสำคัญของความเป็นเจ้าของข้อมูลคือ ต้องเข้าถึงได้ต่อไปอีกนานในอนาคต
    • แอปในเครื่องรุ่นเก่าสามารถใช้ต่อไปได้หากมีข้อมูลและสำเนาซอฟต์แวร์ที่รันได้ และยังสามารถรันระบบปฏิบัติการหรือคอมพิวเตอร์รุ่นเก่าด้วย virtual machine หรือ emulator ได้
    • แม้สื่อบันทึกข้อมูลจะเปลี่ยนไป ก็สามารถคัดลอกไฟล์ไปยังสื่อใหม่ได้
    • แอปคลาวด์พึ่งพาสมมติฐานว่าบริการจะยังให้บริการต่อไป และเปราะบางต่อการปิดบริการ การสูญหายของข้อมูล การเปลี่ยนแปลงราคาและฟีเจอร์ รวมถึงการบังคับอัปเกรดที่ไม่ต้องการ
    • ซอฟต์แวร์แบบ local-first เก็บข้อมูลและซอฟต์แวร์ที่ใช้อ่านและแก้ไขข้อมูลนั้นไว้ในเครื่อง จึงมีโอกาสเก็บรักษาระยะยาวได้มากขึ้น
    • plain text, JPEG และ PDF มีแนวโน้มสูงที่จะยังอ่านได้ไปอีกนาน และหอสมุดรัฐสภาสหรัฐฯ แนะนำ XML, JSON และ SQLite เป็นรูปแบบสำหรับเก็บรักษาชุดข้อมูล

  • 6. ความปลอดภัยและความเป็นส่วนตัวในฐานะค่าเริ่มต้น

    • แอปคลาวด์รวบรวมข้อมูลของผู้ใช้ทั้งหมดไว้ในฐานข้อมูลกลาง จึงเป็นเป้าหมายที่น่าดึงดูดสำหรับผู้โจมตี
    • พนักงานภายในหรือแฮกเกอร์ที่เข้าถึงเซิร์ฟเวอร์ได้อาจอ่านหรือดัดแปลงข้อมูลได้ และการละเมิดข้อมูลก็ยังเป็นความเสี่ยงที่พบได้บ่อย
    • เงื่อนไขของ Google Drive ระบุว่าระบบอัตโนมัติจะวิเคราะห์เนื้อหาของผู้ใช้เพื่อผลการค้นหาที่ปรับแต่งเฉพาะบุคคล และเพื่อตรวจจับสแปมกับมัลแวร์
    • ผู้ใช้ที่จัดการข้อมูลอ่อนไหว เช่น บุคลากรทางการแพทย์ นักข่าวสืบสวน หรือเจ้าหน้าที่รัฐและการทูต อาจพบว่าการใช้แอปคลาวด์ขัดแย้งกับข้อกำกับดูแลและหน้าที่รักษาความลับ
    • แอปแบบ local-first เก็บเฉพาะข้อมูลของผู้ใช้เองไว้บนอุปกรณ์ในเครื่องแต่ละเครื่อง และสามารถเก็บบนเซิร์ฟเวอร์ไว้เพียงสำเนาที่เข้ารหัสแบบต้นทางถึงปลายทางเท่านั้น
    • iMessage, WhatsApp, Signal, Keybase และ Tarsnap ถูกยกเป็นตัวอย่างของการเข้ารหัสแบบต้นทางถึงปลายทาง หรือการแชร์และสำรองไฟล์ที่เข้ารหัส

  • 7. ความเป็นเจ้าของและการควบคุมขั้นสุดท้าย

    • ในแอปคลาวด์ ผู้ให้บริการสามารถจำกัดการเข้าถึงของผู้ใช้ได้
    • ในเดือนตุลาคม 2017 ผู้ใช้ Google Docs บางรายถูกปิดกั้นการเข้าถึงเอกสาร เพราะระบบอัตโนมัติติดป้ายเอกสารผิดว่าเป็นอันตราย
    • ความเป็นเจ้าของในที่นี้ไม่ได้หมายถึงสิทธิ์ในทรัพย์สินทางปัญญา แต่หมายถึงความสามารถในการกระทำของผู้ใช้ อิสระในการตัดสินใจ และสิทธิ์ควบคุมข้อมูล
    • ในซอฟต์แวร์แบบ local-first ไบต์ที่ประกอบเป็นข้อมูลอยู่บนอุปกรณ์ของผู้ใช้ จึงมีอิสระที่จะประมวลผลด้วยวิธีใดก็ได้
    • ความเป็นเจ้าของข้อมูลมาพร้อมกับความรับผิดชอบในการดูแลสำรองข้อมูล ป้องกันข้อมูลสูญหาย รับมือแรนซัมแวร์ และจัดการคลังไฟล์
    • local-first ไม่จำเป็นต้องเป็นโอเพนซอร์สเสมอไป และซอฟต์แวร์เชิงพาณิชย์แบบปิดก็สามารถเข้าใกล้อุดมคตินี้ได้ หากไม่จำกัดการใช้ไฟล์อย่างจงใจ
    • ตัวอย่างของข้อจำกัดที่จงใจ ได้แก่ PDF ที่ห้ามพิมพ์, eBook reader ที่ขัดขวางการคัดลอกและวาง และ DRM ของไฟล์สื่อ

ข้อจำกัดของโมเดลการจัดเก็บและแชร์แบบเดิม

  • ไฟล์และไฟล์แนบอีเมล

    • ไฟล์แบบดั้งเดิมมีจุดแข็งในด้านการดูและแก้ไขแบบออฟไลน์ การควบคุมโดยผู้ใช้ การสำรองข้อมูล การเก็บรักษาระยะยาว และการเข้าถึงที่รวดเร็ว
    • การเข้าถึงจากหลายอุปกรณ์จำเป็นต้องใช้วิธีอย่างอีเมล, USB, NAS/NFS/FTP/rsync, การซิงก์ไฟล์แบบ Dropbox หรือ Git
    • ไฟล์แนบอีเมลเข้าใจง่าย เชื่อถือได้ และแม้ผ่านไป 6 เดือน ไฟล์แนบก็ยังคงอยู่ในรูปเดิม
    • จุดอ่อนคือ การทำงานร่วมกัน
      • โดยปกติแก้ไขไฟล์ได้เพียงคนเดียวในแต่ละครั้ง
      • หากหลายคนแก้ไขพร้อมกัน จำเป็นต้อง merge ด้วยมือ
      • เกิดความสับสนกับชื่อไฟล์ เช่น Budget draft 2 (Jane's version) final final 3.xls
    • แอปที่ต้องการนำแนวคิด local-first ไปใช้ สามารถเริ่มจากการรองรับการ export เป็นฟอร์แมตที่ใช้กันแพร่หลาย เช่น plain text, PDF, PNG, JPEG

  • เว็บแอป

    • เว็บแอปอย่าง Google Docs, Trello, Figma, Pinterest มีเบราว์เซอร์หรือแอปมือถือเป็น thin client และมี data store อยู่บนเซิร์ฟเวอร์
    • เว็บแอปได้สร้างมาตรฐานของการทำงานร่วมกันแบบเรียลไทม์ และมีข้อดีมากในการทำงานเป็นทีมเพราะดูเวอร์ชันล่าสุดได้จากทุกที่
    • ในทางกลับกัน ความเป็นเจ้าของและสิทธิ์ควบคุมลดลงอย่างมาก
      • ข้อมูลบนเซิร์ฟเวอร์เป็นแหล่งอ้างอิงหลัก ส่วนข้อมูลบนไคลเอนต์แทบจะเป็นแค่แคช
      • แม้เครือข่ายขาดหายไปชั่วครู่ ก็อาจถูกปิดกั้นการเข้าถึงระหว่างทำงานได้
      • การรองรับออฟไลน์แบบจำกัด เช่น Google Docs offline plugin ค่อนข้างเหมือนเป็นสิ่งที่นำมาติดเพิ่มภายหลังบนสถาปัตยกรรมที่มีเซิร์ฟเวอร์เป็นศูนย์กลาง
    • แม้เดสก์ท็อปไคลเอนต์แบบติดตั้งได้อย่าง Milanote และ Figma โดยเนื้อแท้ก็เป็นเบราว์เซอร์ที่นำมาห่อใหม่ จึงเผยให้เห็นข้อจำกัดเมื่อเกิดปัญหาเครือข่าย เซิร์ฟเวอร์ล่ม หรือบริการยุติ

  • Dropbox, Google Drive, Box, OneDrive

    • Dropbox, Google Drive, Box, OneDrive จะเฝ้าดูโฟลเดอร์ที่กำหนดบนเดสก์ท็อป และคัดลอกไฟล์ที่เปลี่ยนแปลงไปยังคอมพิวเตอร์เครื่องอื่น
    • เนื่องจากใช้ระบบไฟล์ในเครื่อง จึงเร็วและทำงานออฟไลน์ได้ และแม้บริการซิงก์จะยุติ ไฟล์บนดิสก์ในเครื่องก็ยังคงอยู่
    • หากฮาร์ดดิสก์เสีย สามารถกู้คืนได้โดยติดตั้งแอปแล้วรอให้ซิงก์ จึงมีข้อดีในแง่ความยั่งยืนระยะยาวและสิทธิ์ควบคุม
    • บนมือถือ iOS และ Android จะใกล้เคียงกับโมเดล thin client ที่ไม่ซิงก์ทั้งโฟลเดอร์ แต่ดึงไฟล์จากเซิร์ฟเวอร์ทีละไฟล์
    • ตัวเลือก “Make available offline” ต้องกำหนดไว้ล่วงหน้า ยุ่งยาก และทำงานเฉพาะเมื่อแอปเปิดอยู่
    • จุดที่อ่อนที่สุดคือ การทำงานร่วมกันแบบเรียลไทม์
      • หากไฟล์เดียวกันถูกแก้ไขจากสองอุปกรณ์ จะเกิด conflict ที่ต้อง merge ด้วยมือ
      • การซิงก์ไฟล์ได้ทุกรูปแบบเป็นข้อดีด้านความเข้ากันได้ แต่ก็เป็นจุดอ่อนเพราะไม่สามารถ merge แยกตามฟอร์แมตได้

  • Git และ GitHub

    • Git และ GitHub ใช้กันเป็นหลักในการทำงานร่วมกันบนซอร์สโค้ด และปัจจุบันถูกประเมินว่าเป็นแพ็กเกจซอฟต์แวร์ที่ใกล้เคียง local-first มากที่สุด
    • Git repository เป็นสำเนาข้อมูลหลักบนระบบไฟล์ในเครื่อง และไม่ขึ้นกับเซิร์ฟเวอร์
    • รองรับการทำงานออฟไลน์เต็มรูปแบบ ทำงานเร็ว ให้ผู้ใช้ควบคุมได้ และเหมาะกับการเก็บรักษาระยะยาว
    • GitHub ให้พื้นที่สำหรับการทำงานร่วมกัน การเข้าถึงจากหลายอุปกรณ์ การสำรองข้อมูล และการเก็บถาวร แต่ไม่ได้เข้ารหัส repository
    • จุดอ่อนใหญ่ของ Git มีสองอย่าง
      • ไม่มีการทำงานร่วมกันแบบ auto-merge เรียลไทม์ที่ละเอียดเหมือน Google Docs, Trello, Figma
      • ถูกปรับให้เหมาะกับโค้ดและข้อความแบบอิงบรรทัด ส่วนไฟล์ฟอร์แมตอื่นถูก扱เป็น binary blob ที่แก้ไขและ merge อย่างมีความหมายได้ยาก
    • เหตุผลที่วิศวกรซอฟต์แวร์จำนวนมากไม่ชอบ editor และสภาพแวดล้อมรันงานบนคลาวด์อย่าง Cloud9, Repl.it, Colaboratory เช่น “ช้า”, “ไม่ไว้ใจ”, “อยากเก็บโค้ดไว้บนระบบในเครื่อง” สอดคล้องกับแรงจูงใจของ local-first

ตัวเลือกในมุมมองโครงสร้างพื้นฐานสำหรับนักพัฒนา

  • เว็บแอปแบบ thin client

    • เป็นโมเดลที่เซิร์ฟเวอร์ Rails, Django, PHP, Node.js เก็บข้อมูลไว้ในฐานข้อมูล SQL หรือ NoSQL และให้บริการหน้าเว็บผ่าน HTTPS
    • ไม่ต้องติดตั้ง ผู้ใช้เพียงเข้า URL และความรับผิดชอบในการจัดการข้อมูลอยู่กับทีมวิศวกรรมและ DevOps ที่ deploy ระบบ
    • Meteor, ShareDB, Pusher, Ably, WebSocket ช่วยให้เพิ่มฟีเจอร์การทำงานร่วมกันแบบเรียลไทม์ลงในเว็บแอปได้ง่ายขึ้น
    • หากทุกการกระทำของผู้ใช้ต้องมีคำขอไปยังเซิร์ฟเวอร์ จะช้าลง และแม้จะใช้ JavaScript ฝั่งไคลเอนต์ซ่อนเวลา round trip ก็ยังพังได้ง่ายเมื่ออินเทอร์เน็ตไม่เสถียร
    • แม้จะมีความพยายามอย่าง manifest, localStorage, service worker, Progressive Web Apps แต่สถาปัตยกรรมเว็บแอปโดยพื้นฐานยังคงมีเซิร์ฟเวอร์เป็นศูนย์กลาง
    • เมื่อผู้ใช้ลบคุกกี้ในเบราว์เซอร์ บ่อยครั้งข้อมูลใน local storage ก็ถูกลบไปด้วย จึงไม่เหมาะกับการเก็บข้อมูลสำคัญในระยะยาว
    • หากผู้ใช้โฮสต์เว็บแอปโอเพนซอร์สเอง อาจปรับปรุงคุณลักษณะบางส่วนได้ แต่ผู้ใช้ส่วนใหญ่ไม่ได้อยากเป็นผู้ดูแลระบบ ดังนั้น self-hosting จึงไม่ใช่ทางเลือกที่สมจริงสำหรับคนส่วนใหญ่

  • แอปมือถือที่ใช้ local storage

    • แอป iOS และ Android ดาวน์โหลดไบนารีมาติดตั้งในเครื่อง แต่แอปจำนวนมากอย่าง Twitter, Yelp, Facebook เป็น thin client ที่ต้องมีเซิร์ฟเวอร์จึงทำงานได้
    • แอปที่บันทึกข้อมูลไว้บนอุปกรณ์ในเครื่องก่อนด้วย persistence layer อย่าง SQLite, Core Data หรือไฟล์ทั่วไป จะใกล้เคียงอุดมคติ local-first มากกว่า
    • Clue และ Things เป็นตัวอย่างที่เริ่มจากแอปผู้ใช้เดี่ยว แล้วเพิ่ม cloud backend เพื่อซิงก์หรือแชร์ข้ามอุปกรณ์
    • แอปแบบ thick client เหล่านี้ทำงานเร็วและใช้งานออฟไลน์ได้ เพราะการซิงก์กับเซิร์ฟเวอร์เกิดขึ้นเบื้องหลัง
    • เมื่อมีหลายอุปกรณ์หรือผู้ใช้ร่วมงานหลายคนแก้ไขข้อมูล ความยากจะเพิ่มขึ้น
    • นักพัฒนาแอปมือถือโดยทั่วไปเป็นผู้เชี่ยวชาญด้านการพัฒนาแอปสำหรับผู้ใช้ปลายทาง ไม่ใช่ผู้เชี่ยวชาญระบบกระจายศูนย์
    • อัลกอริทึม diff·merge·แก้ conflict แบบเฉพาะกิจมักมีความน่าเชื่อถือต่ำและเปราะบาง

  • Firebase, CloudKit, Realm

    • Firebase เป็น mobile BaaS ที่ผสานฐานข้อมูลบนอุปกรณ์ในเครื่อง บริการฐานข้อมูลบนคลาวด์ และการซิงก์ระหว่างทั้งสองฝั่ง
    • Firebase รองรับการแชร์หลายอุปกรณ์และการใช้งานออฟไลน์ แต่เพราะเป็นบริการโฮสติ้งแบบปิด จึงได้คะแนนต่ำด้านความเป็นส่วนตัวและความยั่งยืนระยะยาว
    • Parse ถูก Facebook เข้าซื้อแล้วปิดบริการในปี 2017 ทำให้แอปที่พึ่งพา Parse ต้องย้ายไปยัง backend อื่น
    • Firebase console มอบประสบการณ์ที่ดีให้นักพัฒนาในการดู แก้ไข และลบข้อมูล แต่ผู้ใช้ไม่มีเครื่องมือเข้าถึง จัดการ หรือดูแลข้อมูลในระดับเดียวกัน
    • Apple CloudKit มอบประสบการณ์คล้าย Firebase ให้แอปที่จำกัดอยู่บน iOS และ Mac ได้
      • key-value store และการซิงก์
      • ฟังก์ชันออฟไลน์ที่ดี
      • ลดความยุ่งยากในการสร้างบัญชีและล็อกอิน เพราะฝังมากับแพลตฟอร์ม
    • Realm ได้รับความนิยมในฐานะไลบรารี local persistence สำหรับ iOS และ Realm Object Server เป็นโอเพนซอร์สและ self-host ได้ จึงลดความเสี่ยงจากการผูกติดกับบริการ

  • CouchDB

    • CouchDB ได้รับความสนใจจากแนวทาง multi-master replication ที่หลายเครื่องมีสำเนาฐานข้อมูลสมบูรณ์ และแต่ละ replica สามารถสร้างการเปลี่ยนแปลงได้อย่างอิสระ
    • Cloudant เป็นเวอร์ชันโฮสต์ ส่วน PouchDB และ Hoodie ใช้โปรโตคอลซิงก์เดียวกันและออกแบบให้รันบนอุปกรณ์ของผู้ใช้ปลายทาง
    • ในเชิงปรัชญา CouchDB ใกล้เคียงกับหลักการ local-first แต่ในขณะเดียวกัน ข้อมูลที่ถูกแก้พร้อมกันต้องให้โค้ดแอปพลิเคชันแก้ conflict อย่างชัดเจน
    • ในแอปทำงานร่วมกันแบบละเอียดที่ทุกการกดแป้นอาจเป็นการเปลี่ยนแปลงแยกชิ้นเหมือน Google Docs การเขียนโค้ดแก้ conflict ให้ถูกต้องทำได้ยาก
    • เหตุผลที่ CouchDB ไม่ถูกนำไปใช้อย่างแพร่หลาย ได้แก่ scalability ของ DB แยกตามผู้ใช้ การฝัง JavaScript client ในแอป native บน iOS·Android การแก้ conflict และความไม่คุ้นเคยของโมเดล query แบบ MapReduce

CRDT และเทคโนโลยีพื้นฐานที่ดีกว่า

  • เลเยอร์ข้อมูลสำหรับการพัฒนาแอปพลิเคชันแบบเดิมยังไม่สามารถตอบโจทย์อุดมคติของ local-first ได้ครบทั้งหมด
  • Ink & Switch เริ่มทำวิจัยตั้งแต่ 3 ปีก่อนเพื่อหาทางออก และเสนอ Conflict-free Replicated Data Types หรือ CRDT ว่าเป็นรากฐานที่มีแนวโน้มดี
  • CRDT เป็นโครงสร้างข้อมูลอเนกประสงค์ที่เกิดขึ้นจากงานวิจัยวิทยาการคอมพิวเตอร์เชิงวิชาการในปี 2011
  • มันเก็บสถานะของเอกสารเหมือนโครงสร้างข้อมูลอย่างแฮชแมปหรือลิสต์ แต่คำนึงถึงสภาพแวดล้อมแบบผู้ใช้หลายคนมาตั้งแต่ต้น
  • โปรแกรมแก้ไขข้อความ สเปรดชีต และแอปกราฟิกเวกเตอร์ต่างก็รักษาสถานะเอกสารของตนไว้ในรูปโครงสร้างข้อมูล และในแอปสำหรับผู้ใช้หลายคนแบบทำงานร่วมกันสามารถแทนที่สิ่งนี้ด้วย CRDT ได้

  • วิธีการ merge ของ CRDT

    • ผู้ใช้สามารถดูและแก้ไขสถานะแอปพลิเคชันบนอุปกรณ์ภายในเครื่องได้แม้อยู่ในสถานะออฟไลน์
    • CRDT ติดตามการเปลี่ยนแปลง และซิงก์กับอุปกรณ์อื่นในเบื้องหลังเมื่อมีเครือข่าย
    • หากเพิ่มรายการสิ่งที่ต้องทำใหม่พร้อมกันจากอุปกรณ์คนละเครื่อง สถานะที่ merge แล้วจะมีรายการที่เพิ่มทั้งหมดรวมอยู่ในลำดับที่สอดคล้องกัน
    • การเปลี่ยนแปลงพร้อมกันที่เกิดกับออบเจ็กต์คนละตัวสามารถ merge ได้ง่าย
    • กรณีที่แก้อัตโนมัติได้ยากคือเมื่อผู้ใช้หลายคนอัปเดตพร็อพเพอร์ตีเดียวกันของออบเจ็กต์เดียวกันพร้อมกัน ซึ่ง CRDT จะติดตามค่าที่ขัดแย้งกันไว้ และปล่อยให้แอปหรือผู้ใช้เป็นผู้แก้ไข
    • CRDT คล้ายกับ Git แต่ทำงานกับชนิดข้อมูลที่หลากหลายกว่าไฟล์ข้อความ
    • ช่องทางการซิงก์จะเป็นอะไรก็ได้ เช่น เซิร์ฟเวอร์ การเชื่อมต่อ P2P, Bluetooth หรือแฟลชไดรฟ์ USB
    • หน่วยของการเปลี่ยนแปลงอาจเล็กได้ถึงระดับการกดคีย์ครั้งเดียว ทำให้ทำงานร่วมกันแบบเรียลไทม์ในสไตล์ Google Docs ได้ และยังสามารถส่งเป็นก้อนใหญ่เหมือน Git pull request ได้ด้วย

  • Automerge และ Hypermerge

    • Ink & Switch พัฒนา Automerge ซึ่งเป็น implementation ของ CRDT แบบโอเพนซอร์สบน JavaScript
    • Automerge อิงจากงานวิจัย JSON CRDT
    • เมื่อนำ Automerge มารวมกับ Dat networking stack จึงเกิดเป็น Hypermerge
    • ยังพูดได้ยากว่าไลบรารีเหล่านี้ทำให้อุดมคติ local-first เป็นจริงได้อย่างสมบูรณ์ และยังต้องมีงานอีกมาก
    • CRDT มีศักยภาพที่จะเป็นเทคโนโลยีพื้นฐานของซอฟต์แวร์ทำงานร่วมกันที่ผู้ใช้ถือครองความเป็นเจ้าของข้อมูล เช่นเดียวกับ packet switching ของอินเทอร์เน็ต หรือ capacitive touchscreen ของสมาร์ตโฟน

โปรโตไทป์ของ Ink & Switch

  • อัลกอริทึมและการพิสูจน์ทฤษฎีของ CRDT มีความก้าวหน้าในแวดวงวิชาการ แต่การใช้งานในอุตสาหกรรมยังมีน้อย และส่วนใหญ่ใช้ในคอมพิวติ้งที่มีเซิร์ฟเวอร์เป็นศูนย์กลาง
  • ตัวอย่างระบบที่มีเซิร์ฟเวอร์เป็นศูนย์กลางและใช้ CRDT ได้แก่ Azure Cosmos DB, Redis, Riak, Weave Mesh, SoundCloud Roshi และ Facebook OpenR
  • Ink & Switch สร้างโปรโตไทป์แอปทำงานร่วมกันแบบ local-first สำหรับงานสร้างสรรค์ ที่ใช้ CRDT บนอุปกรณ์ของผู้ใช้ปลายทาง
  • การทดลองครอบคลุมคำถามสามข้อ
    • ความเป็นไปได้ทางเทคนิค: CRDT ใกล้เคียงกับซอฟต์แวร์จริงได้แค่ไหน
    • ประสบการณ์ผู้ใช้: เป็นไปได้หรือไม่ที่จะทำงานร่วมกันแบบเรียลไทม์เหมือน Google Docs และทำงานร่วมกันแบบอะซิงโครนัสที่เป็นมิตรกับออฟไลน์เหมือน Git โดยไม่มีเซิร์ฟเวอร์กลางที่มีอำนาจควบคุม
    • ประสบการณ์นักพัฒนา: เลเยอร์ข้อมูล CRDT ต่างจาก SQL DB, ไฟล์ซิสเต็ม และ Core Data อย่างไร
  • โปรโตไทป์ทั้งสามสร้างด้วย Electron, JavaScript และ React และมองว่าการเป็นซอฟต์แวร์ที่ดาวน์โหลดและติดตั้งได้มีความสำคัญต่อความรู้สึกเป็นเจ้าของ

  • Trellis

    • Trellis เป็น Kanban board ที่จำลองจาก Trello
    • ทดลองใช้ WebRTC เป็นเลเยอร์สื่อสารผ่านเครือข่าย
    • ออกแบบประวัติการเปลี่ยนแปลงที่ได้แรงบันดาลใจจาก Git และ “See New Changes” ของ Google Docs
    • ผู้ใช้สามารถดูงานบน Kanban board และย้อนกลับไปดูสถานะก่อนหน้าของเอกสารได้

  • Pixelpusher

    • Pixelpusher เป็นโปรแกรมวาดภาพร่วมกันที่เพิ่มประสบการณ์ทำงานร่วมกันแบบเรียลไทม์คล้าย Figma ให้กับ Pixel Art to CSS ของ Javier Valencia
    • ทดลองการสื่อสารผ่านเครือข่ายด้วยไลบรารี P2P ของโปรเจกต์ Dat
    • ทดลอง URL สำหรับแชร์เอกสาร, branch/merge แบบภาพที่ได้แรงบันดาลใจจาก Git, การแก้ conflict โดยไฮไลต์พิกเซลที่ขัดแย้งเป็นสีแดง และการระบุตัวผู้ใช้ขั้นพื้นฐานด้วยอวาตาร์ที่ผู้ใช้วาดเอง

  • PushPin

    • PushPin เป็น mixed media canvas workspace คล้าย Miro หรือ Milanote
    • เป็นโปรเจกต์ที่สามที่อิง Automerge และมีความสมบูรณ์สูงสุดในบรรดาโปรโตไทป์ทั้งสาม
    • การใช้งานจริงโดยทีมและผู้ใช้ทดสอบภายนอกทำให้ underlying data layer รับภาระมากขึ้น
    • ทดลองเอกสารแชร์ที่ซ้อนกันและเชื่อมโยงกัน, renderer หลายแบบสำหรับเอกสาร CRDT, ระบบตัวตนที่ก้าวหน้าขึ้นรวมถึงโมเดล outbox และการแชร์ข้อมูลชั่วคราวอย่างการไฮไลต์สิ่งที่เลือก

ผลลัพธ์ที่ได้จากโปรโตไทป์

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

  • เทคโนโลยี CRDT ใช้งานได้จริง

    • ความน่าเชื่อถือของ Automerge ดีกว่าที่คาดไว้
    • นักพัฒนาแอปในทีมสามารถผสานไลบรารีได้ค่อนข้างง่าย และการ merge ข้อมูลอัตโนมัติแทบทุกครั้งเป็นไปอย่างเข้าใจง่ายและราบรื่น

  • ประสบการณ์ผู้ใช้แบบออฟไลน์ดี

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

  • เข้ากับโมเดล FRP ของ React ได้ดี

    • โมเดล Functional Reactive Programming ของ React เข้ากับ CRDT ได้ดี
    • ในชั้นข้อมูลที่ใช้ CRDT เอกสารจะรับทั้งอินพุตจากผู้ใช้ในเครื่อง และการเปลี่ยนแปลงจากผู้ใช้หรืออุปกรณ์อื่นที่มาจากเครือข่ายพร้อมกัน
    • โมเดล FRP ซิงก์สถานะแอปพลิเคชันที่มองเห็นได้กับ underlying state ของเอกสารที่แชร์ได้อย่างเสถียร
    • นักพัฒนาไม่ต้องทำงานยุ่งยากในการติดตามการเปลี่ยนแปลงที่มาจากผู้ใช้อื่นและปรับให้เข้ากับหน้าจอปัจจุบัน
    • หากให้การเปลี่ยนแปลงสถานะทั้งหมดผ่านฟังก์ชัน reducer เดียว ก็จะส่งการเปลี่ยนแปลงในเครื่องที่เกี่ยวข้องไปยังผู้ใช้อื่นได้ง่ายขึ้นด้วย

  • ความขัดแย้งรุนแรงน้อยกว่าที่คาดไว้

    • ผู้ใช้พบ conflict ระหว่างทำงานร่วมกันไม่บ่อย และกลไกการแก้ไขทั่วไปทำงานได้ดี
    • Automerge ติดตามการเปลี่ยนแปลงในระดับละเอียดและคำนึงถึงความหมายของชนิดข้อมูล
    • หากผู้ใช้สองคนแทรกรายการพร้อมกันในตำแหน่งเดียวกันของอาร์เรย์ ระบบจะรวมสองรายการเข้าด้วยกันในลำดับที่กำหนดได้แน่นอน
    • ระบบจัดการเวอร์ชันข้อความอย่าง Git อาจมองกรณีนี้เป็น conflict ที่ต้องแก้ไขด้วยมือ
    • ผู้ใช้มีสัญชาตญาณเกี่ยวกับการทำงานร่วมกัน จึงมีกรณีที่แบ่งพื้นที่ทำงานกันโดยนัยเพื่อไม่ให้แก้ไขส่วนเดียวกันพร้อมกัน
    • ในแอป Kanban หากผู้ใช้คนหนึ่งคอมเมนต์ในการ์ด และอีกคนย้ายการ์ดไปยังคอลัมน์อื่น การเปลี่ยนแปลงทั้งสองอย่างจะถูกสะท้อนทั้งหมด
    • conflict จะเกิดขึ้นเฉพาะเมื่อแก้ไขคุณสมบัติเดียวกันของอ็อบเจกต์เดียวกันพร้อมกันเท่านั้น เช่น กรณีที่ผู้ใช้สองคนเปลี่ยนตำแหน่งของอ็อบเจกต์รูปภาพเดียวกันพร้อมกัน
    • ในโปรโตไทป์ semantics การ merge พื้นฐานของ Automerge ก็เพียงพอ และไม่พบกรณีที่ต้องใช้ semantics แบบปรับแต่งเอง

  • การแสดงภาพประวัติเอกสารมีความสำคัญ

    • ในระบบทำงานร่วมกันแบบกระจาย การเปลี่ยนแปลงจากผู้ใช้คนอื่นจำนวนมากอาจมาถึงได้ทุกเมื่อ
    • เนื่องจากไม่มีเซิร์ฟเวอร์กลางคอยเป็นตัวกลางของการเปลี่ยนแปลง จึงต้องมีเครื่องมือเพื่อทำความเข้าใจเส้นทางที่ทำให้เอกสารมาถึงสถานะปัจจุบัน เวอร์ชันที่มีอยู่ และที่มาของการมีส่วนร่วม
    • Trellis ทดลองอินเทอร์เฟซ “time travel” ที่ให้ผู้ใช้ย้อนดูสถานะในอดีตของเอกสารที่ถูก merge แล้วได้
    • ยังทดลองวิธีไฮไลต์องค์ประกอบการเปลี่ยนแปลงที่เพิ่งได้รับโดยอัตโนมัติด้วย

  • การแชร์ URL เป็นธรรมชาติ

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

  • ระบบ P2P ไม่ได้แบ่งเป็นออนไลน์·ออฟไลน์อย่างเรียบง่าย

    • ระบบรวมศูนย์มักนิยามสถานะ “up” หรือ “down” จากการมีการเชื่อมต่อกับเซิร์ฟเวอร์ที่เสถียรหรือไม่
    • ในระบบกระจาย ผู้ใช้แต่ละคนอาจมีมุมมองต่างกันตามว่ามีข้อมูลอะไร แชร์อะไร และยอมรับอะไร
    • การแก้ไขที่อยู่ในแล็ปท็อปบนเครื่องบินสามารถถูกกระจายไปยังผู้ใช้อื่นได้เมื่อเชื่อมต่อหลังลงจอด
    • ผู้ใช้อื่นอาจรับการเปลี่ยนแปลงนั้นทั้งหมด บางส่วน หรือไม่รับเลยเข้าสู่เวอร์ชันเอกสารของตน
    • เช่นเดียวกับ repository ของ Git “master” ของผู้ใช้รายหนึ่งจะกลายเป็นฟังก์ชันของเวลาล่าสุดที่สื่อสารกับผู้ใช้รายอื่น
    • เอกสารแบบกระจายให้สิทธิ์ควบคุมข้อมูลแก่ผู้ใช้ แต่ในมุมมอง UI จริง ๆ แล้วหมายความว่าอย่างไรยังต้องวิจัยเพิ่มเติม

  • ประวัติการเปลี่ยนแปลงที่ยาวสร้างปัญหาด้านประสิทธิภาพ

    • เมื่อนำ PushPin ไปใช้กับเอกสารจริงอย่างการวางแผนสปรินต์ ประสิทธิภาพและการใช้หน่วยความจำ·ดิสก์กลายเป็นปัญหาอย่างรวดเร็ว
    • CRDT เก็บประวัติทั้งหมด รวมถึงการแก้ไขข้อความระดับตัวอักษร
    • อาจมีใครบางคนกลับมาเชื่อมต่อกับเอกสารอีกครั้งหลังผ่านไป 6 เดือนและต้อง merge การเปลี่ยนแปลงตั้งแต่จุดนั้น จึงไม่สามารถตัดประวัติทิ้งได้ง่าย ๆ
    • การปรับแต่งประสิทธิภาพของ Automerge ยังดำเนินต่อไป และยังเป็นพื้นที่งานสำคัญที่กำลังดำเนินอยู่

  • การสื่อสารผ่านเครือข่ายยังไม่ได้รับการแก้ไข

    • อัลกอริทึม CRDT จัดการเฉพาะการ merge ข้อมูลเท่านั้น ไม่ได้จัดการวิธีที่การแก้ไขของผู้ใช้อื่นจะมาถึงคอมพิวเตอร์เครื่องเดียวกันทางกายภาพ
    • ในการทดลอง ได้ลองใช้ WebRTC, การทำ sneakernet โดยคัดลอกไฟล์ด้วย Dropbox และ USB key, ความเป็นไปได้ของโปรโตคอล IPFS และไลบรารี P2P Hypercore ของ Dat
    • CRDT ไม่จำเป็นต้องใช้ชั้นเครือข่าย P2P เสมอไป และสามารถสื่อสารผ่านเซิร์ฟเวอร์ได้ด้วย
    • หากต้องการบรรลุเป้าหมายระยะยาวของ local-first อย่างสมบูรณ์ โซลูชันแบบกระจายศูนย์ที่อยู่ได้นานกว่าบริการแบ็กเอนด์ของ vendor คือเป้าหมายสุดท้ายที่สมเหตุสมผล
    • เทคโนโลยี P2P ยังไม่พร้อมสำหรับ production โดยเฉพาะ NAT traversal มีความน่าเชื่อถือต่ำขึ้นอยู่กับเราเตอร์หรือโทโพโลยีเครือข่าย
    • ประสบการณ์การทำงานร่วมกันแบบเรียลไทม์โดยให้คอมพิวเตอร์เชื่อมต่อกันโดยตรงโดยไม่ต้องเข้าถึงอินเทอร์เน็ต แสดงให้เห็นศักยภาพอย่างมากในโลกที่พึ่งพา API ส่วนกลาง

  • เซิร์ฟเวอร์คลาวด์ยังคงมีบทบาทสนับสนุน

    • โปรโตไทป์การทำงานร่วมกันแบบเรียลไทม์อย่าง PushPin สามารถแชร์เอกสารได้โดยไม่ต้องมีเซิร์ฟเวอร์ตัวกลาง ซึ่งดีต่อความเป็นส่วนตัวและความเป็นเจ้าของ
    • แต่หากผู้ใช้แชร์เอกสารแล้วปิดแล็ปท็อปก่อนที่อีกฝ่ายจะเชื่อมต่อ ผู้ใช้ทั้งสองไม่ได้ออนไลน์พร้อมกัน จึงเชื่อมต่อกันไม่ได้
    • ในโลก local-first เซิร์ฟเวอร์สามารถทำหน้าที่เป็น cloud peer ไม่ใช่อำนาจส่วนกลาง
      • เก็บสำเนาเอกสารไว้ แล้วส่งต่อเมื่อ peer อื่นออนไลน์
      • จัดให้มีตำแหน่งสำหรับ archive และ backup
      • เป็น bridge ไปยัง API เซิร์ฟเวอร์แบบดั้งเดิม เช่น พยากรณ์อากาศหรือราคาหุ้น
      • ให้บริการ burst computing เช่น การเรนเดอร์วิดีโอด้วย GPU ทรงพลัง
    • ความแตกต่างระหว่างระบบดั้งเดิมกับระบบ local-first ไม่ใช่ว่ามีเซิร์ฟเวอร์หรือไม่ แต่คือเซิร์ฟเวอร์ไม่ได้เป็นแหล่งความจริง หากทำหน้าที่สนับสนุน

งานที่จำเป็นต่อจากนี้

  • นักวิจัยด้านระบบกระจายศูนย์และภาษาโปรแกรมมิง

    • งานวิจัยด้าน CRDT และเทคโนโลยี P2P สามารถมีส่วนช่วยอย่างมากต่อซอฟต์แวร์แบบ local-first
    • ปัจจุบันงานวิจัย CRDT มักตั้งสมมติฐานเป็นโมเดลที่ผู้ร่วมงานทุกคนใช้การแก้ไขกับเวอร์ชันเอกสารเดียวกันทันที
    • แอป local-first ในโลกจริงต้องสามารถปฏิเสธการแก้ไขจากผู้ร่วมงานคนอื่น หรือสร้างการเปลี่ยนแปลงส่วนตัวในเวอร์ชันของเอกสารที่ไม่ได้แชร์ได้
    • ยังขาดงานวิจัยที่ขยายแนวคิดของระบบควบคุมซอร์สแบบกระจายศูนย์ เช่น branch, fork, rebase ไปสู่โมเดลการทำงานร่วมกันที่มีเอกสารหลายเวอร์ชันและหลาย branch อยู่ควบคู่กัน
    • ชนิดข้อมูล, การย้ายสคีมา และความเข้ากันได้ก็เป็นประเด็นสำคัญเช่นกัน
      • ผู้ร่วมงานแต่ละคนอาจใช้เวอร์ชันและฟีเจอร์ของแอปที่แตกต่างกัน
      • เนื่องจากไม่มีเซิร์ฟเวอร์ DB ส่วนกลาง จึงไม่มีสคีมา “ปัจจุบัน” ที่เป็นแหล่งอ้างอิงสูงสุดของข้อมูล
      • ระหว่างที่รูปแบบข้อมูลวิวัฒนาการ แอปหลายเวอร์ชันต้องทำงานร่วมกันได้อย่างปลอดภัย

  • นักวิจัย HCI

    • ในระบบรวมศูนย์มีตัวอย่างมากมายของการแสดงสถานะการซิงก์กับเซิร์ฟเวอร์ แต่ระบบกระจายศูนย์มีปัญหา UI แบบใหม่
    • จำเป็นต้องศึกษาว่าในระบบที่ผู้ใช้ทุกคนอาจมีสำเนาข้อมูลต่างกัน จะสื่อสารสถานะออนไลน์·ออฟไลน์ และพร้อมใช้งาน·ไม่พร้อมใช้งานอย่างไร
    • เมื่อสามารถทำงานร่วมกับโหนดอื่นได้โดยตรงโดยไม่ต้องพึ่งอินเทอร์เน็ตวงกว้าง ความหมายของคำว่า “ออนไลน์” ก็เปลี่ยนไปด้วย
    • เอกสารทุกฉบับอาจมีประวัติเวอร์ชันที่ซับซ้อนเพียงจากการใช้งานในชีวิตประจำวัน จึงต้องมี UI ที่ช่วยให้ผู้ใช้เข้าใจเวอร์ชัน การยอมรับการเปลี่ยนแปลง และกระบวนการก่อรูปของเอกสาร
    • ปัจจุบันการจัดการการเปลี่ยนแปลงมีโมเดล diff·patch แบบซอร์สโค้ด และโมเดล suggestion·comment แบบ Google Docs เป็นกระแสหลัก
    • วิธีทั่วไปในการขยายแนวคิดนี้ไปยังรูปแบบข้อมูลที่ไม่ใช่ข้อความยังเป็นปัญหาที่ยังเปิดอยู่
    • ใน local-first ไม่สามารถห้ามผู้ใช้ที่มีข้อมูลอยู่แล้วแก้ไขข้อมูลในเครื่องได้ และแนวคิดเรื่องสิทธิ์จะเปลี่ยนไปเป็นการที่ผู้ใช้คนอื่นเลือกว่าจะติดตามการเปลี่ยนแปลงนั้นหรือไม่

  • ผู้ปฏิบัติงานจริง

    • วิศวกร นักออกแบบ ผู้จัดการผลิตภัณฑ์ และนักพัฒนาอิสระที่สร้างซอฟต์แวร์สำหรับโปรดักชัน สามารถเริ่มก้าวทีละขั้นไปสู่อนาคตแบบ local-first ได้
    • เพื่อให้แอปรวดเร็ว ควรใช้การแคชเชิงรุกและดาวน์โหลดล่วงหน้าเพื่อลด spinner เมื่อเปิดเอกสาร และโดยพื้นฐานแล้วสามารถเชื่อถือแคชในเครื่องได้
    • อุปกรณ์หลายเครื่องสามารถรองรับได้ค่อนข้างง่ายด้วยโครงสร้างพื้นฐานการซิงก์อย่าง Firebase และ iCloud แต่มีความกังวลเรื่องความยืนยาวและความเป็นส่วนตัว
    • สำหรับการใช้งานออฟไลน์บนเว็บ Progressive Web Apps, Service Workers และ app manifest สามารถช่วยได้
    • การทดสอบแอปทำได้โดยปิด WiFi หรือเปลี่ยนเงื่อนไขเครือข่ายด้วยเครื่องมืออย่าง Chrome DevTools network condition simulator และ iOS network link conditioner
    • สำหรับการทำงานร่วมกัน นอกจาก CRDT แล้ว Operational Transformation ที่ใช้งานใน ShareDB เป็นต้น เป็นเทคโนโลยีที่เป็นที่ยอมรับมากกว่า
    • เพื่อการเก็บรักษาระยะยาว ควรส่งออกเป็นรูปแบบที่เสถียรอย่าง JSON, PDF ได้ง่าย
      • การส่งออกจำนวนมากแบบ Google Takeout
      • การสำรองข้อมูลต่อเนื่องด้วยรูปแบบไฟล์ที่เสถียรของ GoodNotes
      • การดาวน์โหลดเอกสาร JSON ของ Trello
    • ด้านความเป็นส่วนตัว ต้องแจ้งให้ผู้ใช้ทราบอย่างชัดเจนว่าข้อมูลถูกเก็บไว้เฉพาะบนอุปกรณ์ หรือถูกส่งไปยังแบ็กเอนด์
    • เพื่อให้ผู้ใช้มีอำนาจควบคุม การสำรอง คัดลอก และลบเอกสารภายในแอปควรทำได้ง่าย โดยมีกรณีของ Google Docs ที่นำการทำงานพื้นฐานแบบไฟล์ซิสเต็มกลับมาสร้างใหม่ผ่าน Google Drive เป็นตัวอย่าง

โอกาสสำหรับสตาร์ทอัพและบทสรุป

  • สำหรับผู้ก่อตั้งที่ต้องการสร้างโครงสร้างพื้นฐานสำหรับนักพัฒนา “Firebase for CRDTs” ถูกเสนอเป็นโอกาสทางตลาดที่น่าสนใจ
  • สตาร์ทอัพเช่นนั้นควรมอบประสบการณ์นักพัฒนาที่ดี และไลบรารีความคงทนของข้อมูลในเครื่องแบบ SQLite หรือ Realm
  • ต้องรองรับ iOS, Android, Windows, Mac, Linux, Electron และ Progressive Web Apps
  • สิทธิ์ควบคุมของผู้ใช้ ความเป็นส่วนตัว การรองรับหลายอุปกรณ์ และการทำงานร่วมกัน ควรถูกบรรจุเป็นพื้นฐาน
  • บททดสอบชี้ขาดของความสำเร็จคือ แม้เซิร์ฟเวอร์ทั้งหมดจะปิดตัวลง แอปของลูกค้ายังคงทำงานต่อไปได้ถาวรหรือไม่
  • ซอฟต์แวร์คลาวด์มอบการทำงานร่วมกันและแอปล่าสุดที่เข้าถึงได้จากทุกที่ แต่การวางความเป็นเจ้าของข้อมูลไว้บนเซิร์ฟเวอร์ทำให้ผู้ใช้กลายเป็นเหมือนผู้เช่าข้อมูลของตนเอง
  • แนวทาง local-first แสดงให้เห็นว่าผู้ใช้สามารถรักษาความเป็นเจ้าของและอำนาจควบคุมข้อมูลไว้ได้ พร้อมกับได้การทำงานร่วมกันและการเข้าถึงแบบคลาวด์
  • การนำไปใช้จริงยังต้องการการรองรับออฟไลน์ การใช้ที่เก็บข้อมูลบนอุปกรณ์ การปรับปรุงอัลกอริทึม โมเดลโปรแกรมมิง และอินเทอร์เฟซผู้ใช้ รวมถึงการทำให้ CRDT และเครือข่าย P2P พร้อมใช้งานในผลิตภัณฑ์มากขึ้น

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

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

 
GN⁺ 2025-07-06
ความคิดเห็นจาก Hacker News

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

    • Obsidian ก็เป็นโมเดลที่น่าใช้อ้างอิงได้ดี ตัวไคลเอนต์ฟรีทั้งหมด และขายเฉพาะบริการซิงก์แบบเลือกใช้ได้
      โน้ตทั้งหมดเป็นไฟล์ Markdown ดังนั้นตัวไคลเอนต์เองก็กลายเป็นตัวเลือกเช่นกัน
    • อยากรู้ว่ามีแผนจะซิงก์อย่างไรโดยไม่มีโครงสร้างพื้นฐานบนคลาวด์
    • “อัปเดต X ปี + ซิงก์อุปกรณ์ + ใช้งานถาวร” ฟังดูดี แต่ถ้าทำแบบนี้ก็ต้องเก็บ ต้นทุนรวมของค่าสมัครสมาชิก 1–2 ปีในครั้งเดียว
      ยังต้องเดินเครื่องเซิร์ฟเวอร์ซิงก์ต่อไปเรื่อย ๆ และต้องคำนึงถึงกรณีที่ผู้ใช้ซิงก์ข้อมูลมูลค่า 1 ปีทั้งหมดในวันเดียวด้วย แถมยังต้องจ่ายเงินเดือนให้คนที่จะดูแลงานพัฒนาในอนาคตต่อไป ดังนั้นถ้ามองจากมุมของนักพัฒนาอย่างเดียวก็มีบางส่วนที่ตกหล่นไป
    • เมื่อไม่กี่ปีก่อน หลังจากโรงงานท้องถิ่นแห่งหนึ่งต้องหยุดการผลิตไปสองวันเพราะเซิร์ฟเวอร์ของผู้ให้บริการ IT ล่ม ผมก็เคยคิดคล้าย ๆ กันโดยนึกถึงสถานการณ์เลวร้ายที่สุด
      https://rodyne.com/?p=1439
    • แบ็กเอนด์อาจเป็นส่วนหนึ่งของฟีเจอร์ เช่น การทำงานร่วมกันแบบเรียลไทม์หรือการซิงก์ได้ อย่างไรก็ตาม หากสามารถ ejectable ออกจากคลาวด์ และเปลี่ยนไปใช้ self-hosting หรือย้อนกลับได้ทุกเมื่อ ก็จะช่วยรับประกันความเป็นเจ้าของและความยั่งยืนระยะยาวทั้งในฝั่งข้อมูลและบริการ
      IDE สำหรับโน้ต/งานที่เรากำลังทำก็ใช้แนวทางนี้: https://thymer.com/local-first-ejectable

  • ที่ Berlin มี Local-first Software Conference ประจำปีซึ่งจัดโดย Ink and Switch และเดือนพฤศจิกายนปีนี้ที่ SF ก็จะมีงานแยกชื่อ Sync Conf ด้วย
    https://www.localfirstconf.com/
    https://syncconf.dev/
    ปีนี้มีพาเนลที่ดีจากผู้เขียนร่วมของบทความต้นฉบับ ว่าซอฟต์แวร์ local-first คืออะไรในบริบทของเครื่องมือพัฒนา และได้เรียนรู้อะไรบ้างหลังจากบทความต้นฉบับ: https://youtu.be/86NmEerklTs?si=Kodd7kD39337CTbf
    ชุมชนกำลังเริ่มสรุปไปในทิศทางที่มองว่า “การซิงก์” เป็นองค์ประกอบหนึ่งของ local-first แต่เป็นเทคโนโลยีที่นำไปใช้ได้กว้างกว่านั้นมาก local-first เป็นคุณลักษณะของซอฟต์แวร์สำหรับผู้ใช้ปลายทาง ส่วนเครื่องมือพัฒนาอย่าง sync engine เป็นเครื่องมือที่ทำให้สิ่งนี้เป็นไปได้ ไม่ใช่ว่าตัวมันเองจำเป็นต้องเป็น local-first เสมอไป
    วิดีโอการบรรยายทั้งหมดในช่วงหลายปีที่ผ่านมาอยู่ที่นี่: https://youtube.com/@localfirstconf?si=uHHi5Tsy60ewhQTQ
    นี่เป็นช่วงเวลาที่น่าสนใจสำหรับชุมชน local-first/sync engine เราสร้างเครื่องมือที่ทำให้ประสบการณ์การทำงานร่วมกันแบบเรียลไทม์และแบบอะซิงโครนัสเป็นไปได้ และเมื่อ AI เข้ามา ตลาดนี้ก็กำลังขยายตัว แอป AI ทุกตัวโดยแก่นแท้แล้วคือ ระบบการทำงานร่วมกันแบบหลายผู้ใช้ ที่มีเอเจนต์เข้าร่วมในฐานะผู้กระทำ จึงต้องใช้เทคโนโลยีที่ชุมชน sync engine ทำงานกันมา

    • ยังมี Local First พอดแคสต์ ที่ยอดเยี่ยม ซึ่งสัมภาษณ์วิศวกรที่สร้างแอปและโครงสร้างพื้นฐานแบบ local-first
      https://www.localfirst.fm/

  • น่าอ่าน และในอดีตก็เคยมีการถกเถียงอย่างคึกคักหลายครั้ง
    https://news.ycombinator.com/item?id=19804478 - พฤษภาคม 2019, 191 ความคิดเห็น
    https://news.ycombinator.com/item?id=21581444 - พฤศจิกายน 2019, 241 ความคิดเห็น
    https://news.ycombinator.com/item?id=23985816 - กรกฎาคม 2020, 9 ความคิดเห็น
    https://news.ycombinator.com/item?id=24027663 - สิงหาคม 2020, 134 ความคิดเห็น
    https://news.ycombinator.com/item?id=26266881 - กุมภาพันธ์ 2021, 90 ความคิดเห็น
    https://news.ycombinator.com/item?id=31594613 - มิถุนายน 2022, 30 ความคิดเห็น
    https://news.ycombinator.com/item?id=37743517 - ตุลาคม 2023, 50 ความคิดเห็น

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

    • ทั้งหมดก็เพราะ รายได้จากการสมัครสมาชิก
      บริษัทที่ได้รายได้จากการสมัครสมาชิกจะมีรายได้มากกว่า มูลค่ากิจการสูงกว่า ระดมทุนเพิ่มเติมได้ง่ายกว่า และเอาชนะบริษัทที่ไม่ทำตามโมเดลนี้ได้ เพราะโครงสร้างที่เสริมแรงตัวเองแบบนี้ ผมจึงมองว่าซอฟต์แวร์แบบ local-first ตายไปแล้ว
    • ถ้าดูพื้นที่จัดเก็บฟรี/เสียเงินของอย่าง Dropbox หรือ Apple ก็จะเห็นต้นทุนจริง ๆ โดยประมาณอยู่ที่ 2TB เดือนละ 10 ดอลลาร์
      Cloudflare ให้โฮสต์ไฟล์สแตติกแทบจะฟรี และต้นทุนก็ใกล้เคียงกับค่าคลาดเคลื่อนจากการปัดเศษ แอป local-first 1,000 แอปซิงก์กับ Dropbox ก็ยังรันได้ด้วยพื้นที่จัดเก็บเดือนละ 10 ดอลลาร์ พื้นที่จัดเก็บนี้ไม่ใช่เครื่องมือดิบระดับล่างแบบ S3 แต่เป็นบริการสำหรับผู้บริโภคที่มีทั้งการยืนยันตัวตน การซัพพอร์ต และโปรแกรมซิงก์ ต้นทุนคลาวด์ส่วนใหญ่จริง ๆ แล้วไม่จำเป็น
    • ถ้าใครคัดค้านโครงการ Stop Killing Games ก็ควรอ่านข้อความนี้
      ไม่มีใครบังคับให้เกมต้องพึ่งพาแต่บริการออนไลน์ ไม่ใช่ข้อกำหนดทางกฎหมาย และไม่ใช่ข้อกำหนดด้านกฎระเบียบ มันเป็นแค่ทางเลือกเหมือนหลาย ๆ อย่างในซอฟต์แวร์ การเลือกให้พึ่งพาบริการออนไลน์ไว้ก่อน แล้วภายหลังมาพูดว่า “ถ้าจะย้อนกลับต้องใช้เงิน” นั้นสายตาสั้น น่าสมเพช และไม่ควรยอมรับ

  • ควรมีแอปจำนวนมากขึ้นที่เป็น local-first ถ้าผู้ใช้ไม่อยากซิงก์ข้อมูลขึ้นคลาวด์ ก็ควรมีตัวเลือกนั้น
    ผมกำลังทำแอปแบบ offline-first หรือ local-first ชื่อ Brisqi มาสักพักแล้ว และออกแบบตั้งแต่ต้นด้วยปรัชญา offline-first
    https://brisqi.com
    แอป local-first ควรถูกออกแบบให้ทำงานแบบออฟไลน์เต็มรูปแบบได้ไม่มีกำหนด ประสบการณ์แบบ local ต้องเป็นฐาน ไม่ใช่ทางเลือกสำรอง และการซิงก์คลาวด์ควรเป็นฟีเจอร์เสริม ไม่ใช่ข้อกำหนด
    แอปที่พึ่งพาแคชชั่วคราว ผมไม่ถือว่าเป็น offline-first แอป offline-first ของจริงต้อง persist ข้อมูลด้วยฐานข้อมูล local แอปจำนวนมากที่เรียกตัวเองว่า “offline-first” จริง ๆ แล้วใกล้เคียงกับ offline-capable ที่มีฟังก์ชันออฟไลน์จำกัด และสุดท้ายยังต้องพึ่งการเชื่อมต่ออินเทอร์เน็ตกลับมาใหม่
    แอป offline-first ทำยากกว่าเว็บแอปแบบออนไลน์เท่านั้นอย่างชัดเจน และกลไกการซิงก์ต้องเชื่อถือได้พอที่จะทำให้ข้อมูลซิงก์ขึ้นคลาวด์อย่างสม่ำเสมอและไม่สูญหาย แม้ระหว่างการสลับสถานะออฟไลน์/ออนไลน์ ผมเขียนแนวทางไว้เพิ่มเติมในบล็อก: https://blog.brisqi.com/posts/how-i-designed-an-offline-first-app-an-outline

    • ผมกังวลว่าโมเดลนี้จะยั่งยืนเป็นธุรกิจได้ยากกว่าหรือเปล่า และอยากรู้ว่าจริง ๆ แล้วตอนนี้เป็นอย่างไรบ้าง

  • น่าสนใจที่บทความอธิบายหลักการนี้ในบริบทผู้บริโภค แต่ตอนนี้เรากำลังทำสิ่งเดียวกันในฝั่ง สินทรัพย์อุตสาหกรรม/ข้อมูลอุตสาหกรรม
    ที่ www.sentineldevices.com การเรียนรู้ การวิเคราะห์ และการตัดสินใจทั้งหมดเกิดขึ้นบนอุปกรณ์ของลูกค้า ไม่มีแม้แต่เซิร์ฟเวอร์ให้ส่งข้อมูลไป เป็นโมเดลที่ทุกอย่างรันอยู่ภายในอุปกรณ์อย่างชัดเจน
    ใน SCADA/ระบบอัตโนมัติอุตสาหกรรม มี use case จำนวนมากที่ไม่สามารถนำข้อมูลออกไปภายนอกได้ บริษัทด้านข้อมูล/AI มองข้ามฐานลูกค้าและ use case ขนาดใหญ่ เพียงเพราะให้บริการในที่ที่ลูกค้าอยู่ได้ยาก และพยายามดึงข้อมูลมาหาตัวเองแทน พร้อมรักษาการผูกติดกับผู้ขายไว้
    เวลาคุยกับลูกค้า เรากลับต้องย้ำหนักมากว่า “ไม่ครับ อันนี้เป็น local และไม่มีการเชื่อมต่อออกไปภายนอก” เพราะพวกเขาแทบไม่เคยได้ยินคำแบบนี้ จึงมักต้องอธิบายทีละขั้นจนเข้าใจว่าทุกอย่างเกิดขึ้นใน local และผู้ให้บริการซอฟต์แวร์เองก็มักรับแนวคิดนี้ไม่ค่อยได้ หวังว่าซอฟต์แวร์ local-first จะตั้งหลักในฝั่งผู้บริโภคมากขึ้น เพื่อให้ฝั่งอุตสาหกรรมคุ้นเคยกับมันมากขึ้นด้วย

    • การที่ ผู้ให้บริการ SCADA ทุกรายขึ้นขบวนกระแสคลาวด์แล้วผลักไปทางนั้น ก็ไม่ได้ช่วยอะไร
      “บริหารโรงงานด้วยสมาร์ตโฟน!” แบบนี้แค่มี zero-day โผล่มาหนึ่งตัว script kiddie ก็เล่นกับปั๊มของผมได้แล้ว
    • เป็นสาขาที่น่าสนใจ และดีใจที่คุณกำลังทำเรื่องนี้อยู่
      ดูหน้ารับสมัครงานแล้วเห็นว่าทุกตำแหน่งเป็นแบบไม่รีโมต เลยสงสัยว่าเป็นข้อจำกัดที่ต้องเจอหน้ากันโดยตรงเพื่อทำซอฟต์แวร์ local-first หรือว่าเป็นเหตุผลด้านการบริหารเป็นหลัก

  • โดยส่วนตัวไม่เห็นด้วยกับแนวทางนี้ ดูเหมือนเป็นความพยายามแก้ ปัญหาทางธุรกิจ อย่าง “ไม่สามารถเชื่อถือผู้ให้บริการคลาวด์ได้” ด้วยการประนีประนอมเชิงเทคนิคอย่าง “หลีกเลี่ยงสถาปัตยกรรมแบบรวมศูนย์”
    การขาดอำนาจควบคุมและความน่าเชื่อถือของซอฟต์แวร์แบบปิดถูกแก้ด้วยโมเดลธุรกิจใหม่อย่างการพัฒนาโอเพนซอร์ส ใบอนุญาตแบบใหม่ และรูปแบบรายได้อย่างสัญญาบำรุงรักษาแทนค่าลิขสิทธิ์
    ในทำนองเดียวกัน ปัญหาของผู้ให้บริการคลาวด์ก็จำเป็นต้องมีทางแก้ในระดับโมเดลธุรกิจ เช่น อาจสร้างสัญญา/ใบอนุญาตมาตรฐานที่กำหนดสิทธิ์เพื่อให้ผู้ใช้เชื่อถือความสัมพันธ์กับผู้ให้บริการคลาวด์ได้ เมื่อเวลาผ่านไป ผู้ใช้อาจเลือกทำธุรกิจกับผู้ให้บริการที่มีใบอนุญาตแบบนี้เท่านั้น
    ในนี้อาจมีข้อกำหนดอย่างสัญญาเมื่อสิ้นสุดอายุการใช้งาน การรับประกันการย้ายข้อมูล และ ความโปร่งใสด้านความเป็นส่วนตัวของข้อมูล ที่ตรวจสอบการเข้าถึงข้อมูลและแจ้งว่าใคร/อะไร/เมื่อไรที่อ่านข้อมูล ปัญหาคือการนำไปใช้จริง ประเด็นสำคัญคือทำไมผู้ให้บริการคลาวด์ถึงต้องยอมรับ และหากพวกเขากลัวอัตราการยกเลิก ก็อาจเสนอข้อตกลงแบบนี้เฉพาะกับการสมัครสมาชิกรายปีหรือคิดราคาสูงขึ้นได้

    • หากปัญหาทางธุรกิจหรือปัญหาทางการเมืองแก้ได้ด้วยทางเทคนิค โดยมากก็เป็นแนวทางที่แข็งแรง เพราะปัญหาเหล่านั้นเกิดจากผู้เล่นที่เป็นปฏิปักษ์ และทางแก้เชิงเทคนิคจะตัดความสามารถของผู้เล่นนั้นในการทรยศออกไป
      ตัวอย่างที่ดีคือ การเข้ารหัส เมื่อใช้บริการคลาวด์ การพยายามปกป้องข้อมูลด้วยนโยบายความเป็นส่วนตัวและกฎระเบียบทางราชการแทบจะเปล่าประโยชน์ ข้อมูลมีมูลค่า และลูกค้าหรือรัฐบาลก็รู้ได้ยากว่าบริษัทแอบขายข้อมูลอยู่หรือไม่ อีกทั้งยังรู้ได้ยากก่อนจะสายเกินไปว่าบริษัทประหยัดงบด้านความปลอดภัยหรือเปล่า
      แต่ถ้าสามารถพิสูจน์ทางคณิตศาสตร์ได้ว่าข้อมูลถูกเข้ารหัสบนอุปกรณ์ไคลเอนต์และเซิร์ฟเวอร์เข้าถึงข้อความธรรมดาไม่ได้ ก็ไม่ต้องกังวลเรื่องนั้น ปัญหาคือเมื่อเซิร์ฟเวอร์ไม่ได้แค่เก็บข้อมูล แต่ต้องประมวลผลข้อมูลด้วย และตอนนั้นทางแก้เชิงเทคนิคก็คือการใช้เซิร์ฟเวอร์ของตัวเอง
    • ผมสงสัยว่าสัญญาแบบนั้นจะแก้ปัญหาได้จริงหรือไม่ ต่อให้เอกสารระบุว่าบริการคลาวด์จะแจ้งล่วงหน้า X เดือนก่อนปิดบริการและอนุญาตให้ส่งออกข้อมูลได้ แต่หลังจากปิดจริง สิ่งที่เหลืออยู่ในมืออาจเป็นไฟล์ JSON ขนาดมหึมาที่แทบใช้ประโยชน์ไม่ได้
      ถ้าไม่สร้างแอปเองหรือไม่มีใครใจดีสร้างให้ ก็ใช้งานได้ยาก มันดีกว่าไม่มีอะไรเลย แต่ไม่ดีเท่า แอปโลคัล ที่ยังรันต่อได้หลายปีหรือหลายสิบปีหลังจากบริษัทปิดตัวหรือเลิกซัพพอร์ต
    • โมเดลนี้อาจทำให้ผู้ให้บริการคลาวด์เป็นเหมือนธนาคารได้ ผู้ให้บริการคลาวด์เก็บทรัพย์สินบางอย่างไว้ในบัญชีผู้ใช้ และผู้ใช้ก็มีสิทธิ์ที่ชัดเจนต่อทรัพย์สินนั้น รวมถึงความสามารถทางกฎหมายในการเรียกคืนจากบัญชี
      ในโลกการเงิน การเรียกคืนเทียบได้กับการรับมอบเงินหรือทรัพย์สิน ส่วนในคลาวด์อาจหมายถึงการได้รับไฟล์ Zip ขนาดใหญ่ที่มีเนื้อหาทั้งหมดของบัญชี
      แต่สิ่งที่ได้รับมอบไม่ได้ใช้งานได้จริงหรือเป็นสิ่งที่พึงประสงค์เสมอไป ในโลกการเงินสามารถโอนบัญชีไปยังผู้ให้บริการรายอื่นได้ และในบริการคลาวด์หลายกรณีก็มีแนวโน้มว่าการโอนบัญชีจะมีประโยชน์กว่ามาก
      จุดที่ยากตรงนี้คือ ความสามารถในการพกพา/ย้ายข้ามระบบ ต่อให้กำหนดกรรมสิทธิ์และสิทธิ์ของผู้ใช้ต่อบัญชีคลาวด์ไว้อย่างดี ก็ยังคลุมเครืออยู่ดีว่าการรับมอบเพื่อนบน Facebook หมายความว่าอะไร หรือการย้ายบัญชี Facebook ไปที่อื่นหมายถึงอะไร
    • ผมคิดว่าการตีความนั้นไม่ถูกต้อง ผู้เขียนยอมรับอย่างเพียงพอว่ากรณีทางธุรกิจของ local-first ยังไม่ได้รับการแก้ไขอย่างสมบูรณ์ และเป็นประเด็นที่เกี่ยวข้องกันอย่างใกล้ชิด
      ปัญหานี้ต้องการทั้งทางแก้ทางธุรกิจและทางเทคนิค และบทความเสนอว่าทางแก้ควรมีคุณลักษณะอย่างไร
      การบอกว่า local-first สนับสนุนการกระจายศูนย์ก็ไม่ถูกต้องเช่นกัน Martin Kleppmann ระบุชัดว่าเขาไม่คิดว่าเทคโนโลยีกระจายศูนย์จะแก้ปัญหานี้ในแบบที่ไปถึงตลาดมวลชนได้ เขาสนับสนุน เอนจินซิงก์มาตรฐานแบบรวมศูนย์ ที่ทำให้อุดมคติของ local-first เป็นไปได้
      ดูงานนำเสนอ Local-first conf ปีที่แล้ว: https://youtu.be/NMq0vncHJvU?si=ilsQqIAncq0sBW95
    • การรับประกันการย้ายข้อมูลไม่ค่อยใช้งานได้จริงสำหรับข้อมูลที่มีขนาดพอสมควร การย้ายฐานข้อมูลสภาพแวดล้อมจริงไปยังฐานข้อมูลใหม่ หากต้องการให้ราบรื่นอาจใช้เวลาหลายเดือนถึงหลายปี
      ในสถานการณ์วิกฤตอาจทำได้ภายในไม่กี่สัปดาห์ แต่ก็อาจเละเทะมาก แม้ย้ายระหว่างฐานข้อมูลโอเพนซอร์สเวอร์ชันเดียวกันก็เช่นกัน เพราะบริการคลาวด์แต่ละรายมีความแตกต่างกันมาก
      ทางแก้ที่ดีที่สุดคือเก็บข้อมูลไว้ในสภาพแวดล้อมของตัวเองตั้งแต่แรก และตัดการเชื่อมต่อเมื่อจำเป็น การผสานการจัดการ BYOC กับโอเพนซอร์สทำให้เป็นไปได้ บริษัทของเราก็ให้บริการผลิตภัณฑ์ข้อมูลแบบ BYOC อยู่ จึงมีผลประโยชน์ทางเศรษฐกิจในแนวทางนี้ แต่เพราะเราเห็นว่ามันใช้งานได้จริง จึงรู้ว่าเป็นไปได้

  • ผมกำลังพยายามทำให้สิ่งนั้นเป็นไปได้ในวงกว้างด้วยโปรเจกต์ของผม https://github.com/ibizaman/selfhostblocks และ https://github.com/ibizaman/skarabox
    เป้าหมายร่วมคือทำให้ self-hosting เข้าถึงคนทั่วไปได้มากขึ้น
    โดยอิงกับ NixOS และพยายามให้มี https, SSO, LDAP, backup, ZFS พร้อม snapshot ฯลฯ มาให้เป็นค่าเริ่มต้นในรูปแบบ declarative ให้มากที่สุด
    แพ็กเกจ Vaultwarden และ Nextcloud ไว้เพื่อให้เก็บข้อมูลส่วนใหญ่ได้ จึงเป็นคู่แข่งของ cloud hosting และยังมีบริการอย่าง Home Assistant ด้วย
    นอกจากนี้ยังเป็นคู่แข่งของ YUNoHost ด้วย แต่ SelfHostBlocks ตั้งใจจะดีกว่า เพราะให้คุณ self-host แพ็กเกจที่ต้องการเองได้ด้วยคอมโพเนนต์ที่มีให้ มันใกล้เคียงกับไลบรารีมากกว่าเฟรมเวิร์ก
    แข่งกับ NAS ด้วย แต่ผมมองว่าดีกว่าในแง่ที่ทุกอย่างเป็นโอเพนซอร์ส ตอนนี้ผู้ใช้ยังต้องมีความรู้เทคนิคอยู่ แต่กำลังลดข้อจำกัดนั้นลง และหนึ่งในเป้าหมายคือให้ติดตั้งบนฮาร์ดแวร์ของตัวเองได้โดยไม่ต้องรู้จัก Nix หรือแตะ command line

    • ดีมากจริง ๆ ช่วงนี้ผมคิดเรื่องนี้เยอะมาก แปลกดีที่มี ทางเลือกเสรีและโอเพนซอร์ส ดี ๆ มากมายขนาดนี้ แต่ถึงแม้สำหรับคนสายเทคนิคจะค่อนข้างง่ายระดับ “docker compose up” แต่สำหรับคนไม่ใช่สายเทคนิคก็ยังเข้าถึงยากอยู่
      แอปจำนวนมากที่ self-host ได้เป็นเว็บแอปพลิเคชันที่มีฐานข้อมูล เซิร์ฟเวอร์ และฟรอนต์เอนด์ แต่ในหลายกรณีการใช้งาน ผู้ใช้ใช้แค่บนคอมพิวเตอร์เครื่องเดียว และไม่จำเป็นต้องมีเวอร์ชันโฮสต์หรือซิงก์กับอุปกรณ์อื่น ตัวอย่างเช่น บัญชีส่วนตัวทำบนคอมพิวเตอร์เดือนละครั้งก็พอ ไม่จำเป็นต้องรันเว็บแอปตลอด 24 ชั่วโมงที่ไหนสักแห่ง แค่เปิดโปรแกรม ทำงาน แล้วปิด
      มี ความไม่สอดคล้อง กันมากระหว่างจำนวนทางเลือกเสรีและโอเพนซอร์สคุณภาพสูงที่ self-host ได้ กับจำนวนคนที่ใช้งานมันได้จริง เราต้องการโปรเจกต์ที่ช่วยลดช่องว่างนี้ให้มากขึ้น ผมตั้งใจจะลองใช้ selfhostblocks กับบางอย่างและลองมีส่วนร่วมดู
    • ชอบที่มี hledger รวมอยู่ด้วย สำหรับคนที่ไม่คุ้นกับบัญชีแบบข้อความล้วน อาจจะรู้สึกแปลกหน่อย แต่มันเป็นซอฟต์แวร์ที่ยอดเยี่ยมจริง ๆ

  • ไม่มีเหตุผลที่ทุกแอปพลิเคชันจะต้องมีแพลตฟอร์มซิงก์ของตัวเอง การวางกรอบแบบนี้ดูเหมือนมาจาก แอปมือถือ ที่ไม่มี composability หรือ modularity ระหว่างโปรแกรม
    ถ้าจะเอา “local-first” อย่างจริงจัง ก็ใช้ไฟล์ซิสเต็มไปเลย และผู้ใช้ก็เลือกได้จากหลายโซลูชัน เช่น git, Box เป็นต้น
    การบังคับให้สมัครใช้ระบบซิงก์ของตัวเองน่ารังเกียจพอ ๆ กับ SaaS อื่น ๆ และยิ่งทึบแสงกว่า แถมเปราะบางกว่าเสียอีก

    • ผมเห็นด้วยว่าไม่ใช่ทุกแอปต้องมี sync engine ของตัวเอง แต่ไม่เห็นด้วยกับการวางกรอบว่าไฟล์ซิสเต็มคือวิธีสากลในการยอมรับ local-first
      อย่างแรก ผมต้องการ local-first ก็จริง แต่ก็ต้องการ concurrency ด้วย ถ้าเป็น local-first แบบง่าย ๆ ซิงก์อะไรก็ได้ก็คงพอ แต่ผมต้องการมากกว่านั้น ผมอยากให้มันทำงานลื่นไหลแบบ Dropbox โดยไม่ต้องคอยสนใจ และแม้ในพื้นที่ที่สื่อสารไม่ได้ ผมกับภรรยาก็ยังแก้ไขแยกกันบนมือถือของแต่ละคนได้
      อย่างที่สอง การซิงก์ทำงานได้ดีกว่ามากเมื่อเข้าใจโครงสร้างข้อมูลและความหมายของข้อมูลอย่างลึกซึ้ง git กับ Box ต่างก็มีข้อจำกัดไม่น้อย และถ้ามีความต้องการด้าน concurrency ข้อจำกัดนั้นก็ยิ่งมากขึ้น
    • โดยรวมเห็นด้วย แต่ในทางปฏิบัติไม่ได้ง่ายแบบนั้นเสมอไป ผมเคยทำแอปที่ทำงานแบบนั้นเป๊ะ ๆ แต่เพราะไม่สามารถประสานได้ว่าเมื่อไร client ใดควรได้รับอนุญาตให้แก้ไฟล์ สุดท้าย file conflict จึงเกิดขึ้นอย่างหลีกเลี่ยงไม่ได้

  • ในเชิงทฤษฎี ผมชอบแนวทางการพัฒนาแบบ local-first มันเข้ากับปรัชญา small tech ที่มองความเป็นส่วนตัวและกรรมสิทธิ์ในข้อมูลเป็นค่าเริ่มต้นได้ดี
    แต่ในทางปฏิบัติมันยาก เพราะแทบจะต้องสร้างเอนจินซิงก์เอง จัดการการแก้ conflict และดูแล schema migration
    ถึงอย่างนั้น ในช่วงไม่กี่ปีที่ผ่านมา เครื่องมือพัฒนาซอฟต์แวร์แบบ local-first ดูจะดีขึ้น ผมติดตาม jazz.tools, electric-sql และ Zero ของ Rocicorp อยู่ และสงสัยว่ายังมีตัวอื่นอีกไหม

    • CouchDB บนเซิร์ฟเวอร์กับ PouchDB บนไคลเอนต์เคยเป็นความพยายามที่จะสร้างสภาพแวดล้อมแบบนั้น
      https://couchdb.apache.org/
      https://pouchdb.com/
      แนวคิดเพิ่มเติมเกี่ยวกับการพัฒนาแอปพลิเคชันแบบ local-first เมื่อราว 10 ปีก่อน ดูได้ที่นี่ด้วย: https://unhosted.org/
    • ช่วงประมาณหนึ่งเดือนที่ผ่านมา ผมได้ลองใช้ instantdb กับโปรเจกต์ข้างเคียงเป็นแอปงบประมาณส่วนตัวค่อนข้างจริงจัง
      คงต้องเขียนบล็อกโพสต์สักหน่อย แต่ก่อนหน้านี้ผมเคยสำรวจ PowerSync, electricSQL, LiveStore, PowerSync และดู jazz.tools ผ่าน ๆ ด้วย แต่ต้องการอะไรที่มีโครงสร้างมากกว่านั้น
      จนถึงตอนนี้ค่อนข้างประทับใจ ผมกำลังเขียนด้วย Vue และไลบรารีของคอมมูนิตี้ ส่วน permission แรก ๆ ซับซ้อนนิดหน่อย แต่พอเข้าใจแล้วก็เรียบง่าย ผมชอบ magic email login ด้วย และ dashboard/response functions ก็ดี แต่ดูเหมือนต้องมีการเปลี่ยนแปลงใหญ่บางอย่างเพื่อให้ใช้งานยุ่งยากน้อยลง
      ชอบตรงที่เป็นโอเพนซอร์สและสามารถ self-host ได้ถ้าต้องการ jazz ขาดโครงสร้างไปหน่อย ส่วน LiveStore แม้จะน่าสนใจ แต่ event store ดูยุ่งยากเกินไป เครื่องมือพัฒนาที่อยู่หลังกำแพงจ่ายเงินก็น่าเสียดาย แต่ก็พอเข้าใจได้ electricSQL ให้มาแค่ครึ่งหนึ่งของโซลูชัน คือมีเฉพาะการอ่าน และยังขาดโมเดลการเขียน CouchDB/PouchDB สำหรับผมก็ยังขาดโครงสร้าง และอยากให้มีการรองรับข้ามเอกสารที่ชัดเจนติดมาในตัวมากกว่านี้ ส่วน Zero ยังไม่ได้สำรวจอย่างจริงจัง
    • สงสัยว่าคุณรู้จักไซต์นี้ไหม: https://www.localfirst.fm
      จริง ๆ ตั้งใจจะชี้ไปที่ลิงก์ “landscape” ในเมนูด้านบน แต่ URL ค่อนข้างไม่สะดวก
    • เมื่อไม่นานมานี้เห็นมีคนพูดถึง Automerge
      https://automerge.org/
      มี implementation ทั้ง Rust และ JavaScript และยังมี network strategies บางแบบให้ด้วย ไม่ได้มาพร้อมแพ็กเกจผลิตภัณฑ์ฟรี/เสียเงินเหมือน jazz.tools แต่ก็ถือว่าค่อนข้างดี
    • Ditto ก็น่าดูเช่นกัน
      https://www.ditto.com
      เป็นแพลตฟอร์ม local-first ที่รองรับการซิงก์แบบเรียลไทม์โดยมี CRDT เป็นแกนหลัก ทำให้การจัดการการแก้ conflict ง่ายขึ้นมาก ออกแบบมาเพื่อรองรับ use case แบบ offline-first และการซิงก์แบบ peer-to-peer เป็นค่าเริ่มต้น จึงไม่จำเป็นต้องสร้างเอนจินซิงก์เองตั้งแต่ศูนย์
      รองรับแพลตฟอร์มหลากหลาย เช่น Swift, Kotlin(Android), Flutter/Dart, React Native, JavaScript(Web/Node), .NET(C#), C++, Java, Rust เป็นต้น อ่านเอกสารเพิ่มเติมได้ที่นี่: https://docs.ditto.live/home/about-ditto