เหตุใดแอปแบบ Local-First จึงยังไม่แพร่หลายสู่คนหมู่มาก?

 (marcobambini.substack.com)
10 คะแนน โดย GN⁺ 2025-09-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แอปแบบ Local-First สัญญาว่าจะให้ การตอบสนองที่รวดเร็ว และ ความเป็นส่วนตัวพื้นฐานโดยปริยาย แต่ในทางปฏิบัติ การรองรับออฟไลน์อย่างแท้จริงนั้นทำได้ยากมาก
  • สาเหตุใหญ่ที่สุดคือ ความซับซ้อนของการซิงก์ เพราะเมื่อมีการเปลี่ยนแปลงข้อมูลพร้อมกันจากหลายอุปกรณ์ สุดท้ายระบบต้อง ลู่เข้าไปสู่สถานะเดียวกันอย่างแม่นยำ
  • มีความท้าทายทางเทคนิคหลักอยู่ 2 ประการคือ ความไม่แน่นอนของลำดับเวลา และ ความขัดแย้งของข้อมูล
  • เพื่อแก้ปัญหานี้ จำเป็นต้องนำแนวทางออกแบบระบบกระจายอย่าง Hybrid Logical Clocks(HLCs) และ CRDTs มาใช้
  • การใช้ส่วนขยายบนพื้นฐานของ SQLite สามารถมอบสถาปัตยกรรมการซิงก์ที่ เชื่อถือได้และเรียบง่าย และนำไปใช้ได้บนทุกแพลตฟอร์ม

คำสัญญาและความเป็นจริงของแอปแบบ Offline-First

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

ความยากพื้นฐานของการซิงก์

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

1. ความไม่แน่นอนของลำดับเหตุการณ์

  • เหตุการณ์จากหลายอุปกรณ์เกิดขึ้นคนละช่วงเวลา และสถานะสุดท้ายอาจเปลี่ยนไปตามลำดับของเหตุการณ์
    • ตัวอย่าง: อุปกรณ์ A ตั้งค่า x=3, อุปกรณ์ B ตั้งค่า x=5 → ต่างฝ่ายต่างเปลี่ยนระหว่างออฟไลน์ แล้วเมื่อซิงก์กันภายหลัง อาจเกิดผลลัพธ์ที่ต่างกันได้
  • ฐานข้อมูลแบบรวมศูนย์เดิมแก้ปัญหานี้ด้วย ความสอดคล้องเข้มงวด แต่แนวทางนี้ต้องอาศัยการซิงก์ระดับโกลบอล จึงไม่เหมาะกับระบบแบบ Local-First
  • สุดท้ายแล้ว จำเป็นต้อง กำหนดลำดับที่เหมาะสมให้กับแต่ละเหตุการณ์แม้อยู่ในสภาพแวดล้อมแบบกระจายและเปลี่ยนแปลงตลอดเวลา จึงต้องมีวิธีกำหนดลำดับโดยไม่พึ่งนาฬิกากลาง

การนำ Hybrid Logical Clocks(HLCs) มาใช้

  • Hybrid Logical Clocks(HLCs) คือ อัลกอริทึมที่เรียบง่ายแต่มีประสิทธิภาพ ซึ่งช่วยให้อุปกรณ์แต่ละเครื่องตกลงลำดับของเหตุการณ์กันได้ในทางปฏิบัติ
  • HLC ใช้งานโดย ผสานข้อมูลเวลาจริงเข้ากับตัวนับเชิงตรรกะ
  • ตัวอย่างเช่น:
    • อุปกรณ์ A บันทึกเหตุการณ์ตอนเวลา 10:00:00.100 ดังนั้น HLC คือ (10:00:00.100, 0)
    • อุปกรณ์ B ที่ได้รับข้อความ แม้นาฬิกาของตัวเองจะช้ากว่า ก็จะเลื่อน HLC เป็น (10:00:00.100, 1)
    • ด้วยเหตุนี้ จึงสามารถกำหนดลำดับเหตุการณ์ได้อย่างถูกต้อง โดยไม่ขึ้นกับความต่างของนาฬิกาจริงระหว่างสองอุปกรณ์

2. ปัญหาความขัดแย้ง

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

การใช้ CRDTs

  • แนวทางที่ดีที่สุดคือการใช้ Conflict-Free Replicated Data Types(CRDTs)
  • CRDTs รับประกันว่า ไม่ว่าจะซิงก์ตามลำดับใด หรือแม้มีการนำไปใช้ซ้ำ สถานะของแต่ละอุปกรณ์ก็จะลงเอยเหมือนกันเสมอ
  • กลยุทธ์ CRDT ที่ง่ายที่สุดคือ Last-Write-Wins(LWW)
    • ใส่ timestamp ให้กับทุกการอัปเดต
    • ระหว่างซิงก์ ให้เลือกค่าที่มี timestamp ใหม่กว่า

ข้อดีของ SQLite

  • ในการสร้างแอปแบบ Local-First จำเป็นต้องมี ฐานข้อมูลภายในเครื่องที่เบาและเชื่อถือได้ และ SQLite คือทางเลือกที่เหมาะที่สุด
  • หากทำฟังก์ชันการซิงก์ผ่านส่วนขยายของเฟรมเวิร์กที่อิง SQLite จะได้ข้อดีดังนี้
    • การนำข้อความมาใช้ทำได้ง่าย: อ่านค่าปัจจุบัน → หาก timestamp ใหม่กว่าให้เขียนทับ → หากไม่ใช่ให้ข้าม
    • วิธีนี้ รับประกันการลู่เข้าสู่สถานะเดียวกันของทุกอุปกรณ์ โดยไม่ขึ้นกับลำดับการซิงก์

ความหมายของสถาปัตยกรรมนี้

  • โครงสร้างนี้ทำให้เกิดการซิงก์ที่ เรียบง่ายและเชื่อถือได้สูง
    • แม้ออฟไลน์ต่อเนื่องหลายสัปดาห์ก็ยังเชื่อถือได้โดยไม่สูญหายของข้อมูล
    • มีคุณสมบัติแบบกำหนดได้แน่นอนที่ลู่เข้าสู่สถานะสุดท้ายเสมอ
    • แก้ปัญหาได้ด้วยเพียง ส่วนขยาย SQLite ขนาดเล็ก โดยไม่ต้องพึ่งพา dependency หนัก ๆ
    • รองรับ ทุกแพลตฟอร์มหลัก เช่น iOS, Android, macOS, Windows, Linux, WASM

ข้อเสนอแนะสำหรับนักพัฒนา

  • ควรหลีกเลี่ยงการ "แกล้งทำเป็น" รองรับโหมดออฟไลน์ด้วยคิวคำขอแบบง่าย ๆ
  • ควรยอมรับแนวคิด eventual consistency และใช้ เทคโนโลยีระบบกระจายที่ผ่านการพิสูจน์แล้ว เช่น HLC และ CRDT
  • แทนที่จะใช้เฟรมเวิร์กขนาดใหญ่และซับซ้อน ควรมุ่งสู่โครงสร้างที่ เล็กและไม่ผูกกับ dependency
  • ผลลัพธ์คือแอปจะได้ประโยชน์อย่าง เปิดใช้งานได้ทันที, ใช้งานออฟไลน์ได้, และ มีความเป็นส่วนตัวพื้นฐานโดยปริยาย

แนะนำโอเพนซอร์ส SQLite-Sync

  • หากสนใจเอนจิน Offline-First แบบข้ามแพลตฟอร์มที่พร้อมใช้ใน production ได้ทันที สามารถดูส่วนขยายโอเพนซอร์ส SQLite-Sync ได้

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

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

 
GN⁺ 2025-09-23
ความเห็นจาก Hacker News
  • แม้จะบอกว่า CRDT(Conflict-Free Replicated Data Types) คือคำตอบ แต่ในความเป็นจริงการสร้างโมเดล CRDT ที่สอดคล้องทั้งกับความคาดหวังเชิงสัญชาตญาณของผู้ใช้และ business logic ที่คงเส้นคงวานั้นยากมาก แถมยังต้องเปลี่ยน data model ให้เป็นกลุ่มข้อความแล้วคอยประกอบกลับมาเป็นสถานะจริงอยู่ตลอด จึงเป็นเรื่องปวดหัวอย่างยิ่ง
    • มี initiative ชื่อ BRAID ที่เป็น web standard ใหม่ โดยมุ่งทำมาตรฐานสำหรับการซิงก์สถานะบนเว็บ นำ Operational Transform (OT) และเทคนิค CRDT มาใช้กับ HTTP เพื่อสร้างเว็บที่ซิงก์กันได้และเป็นมิตรต่อทั้งมนุษย์และเครื่องมากขึ้นโดยพื้นฐาน Braid ช่วยเพิ่มประสิทธิภาพเครือข่าย และรองรับการพัฒนาเว็บแอปแบบ native P2P, collaborative editing และ local-first ลิงก์ที่เกี่ยวข้องคือ BRAID meeting, Braid HN discussion, RESTful API discussion, บทความอธิบาย Braid HTTP
    • เวลาพูดถึง CRDT มักเหมือนเป็นยาวิเศษสารพัดนึก แต่ความจริงการ merge อัตโนมัติไม่ได้ง่ายขนาดนั้น ในทางเทคนิค อัลกอริทึมแบบ last-writer-wins ก็ถือเป็น CRDT ได้ แต่ถ้าจะรวมข้อความที่ซับซ้อนโดยเคารพทั้งเจตนาของผู้ใช้และความคาดหวังของผู้ใช้ให้ครบถ้วน นั่นแทบเป็นปัญหาที่ยากเกือบเป็นไปไม่ได้ด้วยซ้ำ และในบางสถานการณ์ การพยายาม merge ด้วย CRDT อาจเป็นแนวทางที่ผิดตั้งแต่ต้น ตัวอย่างเช่น ถ้ามีคนสองคนจองห้องประชุมห้องเดียวกันพร้อมกัน เรื่องนี้ควรให้ผู้ใช้รับรู้ความขัดแย้งและแก้เอง ไม่ใช่ปล่อยให้อัลกอริทึมตัดสิน
    • เห็นด้วยว่านี่เป็นพื้นที่ที่ถ้าไม่กล้าก็ยากจะลุย และก็มีทางเลือกแบบ “ไม่ใช้ CRDT” สำหรับคนที่ไม่อยากเสี่ยง ดูได้ ที่นี่
    • ทีมของเราสร้างแอป local-first โดยใช้วิธีเมินสถานการณ์ conflict ไปเลย ใช้แบบ last-change-wins conflict ส่วนใหญ่เป็นเรื่องเล็กน้อยอยู่แล้ว (เช่น แก้ได้ง่ายผ่าน audit log) หรือไม่ก็เป็นปัญหาที่แต่เดิมก็แก้อัตโนมัติไม่ได้อยู่ดี ตัวอย่างเช่น ใน task tracker ที่รองรับออฟไลน์ ถ้ามีคนสองคนเริ่มงานเดียวกันพร้อมกัน ก็ควรไปจัดการใน business process แยกต่างหาก
  • เมื่อก่อนซอฟต์แวร์แทบทั้งหมดเป็น local-first และนั่นก็เป็นเรื่องปกติ แต่ทุกวันนี้โลกขับเคลื่อนด้วยการควบคุมและการเพิ่มกำไรสูงสุดเกือบทั้งหมด ผลคือโครงสร้างที่ทำให้ผู้คนเสียประโยชน์บ่อยขึ้น เพราะถึงจะไม่พอใจก็แทบไม่มีทางเลือกอื่น
    • สมัยที่ทำผลิตภัณฑ์แบบ on-premise และ self-hosted ข้อร้องเรียนจากลูกค้าที่ใหญ่ที่สุดคือไม่มีตัวเลือกแบบ cloud บริษัทส่วนใหญ่ไม่อยากโฮสต์เอง และยอมจ่ายรายเดือนเพื่อให้คนอื่นดูแลมากกว่า ดูเหมือน HN จะประเมินความต้องการ cloud service ต่ำเกินไป ทั้งที่ดีมานด์จริงสูงมาก
    • ข้ออ้างที่ว่า “ถ้าผู้คนอยากได้บริการที่เอาเปรียบน้อยกว่า ก็น่าจะทำเงินจากมันได้” นั้นไม่ถูกต้องในเชิงเศรษฐศาสตร์ ปัญหาคือคนจำนวนมากยอมทนกับความเสียหายระดับหนึ่งอยู่แล้ว ถ้าการศึกษาเรื่องนี้หรือการรับรู้ความเสี่ยงสูงกว่านี้อาจเปลี่ยนได้ แต่ผมคิดว่านั่นเป็นโจทย์ที่แก้ยากมาก
    • อีกทางเลือกหนึ่งคือ FOSS(ซอฟต์แวร์โอเพนซอร์ส)
  • อยากให้แอปไม่พึ่งพาคอนเทนต์ออนไลน์ทั้งหมด Tesla GPS เองก็ไม่ cache tile ที่โหลดมาแล้ว ทำให้ออฟไลน์แล้วแผนที่ไม่ขึ้นอะไรเลย แอปอย่าง Peacock, Kanopy ก็เช่นกัน ไม่เก็บแม้แต่ media list หรือ rendered object ไว้ในเครื่อง ทั้งที่มีคอนเทนต์อยู่ในอุปกรณ์แล้วถึง 95% อยากให้เอามันมาใช้ให้เต็มที่ แค่ทำเครื่องหมาย UI เป็น dirty แล้วรอ async save สำเร็จก็พอ โดยไม่จำเป็นต้องเปลี่ยนแนวคิดการออกแบบแอปออฟไลน์ครั้งใหญ่ แค่มีนิสัยที่ดีกว่านี้ ปัญหาส่วนใหญ่ก็แก้ได้ไม่ยาก
    • การใช้ Cache-Control ให้ถูกต้องใน API response และทำให้ network layer ปฏิบัติตาม ก็ช่วยแก้ปัญหาได้มาก แบบนี้ถ้าเปลี่ยนอายุ cache ที่ฝั่งเซิร์ฟเวอร์ก็มีผลได้ทันทีโดยไม่ต้องอัปเดตแอป
    • Google Maps สามารถดาวน์โหลด offline map ได้ด้วยการเลือกพื้นที่เอง และยัง cache หลายพื้นที่พร้อมกันได้ด้วย ผมเคยใช้ได้ดีตอนไปอุทยานแห่งชาติ
    • สำหรับคำพูดที่ว่า “ไม่ต้องเปลี่ยนการออกแบบแอปก็ได้” ผมคิดว่าบริษัทต่าง ๆ ตั้งใจจะเก็บข้อมูลเพิ่มมากกว่า ยกตัวอย่าง Apple ก็เคยมี offline map แต่จงใจทำให้ข้อมูลหมดอายุเพื่อผูกผู้ใช้ให้อยู่กับระบบของตัวเอง ส่วน tile แผนที่ของ Tesla (หรือ Google) ก็น่าสงสัยว่ามีเจตนาแอบแฝงแบบเดียวกัน
  • หลายครั้งที่คนไปโฟกัสกับประเด็น “ร้อนแรงทางการเมือง” อย่างความเป็น local-first หรือ distributed ของแอป จนหลงลืมคุณค่าหลักที่ผู้คนต้องการจริง ๆ
    • ตอนย้ายมาใช้ Immich นึกว่าคงต้องยอมเสียบางอย่างเพราะ self-hosted แต่กลับแปลกใจว่ามันดีกว่า Apple หรือ Google มาก เป็นผลิตภัณฑ์หายากราวกับยูนิคอร์น
  • ผมคิดว่าเหตุผลที่แอป local-first ไม่ดัง สุดท้ายแล้วคือเรื่องเศรษฐศาสตร์ โมเดล SaaS หรือโฆษณามีความแข็งแรงชัดเจน แต่แอป local-first ทำกำไรได้น้อยกว่ามาก คนที่ชอบโมเดลนี้มักให้ความสำคัญกับคุณสมบัติอย่าง data sovereignty, end-to-end encryption และการใช้งานออฟไลน์ ซึ่งขัดกับโมเดลรายได้เดิม ๆ อยู่แล้ว สุดท้ายจึงต้องหวังพึ่งแรงขับเคลื่อนจากชุมชนโอเพนซอร์ส
    • ทุกวันนี้เหมือนมีแค่ทางเลือก “จ่ายเงิน+ข้อมูล” หรือ “ดูโฆษณา” เท่านั้น แต่โมเดลที่จ่ายเป็นเงินสดจริง ๆ แล้วข้อมูลยังได้รับการปกป้องกลับถูกกันออกไป
    • ผมเองก็กำลังสร้างแอป local-first ชื่อ Relay ซึ่งเพิ่มความร่วมมือแบบ Google Docs ให้กับ Obsidian ผมคิดว่า business model ของมันค่อนข้างแปลกใหม่ โดยแยกบริการออกเป็น “global identity layer” และ “Relay Server" (โอเพนซอร์ส/self-hosted) ทำให้ผู้ใช้ควบคุมเนื้อหาเอกสารของตัวเองได้อย่างสมบูรณ์ พร้อมมี single sign-on และการจัดการสิทธิ์แบบง่าย ๆ ตอนนี้ได้รับความสนใจเป็นพิเศษจากบริษัทด้าน AI และ AI Safety หรือบริษัทที่ให้ความสำคัญกับ compliance ลิงก์คือ Relay.md
    • สิ่งที่ผมเห็นบ่อยรอบตัวคือ ผู้บริโภคไม่ซื้อเลยเพราะตอนซื้อมีให้เลือกแต่ subscription อยากซื้อเก็บไว้ก่อนแล้วค่อยใช้ทีหลัง แต่ข้อจำกัดต่าง ๆ (เช่น ช่วงลดราคา หรือกลับมาซื้อใหม่แล้วราคาขึ้น) กลับทำให้หมดอารมณ์ซื้อไปเลย ผมไม่คิดว่านี่จะเป็น business model ที่ดีที่สุด
    • ผมไม่คิดว่าโครงสร้างข้อมูลแบบ replicated เป็นปัญหา แอปที่ local-first อย่างเต็มตัว เช่นเกม single-player ก็ยังบังคับต่ออินเทอร์เน็ตผ่าน launcher กันบ่อยมาก
    • แอป local-first ยังมีปัญหาเรื่องความซับซ้อนรุนแรง ต้องทำให้รันได้ในสารพัดอุปกรณ์และ environment ขณะที่แอป cloud-first รันใน environment เดียวบนเซิร์ฟเวอร์ก็พอ จึงง่ายกว่าและมีค่า maintenance ต่ำกว่าเมื่อเทียบกัน
  • ในอดีตซอฟต์แวร์เดสก์ท็อปและมือถือกลับถูกมองเหมือนเป็นข้อยกเว้นแปลก ๆ ทั้งที่จริงยังเป็นวิธีแจกจ่ายซอฟต์แวร์ที่พบได้ทั่วไปมาก ในทางกลับกัน ถ้าพยายามทำฟีเจอร์ local-first ในเบราว์เซอร์ ก็ต้องแบกรับข้อเสียของเบราว์เซอร์ เช่น ปัญหาการเชื่อมต่อกับระบบโฮสต์
  • ไม่แน่ใจว่าผมพลาดอะไรไปหรือเปล่า แต่โดยทั่วไปผมรู้สึกว่าแอป “local-first” ก็ดูเป็นเรื่องธรรมดาอยู่แล้ว ผู้ใช้ส่วนใหญ่ก็ใช้แอปที่ทำงานแบบออฟไลน์อยู่มาก ถ้าหมายถึง “local-first web app” ก็น่าจะใช่มากกว่า ซึ่งจริง ๆ แล้ว “local-first web app” เองก็เป็นคอนเซ็ปต์ที่ขัดแย้งในตัว
    • ผมอยากย้อนถามว่าตอนนี้แอปส่วนใหญ่ยังเป็น local-first แบบที่ผู้ใช้จ่ายเงินใช้งานโดยตรงจริงหรือไม่ ถ้าไม่นับเกม ดูเหมือนแทบไม่มีบริษัทแบบนั้นเหลือแล้ว และแม้แต่เกม single-player ก็ยังมักต้องใช้อินเทอร์เน็ตโดยอ้าง DRM, anti-cheat, update ฯลฯ
    • คำว่า ‘local-first’ ในที่นี้หมายถึง แอปที่ไม่ได้เอา cloud storage มาเป็นค่าเริ่มต้น แต่ตั้งต้นจากข้อมูลในเครื่อง และรองรับการซิงก์กับคลาวด์
  • แม้แต่แอป offline-first ก็ยังไม่ต่างกันตรงที่พอเครือข่ายติด ๆ ดับ ๆ ก็จะมี loading spinner หมุนอยู่ดี ตัวอย่างเช่น Google Docs จะค้างตอนพยายามตรวจว่ามีเวอร์ชันใหม่ของเอกสารหรือไม่ และจะเปิดได้ทันทีต่อเมื่อบังคับตัดด้วย Airplane Mode ส่วน Spotify ก็ยังหยุดรอเพื่อดึงข้อมูลเสริมออนไลน์ แม้แต่กับ playlist ที่บันทึกไว้แล้ว สุดท้ายแล้วการเชื่อมต่อที่ไม่เสถียรคือปัญหาใหญ่ที่สุดของการพัฒนาแอปออฟไลน์ เพราะแอปมักพยายามเข้าถึงข้อมูลบนคลาวด์ “อีกสักครั้ง” อยู่เสมอ
  • แม้แต่โซลูชันในบทความเองก็ยังติดอยู่กับ closed cloud offering แบบ Firebase ซึ่งตัวมันเองก็โอเค แต่ก็น่าเสียดายที่ไม่ได้ระบุให้ชัด และใช้คำอธิบายประมาณว่า “เป็นแค่ sqlite extension” ทั้งที่จริงรองรับเฉพาะ commercial cloud ส่วน vendor อย่าง Powersync หรือ ElectricSQL อย่างน้อยก็สื่อสารเรื่องนี้อย่างโปร่งใส และ Powersync ยังเปิดให้ self-host ได้ด้วย
    • ผมยังสับสนอยู่ว่าแนวคิด local-first ใช้กับ developer tool ได้หรือไม่ รู้สึกว่าควรพิจารณาดูว่าสามารถสร้างซอฟต์แวร์ที่อิงโมเดลการเก็บข้อมูลในเครื่องด้วยเครื่องมือสาย SQLite-sync ได้หรือเปล่า ElectricSQL self-host ได้ และดูเหมือนผมควรอัปเดตรายการเครื่องมือ “sqlite sync” ของตัวเองต่อไปด้วย ลิงก์ที่เกี่ยวข้องคือ บทความต้นฉบับ local-first, SQLSync, SQLiteSync, SQLite-Sync
  • ผมคิดว่าเราต้องการแอปแบบ local-only และ self-hosted ให้มากกว่านี้ หรือจะเป็นโครงสร้างแบบ federated ก็ได้ ผมรู้สึกว่าโครงสร้างพื้นฐานเครือข่ายที่ผ่านมาเป็นอุปสรรค แต่พอมีโซลูชันอย่าง Tailscale แอปแนวนี้ก็น่าจะทำได้ง่ายขึ้นมาก
    • ผมกำลังทำซอฟต์แวร์พรีเซนเทชันอยู่ ซึ่งต้องทำงานบนเครื่อง local ได้ดีแน่นอน แต่ขณะเดียวกันก็ต้องเข้าถึงได้จากทุกที่ การทำให้ครบทั้งสองอย่างพร้อมกันยากกว่าที่คิด อย่างไรก็ตามเมื่อเทคโนโลยีก้าวหน้า การทำ direct connection หรือ P2P ผ่าน WebRTC ก็ง่ายขึ้นเรื่อย ๆ แม้การใส่ลงในผลิตภัณฑ์จริงและทดสอบจะยังท้าทาย แต่ผมคิดว่าในอนาคตจะมีซอฟต์แวร์ที่เป็น local-first และมีความสามารถด้าน networking ที่ยอดเยี่ยมเพิ่มขึ้นเรื่อย ๆ เป็นโอเพนซอร์ส รายละเอียดเพิ่มเติมดูได้จากโปรไฟล์
    • ช่วงนี้ผมเองก็กำลังสำรวจเรื่องนี้อย่างสนุก รายละเอียดเพิ่มเติมอ่านได้ ที่นี่ การสร้างแอปด้วยแนวทางใหม่ ๆ ค่อนข้างสนุกทีเดียว