Phần mềm local-first: Sở hữu dữ liệu của bạn ngay cả trong kỷ nguyên đám mây (2019)

 (inkandswitch.com)
2 điểm bởi GN⁺ 2025-07-06 | 1 bình luận | Chia sẻ qua WhatsApp
  • Ứng dụng đám mây đã cải thiện đáng kể khả năng cộng tác và truy cập từ nhiều thiết bị, nhưng vì bản sao dữ liệu có thẩm quyền nằm trên máy chủ nên quyền sở hữu và quyền kiểm soát của người dùng bị suy yếu
  • Phần mềm local-first đặt bộ nhớ cục bộ trên laptop, tablet và điện thoại làm bản sao dữ liệu chính, còn máy chủ chỉ giới hạn ở vai trò hỗ trợ đồng bộ hóa và sao lưu
  • Cách tiếp cận này đồng thời hướng tới phản hồi nhanh, làm việc ngoại tuyến, đồng bộ hóa nhiều thiết bị, cộng tác thời gian thực, lưu giữ dài hạn, cùng bảo mật và quyền riêng tư mặc định
  • File, email, ứng dụng web, đồng bộ kiểu Dropbox, Git, Firebase, CloudKit, Realm và CouchDB mỗi thứ đều có một số ưu điểm, nhưng không đáp ứng được đồng thời cả cộng tác và quyền sở hữu dữ liệu
  • Các nguyên mẫu dựa trên CRDT và Automerge đã cho thấy tiềm năng, nhưng vẫn còn những thách thức như hiệu năng, truyền thông mạng, độ ổn định P2P và UI tài liệu phân tán

Xung đột giữa cộng tác trên đám mây và quyền sở hữu dữ liệu

  • Các ứng dụng đám mây như Google Docs, Figma, Slack, Trello được truy cập qua trình duyệt hoặc ứng dụng di động và lưu dữ liệu trên máy chủ
  • Mô hình này mang lại lợi thế cộng tác thời gian thực và truy cập từ mọi nơi, nhưng mọi truy cập dữ liệu đều phải đi qua máy chủ
    • Chỉ có thể thực hiện những thao tác mà máy chủ cho phép
    • Nếu dịch vụ ngừng hoạt động, không chỉ phần mềm mà cả quyền truy cập vào dữ liệu được tạo bằng phần mềm đó cũng có thể bị chặn
    • Ngay cả khi có thể xuất dữ liệu, cũng khó tiếp tục chạy cùng phần mềm đó khi không có máy chủ
  • Ngược lại, các ứng dụng cục bộ kiểu cũ đọc và ghi file trên ổ đĩa cục bộ, nên người dùng có thể trực tiếp kiểm soát việc sao lưu, lưu trữ dài hạn, thao tác bằng chương trình khác và xóa dữ liệu
  • Căng thẳng cốt lõi nằm ở chỗ đám mây mang lại cộng tác, còn ứng dụng cục bộ mang lại quyền sở hữu; local-first là hướng thiết kế nhằm đạt được cả hai

Mô hình cơ bản của phần mềm local-first

  • Phần mềm local-first ưu tiên bộ nhớ cục bộ và mạng cục bộ hơn máy chủ trong trung tâm dữ liệu từ xa
  • Trong ứng dụng đám mây, dữ liệu trên máy chủ là nguồn gốc có thẩm quyền, còn dữ liệu trên client gần giống bộ nhớ đệm phụ thuộc vào máy chủ
  • Trong ứng dụng local-first, dữ liệu cục bộ trên mỗi thiết bị là bản sao chính, còn máy chủ có bản sao phụ để hỗ trợ truy cập từ nhiều thiết bị và sao lưu
  • Sự chuyển đổi góc nhìn này ảnh hưởng trực tiếp đến hiệu năng, khả năng dùng ngoại tuyến, lưu giữ dài hạn, quyền riêng tư và quyền kiểm soát của người dùng

7 lý tưởng của local-first

  • 1. Thao tác tức thì không có vòng xoay chờ

    • Ứng dụng đám mây phát sinh độ trễ vì việc sửa dữ liệu và nhiều truy vấn cần một lượt đi-về với máy chủ
    • Optimistic UI che giấu độ trễ bằng cách hiển thị như thể yêu cầu đã hoàn tất, nhưng khi có lỗi mạng thì độ trễ lại lộ ra
    • Ứng dụng local-first có dữ liệu chính nằm trên thiết bị cục bộ, nên thao tác nhập của người dùng ít phải chờ phản hồi từ máy chủ hơn
    • Đồng bộ hóa diễn ra trong nền, và ứng dụng có thể phản hồi gần như tức thì với dữ liệu nhập

  • 2. Công việc không bị nhốt trong một thiết bị

    • Người dùng qua lại giữa nhiều thiết bị, chẳng hạn ghi lại ý tưởng trên smartphone, sắp xếp trên tablet và viết thành tài liệu trên laptop
    • Ứng dụng local-first cũng đặt dữ liệu trên từng thiết bị, đồng thời cần đồng bộ hóa giữa tất cả thiết bị làm việc
    • Hầu hết dịch vụ đồng bộ giữa các thiết bị cũng lưu một bản sao trên máy chủ, đóng vai trò sao lưu ngoài địa điểm
    • Khi nhiều người đồng thời chỉnh sửa cùng một file, có thể phát sinh xung đột, nên thiết kế cộng tác trở nên quan trọng

  • 3. Mạng là tùy chọn

    • Máy bay, đường hầm, thang máy, bãi đỗ xe, WiFi không ổn định, chi phí roaming, môi trường Internet chưa hoàn chỉnh ở các nước đang phát triển và vùng nông thôn tạo ra nhu cầu làm việc ngoại tuyến
    • Ứng dụng đám mây nhìn chung yếu khi ngoại tuyến, và việc bổ sung hỗ trợ ngoại tuyến muộn vào mô hình lấy máy chủ làm trung tâm cũng khó khăn
    • Ứng dụng local-first lưu dữ liệu chính trong hệ thống file cục bộ của mỗi thiết bị, nên vẫn có thể đọc và ghi khi ngoại tuyến
    • Sau đó, khi có mạng, ứng dụng đồng bộ với thiết bị khác; việc đồng bộ không chỉ có thể qua Internet mà còn qua Bluetooth hoặc WiFi cục bộ
    • Để có trải nghiệm ngoại tuyến tốt, file thực thi được cài đặt cục bộ phù hợp hơn tab trình duyệt

  • 4. Cộng tác trơn tru với đồng nghiệp

    • Phần mềm cũ dựa trên file cục bộ dễ phát sinh xung đột khi nhiều người đồng thời chỉnh sửa cùng một file
    • Các ứng dụng đám mây như Google Docs đã phổ biến hóa trải nghiệm nhiều người dùng cùng chỉnh sửa tài liệu đồng thời mà không phải lo xung đột
    • Lý tưởng của local-first là hỗ trợ cộng tác thời gian thực ngang bằng hoặc tốt hơn các ứng dụng đám mây tốt nhất hiện nay
    • Luồng trong đó một người dùng đề xuất thay đổi và người khác xem xét rồi chọn lọc đưa vào cũng rất quan trọng
      • suggesting mode của Google Docs
      • pull request của GitHub

  • 5. Long Now: khả năng truy cập dài hạn

    • Một khía cạnh quan trọng của quyền sở hữu dữ liệu là vẫn phải có thể truy cập dữ liệu trong tương lai xa
    • Ứng dụng cục bộ cũ có thể tiếp tục được sử dụng nếu có dữ liệu và bản sao phần mềm có thể chạy; hệ điều hành hoặc máy tính cũ cũng có thể chạy bằng máy ảo hoặc trình giả lập
    • Ngay cả khi phương tiện lưu trữ thay đổi, file vẫn có thể được sao chép sang phương tiện mới
    • Ứng dụng đám mây phụ thuộc vào giả định rằng dịch vụ sẽ tiếp tục được cung cấp, và dễ bị ảnh hưởng bởi việc đóng dịch vụ, mất dữ liệu, thay đổi giá cả hoặc tính năng, cũng như các nâng cấp bắt buộc ngoài ý muốn
    • Phần mềm local-first lưu cục bộ dữ liệu và phần mềm đọc, sửa dữ liệu đó, nên khả năng lưu giữ dài hạn cao hơn
    • plain text, JPEG, PDF có khả năng vẫn đọc được trong thời gian dài, và Thư viện Quốc hội Hoa Kỳ khuyến nghị XML, JSON, SQLite làm định dạng bảo tồn dataset

  • 6. Bảo mật và quyền riêng tư như giá trị mặc định

    • Ứng dụng đám mây gom dữ liệu của mọi người dùng vào một cơ sở dữ liệu trung tâm, nên trở thành mục tiêu hấp dẫn với kẻ tấn công
    • Nhân viên nội bộ hoặc hacker có quyền truy cập máy chủ có thể đọc hoặc thao túng dữ liệu, và rò rỉ dữ liệu vẫn là rủi ro phổ biến
    • Điều khoản của Google Drive nêu rằng các hệ thống tự động phân tích nội dung người dùng để tạo kết quả tìm kiếm tùy chỉnh và phát hiện spam, malware
    • Với người dùng xử lý dữ liệu nhạy cảm như nhân viên y tế, nhà báo điều tra, quan chức chính phủ hoặc ngoại giao, việc dùng ứng dụng đám mây có thể xung đột với các nghĩa vụ về quy định và bảo mật
    • Ứng dụng local-first chỉ lưu dữ liệu của chính người dùng trên từng thiết bị cục bộ, và trên máy chủ có thể chỉ đặt bản sao được mã hóa đầu-cuối
    • iMessage, WhatsApp, Signal, Keybase, Tarsnap được nêu như ví dụ về mã hóa đầu-cuối hoặc chia sẻ, sao lưu file được mã hóa

  • 7. Quyền sở hữu và quyền kiểm soát cuối cùng

    • Trong ứng dụng đám mây, nhà cung cấp dịch vụ có thể hạn chế quyền truy cập của người dùng
    • Tháng 10/2017, một số người dùng Google Docs bị chặn truy cập tài liệu vì hệ thống tự động đánh dấu nhầm tài liệu là độc hại
    • Ở đây, quyền sở hữu không có nghĩa là quyền sở hữu trí tuệ, mà là năng lực hành động, tính tự chủ và quyền kiểm soát dữ liệu của người dùng
    • Trong phần mềm local-first, các byte cấu thành dữ liệu nằm trên thiết bị của người dùng, nên họ có quyền tự do xử lý theo bất kỳ cách nào
    • Quyền sở hữu dữ liệu cũng đi kèm trách nhiệm duy trì sao lưu, ngăn mất dữ liệu, ứng phó ransomware và quản lý kho lưu trữ file
    • Local-first không nhất thiết phải là mã nguồn mở; phần mềm thương mại, đóng nguồn cũng có thể tiến gần đến lý tưởng nếu không hạn chế việc sử dụng file một cách nhân tạo
    • Ví dụ về hạn chế nhân tạo gồm PDF chặn in, trình đọc eBook cản trở sao chép-dán và DRM cho file media

Những hạn chế của các mô hình lưu trữ và chia sẻ hiện có

  • Tệp và tệp đính kèm email

    • Tệp truyền thống mạnh ở khả năng xem/chỉnh sửa ngoại tuyến, quyền kiểm soát của người dùng, sao lưu, lưu giữ lâu dài và truy cập nhanh
    • Để truy cập trên nhiều thiết bị, cần các cách như email, USB, NAS/NFS/FTP/rsync, đồng bộ tệp kiểu Dropbox, hoặc Git
    • Tệp đính kèm email dễ hiểu và đáng tin cậy; sau 6 tháng, tệp đính kèm vẫn còn nguyên ở dạng ban đầu
    • Điểm yếu là cộng tác
      • Thông thường mỗi lần chỉ một người có thể chỉnh sửa tệp
      • Nếu nhiều người cùng chỉnh sửa thì cần hợp nhất thủ công
      • Dễ nảy sinh sự lộn xộn về tên tệp như Budget draft 2 (Jane's version) final final 3.xls
    • Các ứng dụng muốn áp dụng ý tưởng local-first có thể bắt đầu bằng việc cung cấp xuất dữ liệu sang các định dạng được hỗ trợ rộng rãi như plain text, PDF, PNG, JPEG

  • Ứng dụng web

    • Các ứng dụng web như Google Docs, Trello, Figma, Pinterest có trình duyệt hoặc ứng dụng di động là client mỏng, còn kho dữ liệu nằm trên máy chủ
    • Ứng dụng web đã đặt ra chuẩn mực cho cộng tác thời gian thực, và có lợi thế lớn là trong làm việc nhóm, mọi người có thể xem phiên bản mới nhất ở bất cứ đâu
    • Ngược lại, quyền sở hữu và quyền kiểm soát bị giảm đi đáng kể
      • Dữ liệu trên máy chủ là nguồn chuẩn, còn dữ liệu ở client gần giống bộ nhớ đệm
      • Chỉ cần mạng bị ngắt tạm thời cũng có thể khiến bạn mất quyền truy cập giữa chừng khi đang làm việc
      • Hỗ trợ ngoại tuyến hạn chế như Google Docs offline plugin gần như là thứ được gắn thêm về sau vào kiến trúc lấy máy chủ làm trung tâm
    • Ngay cả các client desktop cài đặt được như Milanote và Figma về bản chất cũng là trình duyệt được đóng gói lại, nên bộc lộ hạn chế khi có sự cố mạng, máy chủ ngừng hoạt động hoặc dịch vụ chấm dứt

  • Dropbox, Google Drive, Box, OneDrive

    • Dropbox, Google Drive, Box, OneDrive giám sát một thư mục được chỉ định trên desktop và sao chép các tệp đã thay đổi sang các máy tính khác
    • Vì dùng hệ thống tệp cục bộ nên nhanh và có thể làm việc ngoại tuyến; ngay cả khi dịch vụ đồng bộ chấm dứt, các tệp trên ổ đĩa cục bộ vẫn còn
    • Khi ổ cứng gặp lỗi, có thể cài ứng dụng và chờ đồng bộ để khôi phục, nên có lợi thế về tính lâu dài và quyền kiểm soát
    • Trên iOS và Android di động, chúng gần với mô hình client mỏng hơn: không đồng bộ toàn bộ thư mục mà lấy từng tệp từ máy chủ
    • Tùy chọn “Make available offline” phải được chỉ định trước, phiền phức và chỉ hoạt động khi ứng dụng đang mở
    • Điểm yếu nhất là cộng tác thời gian thực
      • Nếu cùng một tệp được chỉnh sửa trên hai thiết bị, sẽ phát sinh xung đột cần hợp nhất thủ công
      • Khả năng đồng bộ định dạng tệp bất kỳ là lợi thế về tương thích, nhưng cũng là điểm yếu vì không thể hợp nhất theo từng định dạng

  • Git và GitHub

    • Git và GitHub chủ yếu được dùng cho cộng tác mã nguồn, và hiện được đánh giá là gói phần mềm gần với local-first nhất
    • Kho Git là bản sao dữ liệu chính trên hệ thống tệp cục bộ và không phụ thuộc vào máy chủ
    • Cung cấp khả năng làm việc ngoại tuyến hoàn toàn, hoạt động nhanh, quyền kiểm soát của người dùng và phù hợp để lưu giữ lâu dài
    • GitHub cung cấp cộng tác, truy cập từ nhiều thiết bị, sao lưu và nơi lưu trữ, nhưng không mã hóa kho
    • Git có hai điểm yếu lớn
      • Không có cộng tác tự động hợp nhất thời gian thực ở mức chi tiết như Google Docs, Trello, Figma
      • Được tối ưu cho mã và văn bản theo dòng; các định dạng tệp khác bị xử lý như blob nhị phân khó chỉnh sửa và hợp nhất một cách có ý nghĩa
    • Việc nhiều kỹ sư phần mềm nêu các lý do như “chậm”, “không tin tưởng”, “muốn để mã trên hệ thống cục bộ” khi ngại dùng các trình chỉnh sửa và môi trường chạy dựa trên đám mây như Cloud9, Repl.it, Colaboratory, có liên quan trực tiếp đến động lực local-first

Các lựa chọn nhìn từ góc độ hạ tầng dành cho nhà phát triển

  • Ứng dụng web client mỏng

    • Đây là mô hình trong đó máy chủ Rails, Django, PHP, Node.js lưu dữ liệu vào cơ sở dữ liệu SQL hoặc NoSQL và cung cấp trang web qua HTTPS
    • Không cần cài đặt, người dùng chỉ cần truy cập URL, còn trách nhiệm quản lý dữ liệu thuộc về đội ngũ engineering/DevOps đã triển khai
    • Meteor, ShareDB, Pusher, Ably, WebSocket giúp việc thêm tính năng cộng tác thời gian thực vào ứng dụng web dễ dàng hơn
    • Nếu mỗi hành động của người dùng đều cần yêu cầu tới máy chủ thì sẽ chậm; ngay cả khi dùng JavaScript phía client để che giấu thời gian khứ hồi, nó vẫn dễ hỏng khi Internet không ổn định
    • Bất chấp các nỗ lực như manifest, localStorage, service worker, Progressive Web Apps, kiến trúc ứng dụng web về căn bản vẫn lấy máy chủ làm trung tâm
    • Khi xóa cookie trong trình duyệt, dữ liệu trong bộ nhớ cục bộ cũng thường bị xóa theo, nên không phù hợp để lưu dữ liệu quan trọng về lâu dài
    • Nếu người dùng tự host ứng dụng web mã nguồn mở, một số đặc tính có thể được cải thiện; nhưng vì hầu hết người dùng không muốn trở thành quản trị viên hệ thống, tự host không phải lựa chọn thực tế cho đa số

  • Ứng dụng di động dùng lưu trữ cục bộ

    • Ứng dụng iOS và Android tải xuống binary và cài đặt cục bộ, nhưng nhiều ứng dụng như Twitter, Yelp, Facebook là client mỏng cần máy chủ để hoạt động
    • Những ứng dụng trước tiên lưu dữ liệu trên thiết bị cục bộ bằng các lớp lưu bền như SQLite, Core Data, hoặc tệp thông thường thì gần hơn với lý tưởng local-first
    • Clue và Things là các trường hợp bắt đầu như ứng dụng một người dùng, sau đó thêm backend đám mây để đồng bộ giữa thiết bị hoặc chia sẻ
    • Các ứng dụng client dày như vậy nhanh và hoạt động được ngoại tuyến vì đồng bộ với máy chủ diễn ra ở nền
    • Độ khó tăng lên khi nhiều thiết bị hoặc nhiều người dùng cộng tác cùng sửa dữ liệu
    • Nhà phát triển ứng dụng di động thường là chuyên gia phát triển ứng dụng cho người dùng cuối, không phải chuyên gia hệ thống phân tán
    • Các thuật toán diff/merge/giải quyết xung đột tạm bợ thường có độ tin cậy thấp và dễ lỗi

  • Firebase, CloudKit, Realm

    • Firebase là BaaS di động kết hợp cơ sở dữ liệu trên thiết bị cục bộ, dịch vụ cơ sở dữ liệu đám mây và đồng bộ giữa hai phía
    • Firebase hỗ trợ chia sẻ trên nhiều thiết bị và sử dụng ngoại tuyến, nhưng vì là dịch vụ hosting độc quyền nên điểm về quyền riêng tư và tính lâu dài thấp
    • Parse sau khi được Facebook mua lại đã đóng cửa vào năm 2017, khiến các ứng dụng phụ thuộc vào nó phải chuyển sang backend khác
    • Firebase console mang lại trải nghiệm tốt cho nhà phát triển trong việc xem, sửa và xóa dữ liệu, nhưng người dùng không có phương tiện tương ứng để truy cập, thao tác và quản lý dữ liệu
    • Apple CloudKit cung cấp trải nghiệm tương tự Firebase cho các ứng dụng có thể giới hạn ở iOS và Mac
      • Lưu trữ khóa-giá trị và đồng bộ
      • Chức năng ngoại tuyến tốt
      • Được tích hợp trong nền tảng, giảm phiền phức khi tạo tài khoản và đăng nhập
    • Realm trở nên phổ biến như một thư viện lưu bền cục bộ cho iOS, và Realm Object Server là mã nguồn mở, có thể tự host, giúp giảm rủi ro phụ thuộc vào dịch vụ

  • CouchDB

    • CouchDB thu hút chú ý nhờ cách tiếp cận multi-master replication, trong đó nhiều máy có bản sao cơ sở dữ liệu đầy đủ và mỗi bản sao có thể tạo thay đổi độc lập
    • Cloudant là phiên bản được host, còn PouchDB và Hoodie được thiết kế để chạy trên thiết bị của người dùng cuối trong khi dùng cùng giao thức đồng bộ
    • Về mặt triết lý, CouchDB gần với các nguyên tắc local-first, nhưng đồng thời, dữ liệu bị thay đổi cần được mã ứng dụng giải quyết xung đột một cách tường minh
    • Trong các ứng dụng cộng tác chi tiết, nơi mỗi lần gõ phím có thể là một thay đổi riêng như Google Docs, rất khó viết mã giải quyết xung đột đúng
    • Các lý do được đưa ra cho việc CouchDB chưa được áp dụng rộng rãi gồm khả năng mở rộng khi mỗi người dùng có DB riêng, nhúng client JavaScript trong ứng dụng native iOS/Android, giải quyết xung đột, và sự xa lạ của mô hình truy vấn MapReduce

CRDT và công nghệ nền tảng tốt hơn

  • Lớp dữ liệu dùng cho phát triển ứng dụng hiện nay không đáp ứng được tất cả các lý tưởng local-first
  • Ink & Switch đã nghiên cứu từ 3 năm trước để tìm lời giải, và đề xuất Conflict-free Replicated Data Types hay CRDT như một nền tảng đầy hứa hẹn
  • CRDT là một cấu trúc dữ liệu đa dụng xuất hiện từ nghiên cứu khoa học máy tính học thuật năm 2011
  • Giống như các cấu trúc dữ liệu như hashmap hay list, CRDT lưu trữ trạng thái tài liệu, nhưng ngay từ đầu đã tính đến môi trường nhiều người dùng
  • Trình soạn thảo văn bản, bảng tính và ứng dụng đồ họa vector đều duy trì trạng thái tài liệu riêng dưới dạng cấu trúc dữ liệu; trong các ứng dụng nhiều người dùng cộng tác, có thể thay thế chúng bằng CRDT

  • Cách CRDT hợp nhất

    • Người dùng có thể xem và chỉnh sửa trạng thái ứng dụng trên thiết bị cục bộ ngay cả khi ngoại tuyến
    • CRDT theo dõi các thay đổi và đồng bộ với các thiết bị khác trong nền khi có mạng
    • Nếu cùng lúc thêm các việc cần làm mới trên các thiết bị khác nhau, trạng thái sau khi hợp nhất sẽ chứa tất cả các mục đã thêm theo một thứ tự nhất quán
    • Các thay đổi đồng thời trên các đối tượng khác nhau có thể được hợp nhất dễ dàng
    • Trường hợp khó tự động giải quyết là khi nhiều người dùng cùng lúc cập nhật cùng một thuộc tính của cùng một đối tượng; CRDT theo dõi các giá trị xung đột và để ứng dụng hoặc người dùng giải quyết
    • CRDT giống Git, nhưng hoạt động với các kiểu dữ liệu phong phú hơn tệp văn bản
    • Kênh đồng bộ có thể là bất cứ thứ gì: máy chủ, kết nối P2P, Bluetooth, USB, v.v.
    • Đơn vị thay đổi có thể nhỏ như một lần gõ phím, cho phép cộng tác thời gian thực kiểu Google Docs, hoặc cũng có thể được gửi thành các gói lớn như pull request của Git

  • Automerge và Hypermerge

    • Ink & Switch đã phát triển Automerge, một triển khai CRDT JavaScript mã nguồn mở
    • Automerge dựa trên nghiên cứu JSON CRDT
    • Họ kết hợp Automerge với Dat networking stack để tạo ra Hypermerge
    • Khó có thể nói các thư viện này đã hiện thực hóa hoàn toàn lý tưởng local-first, và vẫn còn cần nhiều công việc hơn
    • CRDT có tiềm năng trở thành công nghệ nền tảng cho phần mềm cộng tác nơi người dùng sở hữu dữ liệu, giống như packet switching của Internet hay capacitive touchscreen của smartphone

Nguyên mẫu của Ink & Switch

  • Dù thuật toán CRDT và việc kiểm chứng lý thuyết đã có tiến triển trong giới học thuật, việc sử dụng trong công nghiệp vẫn còn ít và phần lớn được dùng trong điện toán lấy máy chủ làm trung tâm
  • Các ví dụ về hệ thống lấy máy chủ làm trung tâm dùng CRDT được nêu gồm Azure Cosmos DB, Redis, Riak, Weave Mesh, SoundCloud Roshi và Facebook OpenR
  • Ink & Switch đã tạo các nguyên mẫu ứng dụng cộng tác local-first cho công việc sáng tạo, sử dụng CRDT trên thiết bị của người dùng cuối
  • Các thử nghiệm xoay quanh ba câu hỏi
    • Tính khả thi về kỹ thuật: CRDT gần với phần mềm thực tế đến mức nào
    • Trải nghiệm người dùng: Có thể cộng tác thời gian thực như Google Docs và cộng tác bất đồng bộ thân thiện với ngoại tuyến như Git mà không cần máy chủ có thẩm quyền trung tâm hay không
    • Trải nghiệm lập trình viên: Lớp dữ liệu CRDT khác SQL DB, hệ thống tệp và Core Data như thế nào
  • Ba nguyên mẫu được xây dựng bằng Electron, JavaScript và React; họ xem việc đây là phần mềm có thể tải xuống và cài đặt là quan trọng đối với cảm giác sở hữu

  • Trellis

    • Trellis là một Kanban board mô phỏng theo Trello
    • Họ thử nghiệm WebRTC làm lớp truyền thông mạng
    • Thiết kế lịch sử thay đổi lấy cảm hứng từ “See New Changes” của Git và Google Docs
    • Người dùng có thể xem các tác vụ trên Kanban board và quay lại trạng thái trước đó của tài liệu

  • Pixelpusher

    • Pixelpusher là chương trình vẽ cộng tác, thêm trải nghiệm cộng tác thời gian thực kiểu Figma vào Pixel Art to CSS của Javier Valencia
    • Họ thử nghiệm truyền thông mạng bằng thư viện P2P của dự án Dat
    • Họ thử nghiệm URL chia sẻ tài liệu, branch/merge trực quan lấy cảm hứng từ Git, giải quyết xung đột bằng cách tô đỏ các pixel xung đột, và nhận diện người dùng cơ bản dựa trên avatar do người dùng vẽ

  • PushPin

    • PushPin là mixed media canvas workspace tương tự Miro hoặc Milanote
    • Đây là dự án thứ ba dựa trên Automerge và là nguyên mẫu hoàn thiện nhất trong ba nguyên mẫu
    • Việc đội ngũ và người dùng thử nghiệm bên ngoài sử dụng thực tế đặt tải lớn hơn lên underlying data layer
    • Họ thử nghiệm các tài liệu chia sẻ lồng nhau và liên kết với nhau, nhiều renderer khác nhau cho tài liệu CRDT, hệ thống danh tính phát triển hơn bao gồm mô hình outbox, và chia sẻ dữ liệu tạm thời như tô nổi vùng chọn

Kết quả thu được từ các nguyên mẫu

  • Mục tiêu của ba nguyên mẫu là đánh giá tính khả thi về kỹ thuật, trải nghiệm người dùng và trải nghiệm nhà phát triển của phần mềm local-first và CRDT
  • 5 thành viên trong nhóm phát triển đã sử dụng thường xuyên, và nhóm cũng tiến hành các bài kiểm thử khả dụng riêng lẻ với khoảng 10 người dùng bên ngoài
    • Người dùng bên ngoài bao gồm nhà thiết kế chuyên nghiệp, quản lý sản phẩm và kỹ sư phần mềm
    • Nhóm sử dụng cách tiếp cận khám phá, không phải một phương pháp đánh giá chính thức

  • Công nghệ CRDT hoạt động

    • Độ tin cậy của Automerge tốt hơn dự kiến
    • Các nhà phát triển ứng dụng trong nhóm có thể tích hợp thư viện tương đối dễ dàng, và việc tự động hợp nhất dữ liệu hầu như luôn trực quan và mượt mà

  • Trải nghiệm người dùng ngoại tuyến rất tốt

    • Luồng chuyển sang ngoại tuyến, làm việc bao lâu tùy ý, rồi sau khi kết nối lại thì hợp nhất với các thay đổi của đồng nghiệp hoạt động tốt
    • Ngay cả khi các ứng dụng khác hiển thị cảnh báo “offline” và lỗi, chặn không cho làm việc, nguyên mẫu local-first vẫn hoạt động bình thường bất kể trạng thái mạng
    • Khác với các hệ thống dựa trên trình duyệt, người dùng ít phải lo lắng hơn về việc ứng dụng có chạy hay không, dữ liệu có còn hay không, đồng thời có cảm giác sở hữu công cụ và sản phẩm công việc của mình

  • Phù hợp tốt với mô hình FRP của React

    • Mô hình Functional Reactive Programming của React phù hợp tốt với CRDT
    • Trong tầng dữ liệu dựa trên CRDT, tài liệu đồng thời nhận đầu vào từ người dùng cục bộ và các thay đổi từ người dùng/thiết bị khác đến qua mạng
    • Mô hình FRP đồng bộ hóa ổn định trạng thái ứng dụng hiển thị với underlying state của tài liệu chia sẻ
    • Nhà phát triển được giải phóng khỏi công việc rườm rà là theo dõi các thay đổi đến từ người dùng khác và điều phối chúng với màn hình hiện tại
    • Nếu cho mọi thay đổi trạng thái đi qua một hàm reducer duy nhất, việc gửi các thay đổi cục bộ liên quan cho người dùng khác cũng trở nên dễ dàng

  • Xung đột ít nghiêm trọng hơn dự kiến

    • Người dùng hiếm khi gặp xung đột trong lúc cộng tác, và các cơ chế giải quyết chung hoạt động tốt
    • Automerge theo dõi thay đổi ở mức rất chi tiết và xét đến ngữ nghĩa của kiểu dữ liệu
    • Nếu hai người dùng đồng thời chèn mục vào cùng một vị trí trong mảng, hai mục sẽ được kết hợp theo một thứ tự xác định
    • Các hệ thống quản lý phiên bản văn bản như Git có thể xem đây là xung đột cần giải quyết thủ công
    • Người dùng có trực giác về cộng tác, nên đôi khi ngầm chia vùng làm việc để tránh chỉnh sửa cùng một mục đồng thời
    • Trong ứng dụng Kanban, nếu một người dùng bình luận trên một thẻ và người dùng khác chuyển thẻ đó sang cột khác, cả hai thay đổi đều được phản ánh
    • Xung đột chỉ xảy ra khi cùng một thuộc tính của cùng một đối tượng bị chỉnh sửa đồng thời; ví dụ được nêu là hai người dùng đồng thời thay đổi vị trí của cùng một đối tượng ảnh
    • Trong các nguyên mẫu, chỉ riêng ngữ nghĩa hợp nhất mặc định của Automerge đã đủ, và nhóm không tìm thấy trường hợp nào cần ngữ nghĩa tùy chỉnh

  • Trực quan hóa lịch sử tài liệu là quan trọng

    • Trong hệ thống cộng tác phân tán, nhiều thay đổi từ người dùng khác có thể đến bất cứ lúc nào
    • Vì không có máy chủ trung tâm đứng ra trung gian cho các thay đổi, cần có công cụ để hiểu con đường khiến tài liệu đạt đến trạng thái hiện tại, các phiên bản đang tồn tại và nguồn đóng góp
    • Trellis thử nghiệm giao diện “time travel” cho phép người dùng di chuyển về các trạng thái trước đây của tài liệu đã được hợp nhất để xem
    • Nhóm cũng thử nghiệm cách tự động làm nổi bật các yếu tố thay đổi mới nhận

  • Chia sẻ bằng URL là tự nhiên

    • Trong số nhiều cơ chế chia sẻ tài liệu, mô hình URL lấy cảm hứng từ web là cách tự nhiên nhất với cả người dùng lẫn nhà phát triển
    • URL có thể được sao chép/dán và chia sẻ qua các kênh liên lạc như email hoặc chat
    • Quyền truy cập tài liệu vượt ra ngoài URL bí mật vẫn là một câu hỏi nghiên cứu còn bỏ ngỏ

  • Hệ thống P2P không chia đơn giản thành trực tuyến/ngoại tuyến

    • Hệ thống tập trung thường định nghĩa trạng thái “up” hoặc “down” dựa trên việc có kết nối ổn định với máy chủ hay không
    • Trong hệ thống phân tán, mỗi người dùng có thể có góc nhìn khác nhau tùy theo dữ liệu họ đang có, chia sẻ và chấp nhận
    • Nội dung chỉnh sửa trên laptop trong máy bay có thể được phân phối cho người dùng khác sau khi hạ cánh và kết nối lại
    • Người dùng khác có thể chấp nhận toàn bộ, một phần hoặc không chấp nhận gì trong số các thay đổi đó vào phiên bản tài liệu của họ
    • Giống như kho Git, “master” của một người dùng cụ thể trở thành một hàm của thời điểm gần nhất họ giao tiếp với người dùng khác
    • Tài liệu phân tán trao quyền kiểm soát dữ liệu cho người dùng, nhưng điều đó có ý nghĩa gì từ góc độ UI thực tế thì cần nghiên cứu thêm

  • Lịch sử thay đổi dài gây ra vấn đề hiệu năng

    • Khi dùng PushPin cho tài liệu thực tế như lập kế hoạch sprint, hiệu năng cũng như mức sử dụng bộ nhớ và ổ đĩa nhanh chóng trở thành vấn đề
    • CRDT lưu toàn bộ lịch sử, bao gồm cả chỉnh sửa văn bản theo từng ký tự
    • Sau 6 tháng, có thể có ai đó kết nối lại với tài liệu và cần hợp nhất các thay đổi kể từ thời điểm đó, nên không thể dễ dàng cắt bỏ lịch sử
    • Việc tối ưu hóa Automerge vẫn đang tiếp tục và còn là một mảng công việc lớn đang diễn ra

  • Giao tiếp mạng vẫn chưa được giải quyết

    • Thuật toán CRDT chỉ xử lý việc hợp nhất dữ liệu, chứ không xử lý cách các chỉnh sửa của người dùng khác thực sự đến cùng một máy tính về mặt vật lý
    • Trong thử nghiệm, nhóm đã thử WebRTC, một triển khai sneakernet sao chép tệp bằng Dropbox và USB key, khả năng dùng giao thức IPFS, cùng thư viện P2P Hypercore của Dat
    • CRDT không nhất thiết đòi hỏi tầng mạng P2P; giao tiếp thông qua máy chủ cũng khả thi
    • Để hiện thực hóa đầy đủ mục tiêu dài hạn về tính bền vững của local-first, lời giải phi tập trung sống lâu hơn các dịch vụ backend của nhà cung cấp là đích đến logic cuối cùng
    • Công nghệ P2P chưa đủ sẵn sàng cho production, đặc biệt NAT traversal có độ tin cậy thấp tùy theo router hoặc topology mạng
    • Trải nghiệm cộng tác thời gian thực trực tiếp giữa các máy tính mà không cần truy cập Internet cho thấy tiềm năng lớn trong một thế giới đang phụ thuộc vào API trung tâm

  • Máy chủ đám mây vẫn giữ vai trò hỗ trợ

    • Các nguyên mẫu cộng tác thời gian thực như PushPin có thể chia sẻ tài liệu mà không cần máy chủ trung gian, điều này tốt cho quyền riêng tư và quyền sở hữu
    • Tuy nhiên, nếu người dùng chia sẻ tài liệu rồi đóng laptop trước khi bên kia kết nối, hai người dùng không đồng thời trực tuyến nên không thể kết nối
    • Trong thế giới local-first, máy chủ có thể đóng vai trò cloud peer thay vì quyền lực trung tâm
      • Lưu bản sao tài liệu rồi chuyển tiếp khi peer khác trực tuyến
      • Cung cấp vị trí lưu trữ và sao lưu
      • Làm cầu nối tới các API máy chủ truyền thống như dự báo thời tiết hoặc giá cổ phiếu
      • Cung cấp burst computing như render video bằng GPU mạnh
    • Khác biệt giữa hệ thống truyền thống và hệ thống local-first không nằm ở việc có hay không có máy chủ, mà ở chỗ máy chủ không phải nguồn chân lý, mà đảm nhiệm vai trò hỗ trợ

Những việc cần làm trong tương lai

  • Nhà nghiên cứu hệ thống phân tán và ngôn ngữ lập trình

    • Nghiên cứu về CRDT và công nghệ P2P có thể đóng góp lớn cho phần mềm local-first
    • Nghiên cứu CRDT hiện nay thường giả định mô hình trong đó mọi cộng tác viên áp dụng chỉnh sửa ngay lập tức vào một phiên bản tài liệu duy nhất
    • Ứng dụng local-first thực tế cần có khả năng từ chối chỉnh sửa của cộng tác viên khác, hoặc tạo các thay đổi riêng tư trên một phiên bản tài liệu không được chia sẻ
    • Còn thiếu nghiên cứu mở rộng các khái niệm kiểm soát nguồn phân tán như branch, fork, rebase thành mô hình cộng tác nơi nhiều phiên bản tài liệu và branch cùng tồn tại song song
    • Kiểu dữ liệu, migration schema và tính tương thích cũng là những vấn đề quan trọng
      • Mỗi cộng tác viên có thể dùng các phiên bản và tính năng ứng dụng khác nhau
      • Vì không có máy chủ DB trung tâm, không tồn tại schema “hiện tại” có thẩm quyền của dữ liệu
      • Trong khi định dạng dữ liệu tiến hóa, nhiều phiên bản ứng dụng phải tương tác an toàn với nhau

  • Nhà nghiên cứu HCI

    • Trong các hệ thống tập trung có nhiều ví dụ hiển thị trạng thái đồng bộ với máy chủ, nhưng hệ thống phi tập trung có các vấn đề UI mới
    • Cần nghiên cứu cách truyền đạt trạng thái online/offline, khả dụng/không khả dụng trong hệ thống nơi mọi người dùng đều có thể có các bản sao dữ liệu khác nhau
    • Khi có thể cộng tác trực tiếp với các node khác mà không cần Internet diện rộng, ý nghĩa của “online” cũng thay đổi
    • Vì mọi tài liệu có thể có lịch sử phiên bản phức tạp chỉ qua việc sử dụng hằng ngày, cần UI giúp người dùng hiểu phiên bản, việc chấp nhận thay đổi và quá trình hình thành tài liệu
    • Hiện nay, quản lý thay đổi chủ yếu dựa trên mô hình diff/patch kiểu mã nguồn và mô hình suggestion/comment kiểu Google Docs
    • Cách khái quát hóa các ý tưởng này cho các định dạng dữ liệu không phải văn bản vẫn là một vấn đề mở
    • Trong local-first, không thể ngăn người dùng đang giữ dữ liệu chỉnh sửa cục bộ; khái niệm quyền hạn thay đổi theo hướng người dùng khác chọn có subscribe những thay đổi đó hay không

  • Người làm thực tiễn

    • Kỹ sư, nhà thiết kế, product manager và nhà phát triển độc lập xây dựng phần mềm production có thể thực hiện các bước tăng dần hướng tới tương lai local-first
    • Để ứng dụng nhanh hơn, có thể giảm spinner khi mở tài liệu bằng caching tích cực và tải trước, đồng thời mặc định tin cậy cache cục bộ
    • Đa thiết bị có thể được hỗ trợ tương đối dễ bằng hạ tầng đồng bộ như Firebase và iCloud, nhưng có các lo ngại về tính lâu dài và quyền riêng tư
    • Với offline trên web, Progressive Web Apps, Service Workers và app manifest có thể hỗ trợ
    • Có thể kiểm thử ứng dụng bằng cách tắt WiFi hoặc thay đổi điều kiện mạng bằng các công cụ như Chrome DevTools network condition simulator, iOS network link conditioner
    • Với cộng tác, ngoài CRDT, Operational Transformation được triển khai trong ShareDB và các hệ thống khác là công nghệ đã được thiết lập vững chắc hơn
    • Để lưu trữ dài hạn, cần có khả năng xuất dễ dàng sang các định dạng ổn định như JSON, PDF
      • Xuất hàng loạt như Google Takeout
      • Sao lưu liên tục bằng định dạng tệp ổn định của GoodNotes
      • Tải xuống tài liệu JSON của Trello
    • Về quyền riêng tư, cần thông báo rõ cho người dùng biết dữ liệu chỉ được lưu trên thiết bị hay được gửi tới backend
    • Để đảm bảo quyền kiểm soát của người dùng, việc sao lưu, sao chép và xóa tài liệu trong ứng dụng phải dễ dàng; ví dụ được nêu là Google Docs đã tái triển khai các thao tác hệ thống tệp cơ bản thông qua Google Drive

Cơ hội startup và kết luận

  • Với các nhà sáng lập muốn xây dựng hạ tầng cho nhà phát triển, “Firebase for CRDTs” được xem là một cơ hội thị trường thú vị
  • Một startup như vậy cần cung cấp trải nghiệm nhà phát triển tốt và các thư viện lưu trữ cục bộ bền vững như SQLite hoặc Realm
  • Cần hỗ trợ iOS, Android, Windows, Mac, Linux, Electron và Progressive Web Apps
  • Quyền kiểm soát của người dùng, quyền riêng tư, hỗ trợ đa thiết bị và cộng tác cần được tích hợp mặc định
  • Phép thử litmus cho thành công là liệu ứng dụng của khách hàng có tiếp tục hoạt động vĩnh viễn ngay cả khi mọi máy chủ bị tắt hay không
  • Phần mềm đám mây đã mang lại khả năng cộng tác và các ứng dụng luôn cập nhật có thể truy cập ở mọi nơi, nhưng khi đặt quyền sở hữu dữ liệu trên máy chủ, nó biến người dùng thành người thuê chính dữ liệu của mình
  • Cách tiếp cận local-first cho thấy người dùng có thể giữ quyền sở hữu và kiểm soát dữ liệu, đồng thời vẫn có được khả năng cộng tác và truy cập kiểu đám mây
  • Để triển khai thực tế, vẫn cần cải thiện hơn nữa hỗ trợ offline, tận dụng lưu trữ trên thiết bị, thuật toán, mô hình lập trình và giao diện người dùng, cũng như đưa CRDT và mạng P2P thành sản phẩm

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-07-06
Ý kiến trên Hacker News

  • Hoàn toàn đồng ý. Tôi đã chán ngấy xu hướng mọi dịch vụ đều lấy dữ liệu của tôi đưa lên cloud của họ, rồi muốn dùng cho tử tế thì bắt trả phí thuê bao
    Ứng dụng theo dõi fitness tôi đang làm sẽ đi theo mô hình “mua một lần thì nhận cập nhật trong X năm, đồng bộ với mọi thiết bị, và sau đó vẫn dùng vĩnh viễn”. Sau X năm, nếu cần cập nhật thì mua lại phiên bản mới; nếu các tính năng hiện tại đã đủ thì cứ tiếp tục dùng
    Tôi mong phần lớn phần mềm đều có thể mua được với mức giá hợp lý như vậy, bản thân sản phẩm tốt, và không bị trói đến mức không có cloud thì không dùng được. Điểm hay nhất của phần mềm local-first là nó khôi phục động lực lành mạnh để kiếm tiền bằng chất lượng sản phẩm, thay vì quảng cáo, theo dõi và tối đa hóa mức độ tương tác

    • Obsidian cũng là một mô hình đáng tham khảo. Client hoàn toàn miễn phí, họ chỉ bán dịch vụ đồng bộ tùy chọn
      Ghi chú đều là file Markdown, nên bản thân client cũng trở thành tùy chọn
    • Tôi tò mò bạn định đồng bộ thế nào nếu không có hạ tầng cloud
    • “X năm cập nhật + đồng bộ thiết bị + dùng vĩnh viễn” nghe có vẻ hay, nhưng với cách này bạn phải thu một lần số tiền tương đương tổng chi phí thuê bao của 1–2 năm
      Máy chủ đồng bộ vẫn phải vận hành liên tục, và cũng phải tính đến trường hợp người dùng dồn dữ liệu của cả 1 năm để đồng bộ trong một ngày. Nhân lực phụ trách phát triển trong tương lai cũng vẫn phải được trả lương đều, nên nếu chỉ nhìn từ góc độ nhà phát triển thì có những phần bị bỏ sót
    • Vài năm trước, một nhà máy địa phương đã phải dừng sản xuất hai ngày vì sự cố máy chủ của nhà cung cấp IT, khiến tôi cũng nghĩ tương tự khi hình dung tình huống xấu nhất
      https://rodyne.com/?p=1439
    • Backend có thể là một phần của tính năng, như cộng tác thời gian thực hoặc đồng bộ. Tuy nhiên, nếu có thể thoát khỏi cloud (ejectable) và bất cứ lúc nào cũng chuyển sang tự host hoặc quay lại, thì có thể bảo đảm quyền sở hữu và tính lâu dài cho cả dữ liệu lẫn dịch vụ
      IDE ghi chú/tác vụ mà chúng tôi đang làm cũng theo cách này: https://thymer.com/local-first-ejectable

  • Ở Berlin có Local-first Software Conference hằng năm do Ink and Switch tổ chức, và tháng 11 năm nay tại SF cũng có một sự kiện phái sinh tên là Sync Conf
    https://www.localfirstconf.com/
    https://syncconf.dev/
    Năm nay có một panel rất hay, trong đó các đồng tác giả của bài báo gốc bàn về phần mềm local-first là gì trong bối cảnh công cụ phát triển, và họ đã học được gì kể từ bài báo gốc: https://youtu.be/86NmEerklTs?si=Kodd7kD39337CTbf
    Cộng đồng đang dần thống nhất theo hướng xem “đồng bộ” là một thành phần của local-first, nhưng là một công nghệ có thể áp dụng rộng hơn nhiều. Local-first là một đặc tính của phần mềm dành cho người dùng cuối, còn các công cụ phát triển như sync engine là công cụ giúp điều đó khả thi, chứ bản thân chúng không nhất thiết là local-first
    Toàn bộ các bài nói trong vài năm qua có ở đây: https://youtube.com/@localfirstconf?si=uHHi5Tsy60ewhQTQ
    Đây là thời điểm thú vị với cộng đồng local-first/sync engine. Họ đã xây dựng các công cụ cho phép trải nghiệm cộng tác thời gian thực và cộng tác bất đồng bộ, và với sự xuất hiện của AI, thị trường này đang mở rộng. Về bản chất, mọi ứng dụng AI đều là hệ thống cộng tác đa người dùng trong đó agent tham gia như một tác nhân, nên chúng cần những công nghệ mà cộng đồng sync engine vẫn xử lý

    • Cũng có một podcast Local First rất hay, phỏng vấn các kỹ sư xây dựng ứng dụng và hạ tầng local-first
      https://www.localfirst.fm/

  • Đáng đọc, và trước đây cũng đã có nhiều cuộc thảo luận sôi nổi
    https://news.ycombinator.com/item?id=19804478 - tháng 5/2019, 191 bình luận
    https://news.ycombinator.com/item?id=21581444 - tháng 11/2019, 241 bình luận
    https://news.ycombinator.com/item?id=23985816 - tháng 7/2020, 9 bình luận
    https://news.ycombinator.com/item?id=24027663 - tháng 8/2020, 134 bình luận
    https://news.ycombinator.com/item?id=26266881 - tháng 2/2021, 90 bình luận
    https://news.ycombinator.com/item?id=31594613 - tháng 6/2022, 30 bình luận
    https://news.ycombinator.com/item?id=37743517 - tháng 10/2023, 50 bình luận

  • Những thứ phụ thuộc vào trực tuyến chắc chắn kéo theo bảo trì liên tục và chi phí. Nếu hệ thống không ưu tiên cục bộ, tốt nhất là chỉ cục bộ, thì nó không được thiết kế cho độ tin cậy dài hạn
    Thiết bị gia dụng và ô tô kết nối mạng, nhìn từ góc độ thực dụng, gần như là kiểu kỹ thuật ngớ ngẩn nhất

    • Tất cả là vì doanh thu đăng ký
      Công ty có doanh thu đăng ký thì doanh thu cao hơn, định giá cao hơn, dễ gọi thêm vốn hơn, và đánh bại những công ty không theo mô hình này. Vì cấu trúc tự củng cố như vậy nên tôi cho rằng phần mềm ưu tiên cục bộ đã chết
    • Nhìn vào dung lượng lưu trữ miễn phí/trả phí của những nơi như Dropbox hay Apple là thấy chi phí thực tế. Đại khái khoảng 10 đô la/tháng cho 2TB
      Cloudflare gần như cho lưu trữ tệp tĩnh miễn phí, chi phí chỉ như sai số làm tròn. Dù 1000 ứng dụng ưu tiên cục bộ đồng bộ lên Dropbox, chúng vẫn có thể chạy với gói lưu trữ 10 đô la/tháng. Dung lượng lưu trữ này không phải là công cụ thô cấp thấp như S3, mà là dịch vụ tiêu dùng có cả xác thực, hỗ trợ và chương trình đồng bộ. Phần lớn chi phí đám mây thật ra là không cần thiết
    • Nếu bạn phản đối sáng kiến Stop Killing Games, bạn nên đọc bình luận này
      Không ai buộc trò chơi phải chỉ phụ thuộc vào dịch vụ trực tuyến. Đó không phải yêu cầu pháp lý hay yêu cầu quy định. Giống như nhiều thứ trong phần mềm, đó chỉ là một lựa chọn. Chọn phụ thuộc vào dịch vụ trực tuyến rồi sau đó nói “muốn đảo ngược việc này sẽ tốn tiền” là thiển cận, đáng chán, và không nên được chấp nhận

  • Nhiều ứng dụng hơn nên ưu tiên cục bộ. Nếu người dùng không muốn đồng bộ dữ liệu lên đám mây, họ phải có lựa chọn đó
    Tôi đã làm Brisqi, một ứng dụng ưu tiên offline hoặc ưu tiên cục bộ, được một thời gian; ngay từ đầu nó đã được thiết kế theo triết lý ưu tiên offline
    https://brisqi.com
    Ứng dụng ưu tiên cục bộ phải được thiết kế để hoạt động hoàn toàn offline vô thời hạn. Trải nghiệm cục bộ là nền tảng chứ không phải phương án thay thế, và đồng bộ đám mây nên là tính năng bổ trợ chứ không phải yêu cầu bắt buộc
    Tôi không xem các ứng dụng dựa vào cache tạm thời là ưu tiên offline. Ứng dụng thật sự ưu tiên offline phải lưu bền dữ liệu bằng cơ sở dữ liệu cục bộ. Nhiều ứng dụng tự gọi là “ưu tiên offline” thực ra chỉ cung cấp chức năng offline hạn chế và rốt cuộc vẫn phụ thuộc vào việc kết nối lại Internet; chúng giống cho phép offline hơn
    Ứng dụng ưu tiên offline rõ ràng khó xây dựng hơn ứng dụng web chỉ-online, và cơ chế đồng bộ phải đủ đáng tin cậy để dữ liệu vẫn được đồng bộ nhất quán lên đám mây, không bị mất trong quá trình chuyển đổi giữa offline/online. Tôi đã viết thêm về cách tiếp cận này trên blog: https://blog.brisqi.com/posts/how-i-designed-an-offline-first-app-an-outline

    • Tôi lo mô hình này có thể còn khó bền vững hơn về mặt kinh doanh, nên tò mò thực tế đang diễn ra thế nào

  • Việc giải thích nguyên tắc này theo hướng phù hợp với lĩnh vực tiêu dùng khá thú vị, nhưng hiện chúng tôi đang làm điều tương tự ở mảng tài sản công nghiệp/dữ liệu công nghiệp
    Tại www.sentineldevices.com, toàn bộ việc học, phân tích và ra quyết định đều diễn ra trên thiết bị của khách hàng. Thậm chí không có máy chủ để gửi dữ liệu lên; mô hình này nói rõ rằng mọi thứ chạy bên trong thiết bị
    Trong SCADA/tự động hóa công nghiệp có rất nhiều trường hợp sử dụng không thể đưa dữ liệu ra ngoài. Các công ty dữ liệu/AI bỏ qua một nhóm khách hàng và use case khổng lồ vì khó cung cấp dịch vụ tại nơi khách hàng đang ở, thay vào đó họ muốn kéo dữ liệu về phía mình và duy trì sự phụ thuộc vào nhà cung cấp
    Khi nói chuyện với khách hàng, chúng tôi lại phải nhấn mạnh rất mạnh rằng “không, cái này là cục bộ và không có kết nối ra ngoài”. Vì họ hầu như chưa từng nghe điều như vậy, nên nhiều khi phải giải thích từng bước thì họ mới hiểu mọi thứ diễn ra cục bộ; còn các nhà cung cấp phần mềm thì không dễ tiếp nhận khái niệm này. Tôi hy vọng phần mềm ưu tiên cục bộ sẽ phổ biến hơn trong lĩnh vực tiêu dùng để lĩnh vực công nghiệp cũng quen thuộc hơn với nó

    • Việc tất cả nhà cung cấp SCADA đều chạy theo trào lưu đám mây và thúc đẩy theo hướng đó cũng chẳng giúp ích gì
      “Hãy vận hành nhà máy bằng smartphone!” — giờ chỉ cần một lỗ hổng zero-day là script kiddie cũng có thể nghịch máy bơm của tôi
    • Đây là một lĩnh vực thú vị, và thật vui khi thấy bạn đang làm việc này
      Tôi thấy trên trang tuyển dụng mọi vị trí đều không làm từ xa; tôi tò mò đó là vì khi làm phần mềm ưu tiên cục bộ thì có giới hạn phải gặp trực tiếp, hay chủ yếu là lý do quản lý

  • Cá nhân tôi không đồng ý với cách tiếp cận này. Nó giống như một nỗ lực giải quyết vấn đề kinh doanh “không thể tin nhà cung cấp đám mây” bằng một thỏa hiệp kỹ thuật là “tránh kiến trúc tập trung”
    Việc thiếu quyền kiểm soát và thiếu độ tin cậy của phần mềm đóng đã được giải quyết bằng các mô hình kinh doanh mới như phát triển mã nguồn mở, giấy phép mới, và cách tạo doanh thu như hợp đồng bảo trì thay cho phí giấy phép
    Tương tự, vấn đề với các nhà cung cấp đám mây cũng cần giải pháp ở cấp mô hình kinh doanh. Ví dụ, có thể tạo một hợp đồng/giấy phép tiêu chuẩn định nghĩa các quyền để người dùng có thể tin tưởng mối quan hệ với nhà cung cấp đám mây. Theo thời gian, người dùng cũng có thể chỉ giao dịch với những nhà cung cấp có giấy phép như vậy
    Trong đó có thể bao gồm các điều khoản như thỏa thuận kết thúc vòng đời, bảo đảm khả năng di chuyển dữ liệu, và tính minh bạch về quyền riêng tư dữ liệu cho phép kiểm toán việc truy cập dữ liệu và cho biết ai/cái gì/đã đọc khi nào. Vấn đề là mức độ chấp nhận. Cốt lõi là vì sao nhà cung cấp đám mây phải chấp nhận; nếu họ sợ tỷ lệ rời bỏ, họ cũng có thể chỉ cung cấp các hợp đồng như vậy cho gói thuê bao hằng năm hoặc tính giá cao hơn

    • Nếu có thể giải quyết vấn đề kinh doanh hay chính trị bằng giải pháp kỹ thuật, đó thường là một cách tiếp cận mạnh. Vì những vấn đề đó do các tác nhân đối nghịch gây ra, còn giải pháp kỹ thuật loại bỏ khả năng phản bội của tác nhân đó
      Mã hóa khi dùng dịch vụ đám mây là một ví dụ tốt. Cố bảo vệ dữ liệu bằng chính sách quyền riêng tư và các quy tắc quan liêu gần như là công cốc. Dữ liệu có giá trị, khách hàng hay chính phủ khó biết công ty có đang âm thầm bán nó hay không, và cũng khó biết liệu họ có tiết kiệm chi phí bảo mật hay không cho đến khi đã quá muộn
      Nhưng nếu dữ liệu được mã hóa trên thiết bị client và có thể chứng minh bằng toán học rằng server không thể truy cập bản rõ, thì không cần lo những chuyện đó. Vấn đề là khi server không chỉ lưu trữ dữ liệu mà còn phải xử lý nó; khi đó giải pháp kỹ thuật trở thành dùng server của chính mình
    • Tôi nghi ngờ liệu những hợp đồng như vậy có thật sự giải quyết được vấn đề không. Dù một dịch vụ đám mây có ghi rõ rằng họ sẽ thông báo trước X tháng trước khi đóng cửa và cho phép xuất dữ liệu, thì sau khi dịch vụ thật sự kết thúc, thứ còn lại trong tay có thể chỉ là một tệp JSON khổng lồ gần như vô dụng
      Nếu không tự xây ứng dụng hoặc không có ai đó tốt bụng làm giúp, sẽ khó tận dụng được. Nó vẫn tốt hơn là không có gì, nhưng không tốt bằng một ứng dụng cục bộ có thể tiếp tục chạy nhiều năm hoặc nhiều thập kỷ sau khi công ty đóng cửa hay ngừng hỗ trợ
    • Mô hình này có thể biến nhà cung cấp đám mây thành thứ giống như ngân hàng. Nhà cung cấp đám mây giữ một dạng tài sản trong tài khoản người dùng, và người dùng có các quyền rõ ràng đối với tài sản đó cũng như năng lực pháp lý để thu hồi nó khỏi tài khoản
      Trong tài chính, thu hồi tương ứng với việc nhận lại tiền hoặc tài sản; còn trên đám mây, nó có thể là nhận một tệp Zip lớn chứa toàn bộ nội dung tài khoản
      Nhưng thứ được bàn giao không phải lúc nào cũng thực dụng hoặc đáng mong muốn. Trong tài chính, có thể chuyển tài khoản sang một đơn vị khác; và trong dịch vụ đám mây, trong nhiều trường hợp việc chuyển tài khoản có khả năng hữu ích hơn nhiều
      Điểm khó ở đây là tính di động. Ngay cả khi định nghĩa tốt quyền sở hữu và quyền của người dùng đối với tài khoản đám mây, việc được bàn giao bạn bè Facebook nghĩa là gì, hay chuyển tài khoản Facebook sang nơi khác nghĩa là gì, vẫn rất mơ hồ
    • Tôi cho rằng cách diễn giải đó không chính xác. Các tác giả hoàn toàn thừa nhận rằng bài toán kinh doanh của local-first chưa được giải quyết hoàn toàn và là một vấn đề liên quan mật thiết
      Vấn đề này cần cả giải pháp kinh doanh lẫn giải pháp kỹ thuật, và bài viết đề xuất các đặc tính mà giải pháp nên có
      Nói local-first chủ trương phi tập trung cũng không đúng. Martin Kleppmann đã nói rõ rằng ông không cho rằng công nghệ phi tập trung sẽ giải quyết vấn đề này theo cách có thể đi vào thị trường đại chúng. Ông ủng hộ một công cụ đồng bộ tiêu chuẩn tập trung giúp hiện thực hóa lý tưởng local-first
      Tham khảo bài trình bày tại Local-first conf năm ngoái: https://youtu.be/NMq0vncHJvU?si=ilsQqIAncq0sBW95
    • Bảo đảm khả năng di chuyển dữ liệu không thực tế đối với dữ liệu có quy mô nhất định. Việc di chuyển cơ sở dữ liệu production sang một cơ sở dữ liệu mới có thể mất từ vài tháng đến vài năm nếu muốn diễn ra suôn sẻ
      Trong tình huống khủng hoảng, có thể làm trong vài tuần, nhưng có thể trở nên rất lộn xộn. Ngay cả khi chuyển giữa các cơ sở dữ liệu mã nguồn mở cùng phiên bản, mỗi dịch vụ đám mây cũng có nhiều khác biệt nên tình hình cũng tương tự
      Giải pháp tốt nhất là ngay từ đầu đặt dữ liệu trong môi trường của chính mình và ngắt kết nối khi cần. Kết hợp quản lý BYOC với mã nguồn mở có thể làm được điều đó. Công ty chúng tôi cũng vận hành sản phẩm dữ liệu BYOC nên có lợi ích kinh tế trong cách tiếp cận này, nhưng vì đã thấy nó thực sự hoạt động nên tôi biết là có thể

  • Với các dự án của tôi là https://github.com/ibizaman/selfhostblocks và https://github.com/ibizaman/skarabox, tôi đang cố làm cho chính điều đó trở nên khả thi rộng rãi
    Mục tiêu chung là khiến self-hosting dễ tiếp cận hơn với đại chúng
    Dựa trên NixOS, tôi muốn cung cấp sẵn ở mức khai báo tối đa các thứ như https, SSO, LDAP, sao lưu, ZFS có snapshot, v.v.
    Vì có thể đóng gói Vaultwarden và Nextcloud để lưu trữ phần lớn dữ liệu, nó là đối thủ của cloud hosting, đồng thời cũng cung cấp các dịch vụ như Home Assistant
    Nó cũng là đối thủ của YUNoHost, nhưng tốt hơn, hoặc đang hướng tới tốt hơn, ở chỗ bạn có thể tự self-host các gói mình muốn bằng những thành phần mà SelfHostBlocks cung cấp. Nó gần với một thư viện hơn là một framework
    Nó cũng cạnh tranh với NAS, nhưng tôi cho rằng tốt hơn vì mọi thứ đều là mã nguồn mở. Hiện người dùng vẫn cần có kỹ thuật, nhưng tôi đang loại bỏ rào cản đó, và một trong các mục tiêu là giúp họ cài đặt được trên phần cứng của mình mà không cần biết Nix hay đụng tới dòng lệnh

    • Thật sự rất hay. Dạo này tôi nghĩ nhiều về chuyện này. Thật lạ là có nhiều phương án thay thế mã nguồn mở tự do xuất sắc như vậy, nhưng dù với dân kỹ thuật thì tương đối dễ kiểu “docker compose up”, với người không rành kỹ thuật thì vẫn khó tiếp cận
      Khá nhiều ứng dụng có thể self-host là ứng dụng web có cơ sở dữ liệu, máy chủ và frontend, nhưng trong nhiều trường hợp sử dụng, người ta chỉ dùng trên một máy tính và không cần bản hosted hay đồng bộ với thiết bị khác. Ví dụ, kế toán cá nhân chỉ cần làm trên máy tính mỗi tháng một lần, nên không cần chạy một web app 24/7 ở đâu đó. Chỉ cần mở chương trình, làm việc rồi tắt đi
      Có một sự lệch pha lớn giữa số lượng các phương án thay thế mã nguồn mở tự do chất lượng cao có thể self-host và số người thực sự có thể dùng chúng. Cần thêm các dự án thu hẹp khoảng cách đó. Tôi định thử dùng selfhostblocks cho vài thứ và đóng góp
    • Tôi thích việc có cả hledger. Với người chưa quen kế toán dạng văn bản thuần thì có thể hơi lạ, nhưng đây thật sự là phần mềm tuyệt vời

  • Không có lý do gì để mọi ứng dụng đều phải có nền tảng đồng bộ riêng. Cách đóng khung này có vẻ xuất phát từ ứng dụng di động, nơi thiếu khả năng kết hợp hay tính mô-đun giữa các chương trình
    Nếu nghiêm túc với “local-first” thì cứ dùng hệ thống tệp, và người dùng có thể chọn trong nhiều giải pháp như git, Box, v.v.
    Việc yêu cầu đăng ký dịch vụ đồng bộ riêng cũng khó chịu như các SaaS khác, thậm chí còn mù mờ hơn và dễ hỏng hơn

    • Tôi đồng ý rằng không phải mọi ứng dụng đều cần engine đồng bộ riêng, nhưng không đồng ý với cách đóng khung rằng hệ thống tệp là cách phổ quát để chấp nhận local-first
      Thứ nhất, tôi muốn local-first nhưng cũng muốn tính đồng thời. Nếu chỉ đơn giản là local-first thì đồng bộ kiểu nào cũng ổn, nhưng tôi muốn hơn thế. Tôi muốn nó chạy mượt như Dropbox mà không cần bận tâm, và muốn ở những vùng không có liên lạc, tôi và vợ vẫn có thể chỉnh sửa riêng trên điện thoại của mỗi người
      Thứ hai, đồng bộ hoạt động tốt hơn nhiều khi hiểu sâu cấu trúc dữ liệu và ý nghĩa của dữ liệu. git và Box đều có những giới hạn đáng kể, và nếu có yêu cầu về tính đồng thời thì các giới hạn đó còn lớn hơn
    • Nhìn chung tôi đồng ý, nhưng thực tế không phải lúc nào cũng đơn giản như vậy. Tôi đã làm một ứng dụng hoạt động đúng kiểu đó, nhưng vì không thể điều phối khi nào client nào được phép chỉnh sửa tệp, cuối cùng xung đột tệp là không thể tránh khỏi

  • Về lý thuyết, tôi thích cách phát triển theo hướng local-first. Nó rất hợp với triết lý small tech, vốn xem quyền riêng tư và quyền sở hữu dữ liệu là mặc định
    Nhưng thực tế thì khó. Về cơ bản phải xây dựng một engine đồng bộ, xử lý giải quyết xung đột và quản lý migration schema
    Dù vậy, có vẻ trong vài năm qua các công cụ phát triển phần mềm local-first đã tốt hơn. Tôi đang theo dõi jazz.tools, electric-sql, Zero của Rocicorp, và tò mò không biết còn công cụ nào khác không

    • CouchDB ở phía server và PouchDB ở phía client từng là một nỗ lực nhằm tạo ra môi trường như vậy
      https://couchdb.apache.org/
      https://pouchdb.com/
      Có thể xem thêm những suy nghĩ về phát triển ứng dụng local-first từ khoảng 10 năm trước tại đây: https://unhosted.org/
    • Khoảng một tháng qua tôi đã dùng instantdb khá nghiêm túc cho một side project ứng dụng ngân sách cá nhân
      Lẽ ra tôi nên viết một bài blog, nhưng trước đó tôi đã tìm hiểu PowerSync, electricSQL, LiveStore, PowerSync, và cũng xem qua jazz.tools một chút, nhưng muốn thứ gì đó có cấu trúc hơn
      Cho đến giờ khá ấn tượng. Tôi đang viết bằng Vue và một thư viện cộng đồng; phần phân quyền hơi khó nhằn, nhưng khi hiểu rồi thì đơn giản. Tôi cũng thích đăng nhập bằng magic email, dashboard/chức năng phản hồi cũng tốt, nhưng để bớt rườm rà hơn có vẻ cần vài thay đổi lớn
      Tôi thích việc nó là mã nguồn mở và có thể tự host nếu muốn. jazz thiếu cấu trúc, LiveStore tuy hấp dẫn nhưng event store trông quá phiền phức. Việc công cụ phát triển nằm sau paywall thì hơi tiếc, nhưng cũng hiểu được. electricSQL chỉ cung cấp một nửa lời giải, tức là chỉ đọc, còn thiếu mô hình ghi. CouchDB/PouchDB với tôi cũng thiếu cấu trúc, và tôi muốn hỗ trợ giữa các tài liệu được tích hợp sẵn rõ ràng hơn. Zero thì tôi chưa tìm hiểu kỹ
    • Không biết bạn có biết site này không: https://www.localfirst.fm
      Thật ra tôi định chỉ vào liên kết “landscape” ở menu trên cùng, nhưng URL khá bất tiện
    • Gần đây tôi thấy ai đó nhắc đến Automerge
      https://automerge.org/
      Có implementation bằng Rust và JavaScript, đồng thời cung cấp vài chiến lược mạng. Nó không đi kèm cấu trúc sản phẩm miễn phí/trả phí như jazz.tools, nhưng khá ổn
    • Ditto cũng đáng xem
      https://www.ditto.com
      Đây là một nền tảng local-first hỗ trợ đồng bộ thời gian thực với CRDT làm lõi, nên việc quản lý giải quyết xung đột dễ hơn nhiều. Nó được thiết kế để xử lý sẵn các trường hợp offline-first và đồng bộ peer-to-peer, nên không cần tự xây engine đồng bộ từ đầu
      Hỗ trợ nhiều nền tảng như Swift, Kotlin(Android), Flutter/Dart, React Native, JavaScript(Web/Node), .NET(C#), C++, Java, Rust, v.v. Có thể xem thêm tài liệu tại đây: https://docs.ditto.live/home/about-ditto