- Phần mềm local-first là một cách tiếp cận nhằm đồng thời hiện thực hóa lợi ích của cộng tác dựa trên đám mây và quyền sở hữu dữ liệu cá nhân
- Các ứng dụng đám mây hiện nay vượt trội về cộng tác thời gian thực và khả năng truy cập, nhưng cũng gây ra các vấn đề như quyền sở hữu dữ liệu và khả năng truy cập dài hạn
- Phần mềm local-first coi lưu trữ cục bộ là nơi lưu dữ liệu mặc định, và cung cấp thêm các tính năng đồng bộ hóa và cộng tác
- Loại phần mềm này mang lại lợi ích về tốc độ, hỗ trợ ngoại tuyến, quyền riêng tư và khả năng kiểm soát của người dùng, nhưng cũng tồn tại độ khó triển khai ở các khía cạnh như cộng tác thời gian thực hay đồng bộ đa thiết bị
- Để hiện thực hóa phần mềm local-first, nhiều mô hình công nghệ hiện có đang được so sánh và phân tích, đồng thời cũng đang tìm kiếm khả năng phát triển các mô hình lý tưởng hơn trong tương lai
Giới hạn của ứng dụng đám mây và quyền sở hữu dữ liệu
- Phần lớn người dùng sử dụng nhiều ứng dụng đám mây như Google Docs, Figma, Slack cho các mục đích như soạn thảo tài liệu, thiết kế và cộng tác
- Các dịch vụ này được truy cập qua trình duyệt hoặc ứng dụng di động, và phần lớn lưu dữ liệu trên máy chủ
- Phần mềm dựa trên đám mây có ưu điểm là hỗ trợ cộng tác và cho phép truy cập dữ liệu từ mọi nơi, nhưng dữ liệu bên trong càng trở nên có giá trị khi người dùng đầu tư nhiều thời gian hơn vào ứng dụng
- Thông qua phỏng vấn với các chuyên gia, có thể thấy rằng đằng sau lợi ích chức năng của ứng dụng đám mây là những nhược điểm nghiêm trọng như mất quyền sở hữu, sự bất định về khả năng truy cập dài hạn
- Việc quyền bảo tồn và sở hữu tài liệu cũng như dữ liệu do chính người dùng tạo ra hoặc sản xuất bị hạn chế tạo nên cả cảm giác bất an về tâm lý lẫn rủi ro thực tế
Ý nghĩa của việc thực sự sở hữu dữ liệu
- Dữ liệu được lưu trên đám mây có vẻ như là "của mình", nhưng trên thực tế quyền quản lý và kiểm soát truy cập lại nằm trong tay nhà cung cấp dịch vụ đám mây
- Khi dịch vụ bị ngừng cung cấp hoặc máy chủ gặp sự cố, có thể xảy ra mất khả năng truy cập dữ liệu và khó khăn trong việc lưu giữ dữ liệu lâu dài
- Vấn đề cốt lõi không phải là quyền sở hữu trí tuệ theo nghĩa pháp lý, mà là cảm giác sở hữu và khả năng kiểm soát dữ liệu mà người dùng cảm nhận được
- Các ứng dụng cũ lấy lưu trữ cục bộ làm trung tâm (trình soạn thảo văn bản, quản lý phiên bản, các công cụ khác nhau) đảm bảo quyền sở hữu dữ liệu trọn vẹn và tính tự chủ
So sánh ưu và nhược điểm của đám mây và cục bộ
- "Ứng dụng đám mây = cộng tác·khả năng truy cập", "ứng dụng cục bộ = quyền sở hữu·tự chủ"
- Thay vì buộc phải chọn một trong hai, cần theo đuổi sự kết hợp tốt nhất theo hướng lai ghép
- Quyền sở hữu dữ liệu và khả năng cộng tác thời gian thực không nhất thiết xung đột với nhau, và có thể thiết kế một mô hình phần mềm đạt được cả hai
- Mô hình này được định nghĩa là phần mềm local-first, với cấu trúc cơ bản là sự kết hợp giữa lưu trữ cục bộ, mạng và máy chủ phụ trợ
7 lý tưởng của phần mềm local-first
- Trong ứng dụng đám mây, máy chủ đóng vai trò là “bản chính” của dữ liệu nên mọi yêu cầu đều cần một vòng khứ hồi tới máy chủ, từ đó phát sinh độ trễ trong trải nghiệm người dùng
- Ngược lại, phần mềm local-first xem bản sao trong lưu trữ cục bộ là phiên bản cơ sở của dữ liệu, còn việc đồng bộ hóa (thông qua máy chủ) chỉ là thứ yếu
- Sự thay đổi góc nhìn này mang lại lợi ích thực tế về tốc độ phản hồi, hỗ trợ ngoại tuyến và quyền kiểm soát dữ liệu
1. Tốc độ (phản hồi nhanh)
- Ứng dụng local-first xử lý mọi thao tác trên hệ thống tệp cục bộ, nên có thể đạt được khả năng phản hồi tức thì mà không phải chờ độ trễ từ yêu cầu máy chủ
- Việc đồng bộ được xử lý âm thầm trong nền, nên trải nghiệm người dùng không bị gián đoạn ở bất kỳ thời điểm nào
2. Đồng bộ đa thiết bị
- Người dùng hiện đại làm việc trên nhiều thiết bị, vì vậy ứng dụng local-first cũng cần đồng bộ dữ liệu giữa các thiết bị
- Đồng bộ ở cấp độ tệp thuận tiện khi chỉ có một người dùng, nhưng khi nhiều người cùng chỉnh sửa đồng thời sẽ phát sinh vấn đề xung đột (Conflict)
3. Ưu tiên ngoại tuyến
- Phần mềm local-first cho phép tạo và chỉnh sửa dữ liệu bất kỳ lúc nào trong trạng thái ngoại tuyến, rồi tự động đồng bộ khi mạng được khôi phục sau đó
- Có thể chia sẻ và đồng bộ dữ liệu giữa các thiết bị bằng nhiều cách như Bluetooth, WiFi cục bộ
- Để hỗ trợ ngoại tuyến thực sự, dạng tệp thực thi cài đặt cục bộ được ưu tiên hơn
4. Cộng tác và quản lý xung đột
- Các cách làm truyền thống (tệp đính kèm email, công cụ quản lý phiên bản, v.v.) gây ra sự bất tiện về xung đột và hợp nhất thủ công khi nhiều người cùng làm việc trên một tệp
- Các ứng dụng đám mây (Google Docs, v.v.) giảm thiểu độ khó và mâu thuẫn trong cộng tác bằng tính năng chỉnh sửa đồng thời theo thời gian thực
- Phần mềm local-first cũng có tiềm năng triển khai nhiều luồng cộng tác như cộng tác thời gian thực, đề xuất thay đổi và phê duyệt, và đây là một lĩnh vực thách thức về mặt kỹ thuật
5. Bảo tồn dữ liệu dài hạn
- Khi sử dụng ứng dụng local-first, quyền truy cập dữ liệu vẫn được đảm bảo ngay cả khi công ty làm phần mềm không còn tồn tại
- Các định dạng tệp phổ biến (văn bản, PDF, JPEG, v.v.) có thể duy trì khả năng tương thích lâu dài, và ngay cả với định dạng không còn tương thích vẫn có thể truy cập bằng máy ảo hoặc trình giả lập
- Nếu không có sự bảo tồn dữ liệu thực sự trong dài hạn, vấn đề thời kỳ đen tối số (con người tương lai không thể truy cập hay diễn giải dữ liệu ngày nay) có thể trở thành hiện thực
6. Quyền riêng tư và bảo mật
- Cấu trúc tập trung quanh đám mây dễ bị tổn thương trước nhiều sự cố bảo mật như bị tấn công, bị nhân viên nội bộ lạm dụng
- Các chuyên gia xử lý thông tin cá nhân hoặc dữ liệu nhạy cảm có thể đạt được bảo mật và tính độc lập dữ liệu trong mô hình local-first thông qua mã hóa đầu cuối
- Các tập đoàn lớn như Google có thể sử dụng dữ liệu nội bộ theo nhiều cách khác nhau, trong khi phần mềm local-first trao quyền kiểm soát cho chính chủ thể dữ liệu
7. Quyền sở hữu và quyền kiểm soát của người dùng
- Việc truy cập dữ liệu có thể bị chặn hoặc hạn chế một cách tùy ý bởi nhà cung cấp dịch vụ đám mây (gắn cờ tự động sai, thay đổi chính sách, v.v.)
- Trong môi trường local-first, mọi quyền như sử dụng, chỉnh sửa, sao lưu và lưu giữ dữ liệu đều do chính người dùng quyết định
- Đây không đơn thuần là vấn đề bản quyền theo pháp lý, mà là vấn đề về tính tự chủ thực chất và quyền kiểm soát dữ liệu của người dùng
So sánh các mô hình phần mềm khác nhau
- Tệp cục bộ + tệp đính kèm email: vượt trội về tốc độ, ngoại tuyến, bảo tồn dài hạn, quyền kiểm soát, nhưng bất tiện về cộng tác, đồng bộ thiết bị
- Ứng dụng web đám mây (Google Docs, Trello, v.v.): vượt trội về cộng tác thời gian thực, khả năng truy cập, nhưng yếu về tốc độ, ngoại tuyến, quyền sở hữu, quyền riêng tư
- Dịch vụ đồng bộ tệp (Dropbox, v.v.): vượt trội về tốc độ, ngoại tuyến, bảo tồn dài hạn, quyền kiểm soát, nhưng có giới hạn về cộng tác và môi trường di động
- Hệ thống quản lý phiên bản (Git, v.v.): rất mạnh về tốc độ, ngoại tuyến, bảo tồn dài hạn, quyền kiểm soát, nhưng yếu với tệp không phải văn bản và cộng tác thời gian thực
- Client di động (Firebase, CloudKit, v.v.): mạnh về đồng bộ, ngoại tuyến, nhưng có giới hạn về dữ liệu cá nhân, quyền riêng tư và tính liên tục dài hạn của dịch vụ
- Phương thức sao chép multi-master (DB, ví dụ: CouchDB): mạnh về ngoại tuyến và đồng bộ, nhưng khó hoặc chưa đủ tốt để hiện thực hóa các lý tưởng như cộng tác, quyền riêng tư và quyền kiểm soát
Góc nhìn của nhà phát triển phần mềm và định hướng tương lai
- Phần mềm local-first lý tưởng cần được thiết kế/triển khai ngay từ đầu với các yếu tố ngoại tuyến, đồng bộ đa thiết bị, cộng tác thời gian thực, quyền riêng tư, kiểm soát của người dùng
- Tuy nhiên trong thực tế, vẫn chưa có công nghệ công khai nào có thể đồng thời đáp ứng mọi lý tưởng đó
- Các công nghệ mới được thiết kế trong nghiên cứu khoa học máy tính hiện đại (ví dụ: Conflict-free Replicated Data Types(CRDTs), phương thức đồng bộ dữ liệu phân tán, v.v.) có thể trở thành nền tảng cốt lõi để hiện thực hóa phần mềm local-first trong tương lai
Kết luận
- Phần mềm local-first là một định hướng quan trọng có thể hiện thực hóa sự cân bằng giữa khả năng cộng tác, tính độc lập, quyền riêng tư và chủ quyền dữ liệu trong kỷ nguyên số
- Nó mang lại cho chuyên gia, nhà sáng tạo và những người khác cảm giác sở hữu đối với dữ liệu cùng sự bảo vệ dài hạn, đồng thời được kỳ vọng tạo ra thay đổi tích cực trên toàn bộ các ngành
- Trong tương lai, cần tiếp tục nghiên cứu và thử nghiệm về hạ tầng, công cụ phát triển, kiến trúc và thuật toán tốt hơn để hiện thực hóa lý tưởng này
1 bình luận
Ý kiến trên Hacker News
Cảm thấy đồng cảm cực mạnh. Tôi cũng đang phát triển để giải quyết đúng kiểu vấn đề này, và đã chán ngấy cách phải đưa thông tin của mình lên cloud rồi chỉ để tiếp tục trả phí thuê bao. Hiện tôi đang làm một ứng dụng fitness tracking và dự định áp dụng mô hình của Sublime. Mua một lần lúc đầu, được cập nhật trong vài năm, đồng bộ trên mọi thiết bị, dùng trọn đời. Sau đó nếu muốn cập nhật tiếp thì chỉ cần mua lại phiên bản mới là đủ. Mục tiêu là chất lượng phải đủ tốt để người dùng có thể cứ thế dùng mãi. Tôi muốn 90% phần mềm đi theo mô hình này. Phải có thể mua với mức giá hợp lý, bản thân sản phẩm phải tốt, và quan trọng là phải hoạt động tử tế ngay cả khi không có tích hợp cloud. Không chỉ vì quyền riêng tư dữ liệu, mô hình này còn có rất nhiều ưu điểm khác. Dù vẫn còn các bài toán như tooling, nền tảng kỹ thuật thì đã đủ chín muồi. Ưu điểm lớn nhất của local-first software là cấu trúc khuyến khích lành mạnh. Nó không thưởng cho quảng cáo, theo dõi người dùng hay tối đa hóa “engagement”, mà thưởng cho chính sản phẩm. Nó thực sự cho cảm giác là phần mềm đặt người dùng làm trung tâm.
Mô hình của ứng dụng ghi chú Obsidian cũng là một hình mẫu rất tốt. Client miễn phí, còn dịch vụ đồng bộ thì bán như một lựa chọn thêm. Điểm mạnh là ghi chú là file Markdown nên thực ra cũng không nhất thiết phải cần client.
Tôi tò mò không biết bạn định xử lý đồng bộ thế nào mà không dùng hạ tầng cloud.
Hoàn toàn đồng ý. Nếu tiện thì tôi cũng rất muốn biết tech stack của ứng dụng fitness tracking đó. Đặc biệt là cách bạn xử lý đồng bộ đa thiết bị.
Cũng có nhiều ứng dụng thuần local vẫn kiếm tiền bằng quảng cáo, nên chuyện “không gắn quảng cáo” không phải lúc nào cũng đúng.
Hiện tại ở Berlin đang có hội nghị Local-first Software (https://www.localfirstconf.com/) do Ink and Switch tổ chức rất sôi nổi, và năm nay thậm chí còn có thêm Sync Conf (https://syncconf.dev/) ở San Francisco vào tháng 11. Ở các hội nghị gần đây, chính các đồng tác giả của bài báo cũng đã trực tiếp tham gia panel thảo luận, rất hữu ích vì họ chia sẻ những điều học được trong bối cảnh công cụ phát triển cho local-first software. Rất khuyến nghị video panel thảo luận. Trong cộng đồng hiện nay, “Sync” đang dần được xem là yếu tố cốt lõi của local-first, và xu hướng là các dev tool như sync engine chỉ là công cụ hỗ trợ hiện thực hóa các đặc tính local-first, chứ bản thân chúng không phải là local-first. Tổng hợp toàn bộ các bài nói chuyện vài năm gần đây cũng đã được đăng ở đây. Việc phát triển công cụ hỗ trợ cộng tác realtime và bất đồng bộ đang diễn ra rất mạnh, và với sự xuất hiện gần đây của AI, thị trường ngày càng cần các sync engine dạng này hơn. Ứng dụng AI về bản chất là môi trường cộng tác nhiều người dùng, nên đây là thời điểm cần đến nền tảng kỹ thuật từ cộng đồng sync engine.
Về chủ đề này trước đây cũng đã có rất nhiều thảo luận sôi nổi, nên nếu quan tâm thì rất đáng đọc: 2019-05, 191 bình luận
2019-11, 241 bình luận
2020-07, 9 bình luận
2020-08, 134 bình luận
2021-02, 90 bình luận
2022-06, 30 bình luận
2023-10, 50 bình luận
Tôi cho rằng không nhất thiết mọi ứng dụng đều phải có nền tảng sync riêng. Xu hướng này có vẻ bắt nguồn từ việc trên mobile app rất khó ghép nối và mô-đun hóa giữa các chương trình. Nếu thật sự muốn local-first thì chỉ cần dùng file system là được. Từ góc nhìn người dùng, họ có thể tự chọn nhiều giải pháp sẵn có như git, box v.v. Bản thân quy trình đăng ký sync cho từng ứng dụng cũng mù mờ và dễ hỏng chẳng kém gì SaaS, nên khá nặng nề.
Tôi đồng ý rằng không phải ứng dụng nào cũng cần sync engine, nhưng tôi không nghĩ file system là lời giải vạn năng cho local-first. Có hai lý do. Thứ nhất là concurrency. Nếu chỉ local-first thuần túy thì có thể dùng sync kiểu nào cũng được, nhưng tôi muốn nhiều hơn thế. Ví dụ tôi muốn trải nghiệm mà vợ tôi và tôi có thể chỉnh sửa độc lập trên điện thoại của mình ngay cả khi mất liên lạc, rồi mọi thứ tự động hợp nhất ổn thỏa. Kiểu đồng bộ thật tự nhiên như DropBox. Thứ hai là để mang lại trải nghiệm sync tốt hơn, sync engine phải hiểu rất sâu cấu trúc và ngữ nghĩa của dữ liệu. git hay box có nhiều giới hạn trước nhu cầu đồng biên tập mang tính ngữ nghĩa như vậy.
Tôi đã thử triển khai theo cách chỉ dùng file system, nhưng rất khó điều phối giữa các client xem khi nào được phép chỉnh sửa file, nên cuối cùng vấn đề xung đột file là không tránh khỏi.
Các hệ thống phụ thuộc online thì tất yếu kéo theo chi phí bảo trì và vận hành. Nếu không phải thiết kế local-first hoặc local-only thì không thể là hệ thống đáng tin cậy lâu dài. Các loại đồ gia dụng kết nối mạng và ô tô kết nối mạng xét về tính thực dụng là những ví dụ kỹ thuật thật sự ngớ ngẩn.
Ngược lại, tôi khá hoài nghi với góc nhìn muốn giải quyết vấn đề độ tin cậy của cloud hoàn toàn bằng kỹ thuật, chẳng hạn tránh kiến trúc tập trung. Trước đây, những vấn đề như phần mềm đóng khó kiểm soát và khó tin cậy từng được giải quyết bằng mô hình kinh doanh như phát triển mã nguồn mở, hợp đồng bảo trì v.v. Tôi cho rằng vấn đề cloud cũng cần những lời giải ở cấp mô hình kinh doanh như vậy. Ví dụ có thể tạo hợp đồng hay giấy phép tiêu chuẩn để ghi rõ quyền của người dùng, rồi định hướng thị trường chỉ chọn các vendor thực thi loại giấy phép được chứng nhận đó. Có thể thêm rất nhiều điều khoản như bảo đảm quyền di chuyển dữ liệu của người dùng, công khai minh bạch lịch sử sử dụng dữ liệu, quy trình xử lý khi dịch vụ ngừng hoạt động, v.v. Tất nhiên trở ngại lớn nhất là tại sao các vendor lại chấp nhận điều này. Vì sợ khách hàng rời đi, các vendor có thể chỉ cho phép thuê bao năm nếu cung cấp loại giấy phép đó, hoặc đòi thêm phí.
Khi có thể tiếp cận một vấn đề kinh doanh/chính trị bằng lời giải kỹ thuật, tôi nghĩ đó lại là phương pháp chắc chắn hơn. Vì có thể chặn hẳn xung đột lợi ích đối kháng bằng công nghệ. Ví dụ điển hình là mã hóa phía client (client-side encryption). Dựa vào chính sách quyền riêng tư hay quy định quan liêu thì cám dỗ quá lớn, còn việc giám sát và phát hiện lại khó. Nếu dữ liệu được mã hóa sao cho về mặt toán học máy chủ không thể đọc được thì nỗi lo đó biến mất. Dù vậy, nếu phía máy chủ thực sự phải xử lý dữ liệu thì sẽ rơi vào tình huống thực tế là bạn phải dùng máy chủ của chính mình.
Ví dụ, kể cả có giải quyết bằng hợp đồng khi chấm dứt dịch vụ đi nữa, nếu nhà cung cấp cloud phá sản, thông báo rồi chỉ cho xuất dữ liệu ra, cuối cùng thứ còn lại cũng chỉ là một file JSON khổng lồ. Nếu bạn không tự làm ứng dụng hoặc không có ai khác làm giúp thì thực tế nó chẳng hữu ích mấy. Ý định thì tốt, nhưng vẫn kém hơn ứng dụng local ở chỗ ứng dụng local cho phép dữ liệu của một ứng dụng đã hết vòng đời tiếp tục được dùng lâu dài.
Điều khoản bảo đảm di chuyển dữ liệu cũng vậy, việc chuyển lượng dữ liệu lớn trong thực tế rất khó và tốn thời gian. Làm gấp trong tình huống khủng hoảng thì còn tệ hơn. Ngay cả giữa các open source DB cùng phiên bản, do mỗi dịch vụ có nhiều biến số nên cũng không hề dễ. Cuối cùng, phương án thực tế là ngay từ đầu giữ dữ liệu trong môi trường của chính mình và khi cần thì có thể “rút phích cắm”. Có khả năng kết hợp BYOC (bring your own cloud) với mã nguồn mở. Công ty chúng tôi cũng đang vận hành sản phẩm dữ liệu BYOC nên đã trực tiếp trải nghiệm rằng cấu trúc này là khả thi.
Dù có ghi trách nhiệm trong hợp đồng khi dịch vụ cloud ngừng hoạt động, đến lúc thực sự quyết định đóng cửa thì cũng khó hình dung rõ cách thực thi và giám sát trong thực tế.
Không chỉ là vấn đề kinh doanh/chính trị, mà bản thân an toàn dữ liệu cũng là vấn đề. Lý do chính tôi tránh mô hình thuê bao hay cloud là vì muốn bảo vệ dữ liệu của mình. Dữ liệu được truyền đi mà không có mã hóa cục bộ thì thật sự lúc nào cũng có thể bị lộ.
Đọc bài này tôi thấy khá mới mẻ. Tôi nghĩ cần có nhiều ứng dụng local-first hơn. Nếu người dùng không muốn đồng bộ cloud thì nhất định phải có lựa chọn đó. Brisqi của tôi (https://brisqi.com) cũng là một ứng dụng dựa trên triết lý offline-first như vậy. Về cơ bản, ứng dụng local-first nghĩa là phải hoạt động hoàn hảo vô thời hạn ngay cả khi offline. Trải nghiệm offline là mặc định, còn cloud sync chỉ là một cải tiến bổ sung. Những ứng dụng dựa trên cache tạm thời thì không thể gọi là offline-first. Dữ liệu phải được lưu trong local DB; offline-first đúng nghĩa là dữ liệu được bảo toàn bất kể internet ra sao. Phần lớn các ứng dụng tự nhận là “offline-first” thực ra chỉ là offline-tolerant (hỗ trợ offline hạn chế). Xây dựng ứng dụng offline-first khó hơn rất nhiều so với web app chỉ chạy online. Cần có cơ chế đồng bộ thật chắc chắn để không mất dữ liệu ngay cả khi chuyển qua lại giữa offline và online. Cách tôi triển khai có thể xem trong blog (https://blog.brisqi.com/posts/how-i-designed-an-offline-firs...).
Ngay cả khi các nguyên tắc này tập trung vào người tiêu dùng thì vẫn có ý nghĩa. Hiện tại chúng tôi ở Sentinel Devices (www.sentineldevices.com) đang phát triển một cấu trúc cho các hiện trường công nghiệp như SCADA/tự động hóa công nghiệp, nơi dữ liệu tuyệt đối không thể đưa ra bên ngoài: mọi việc từ chạy, phân tích đến ra quyết định đều diễn ra hoàn toàn local trên chính thiết bị của họ. Chúng tôi không cung cấp máy chủ bên ngoài nào cả. Kiểu cấu trúc tập trung vào nguyên tắc on-device này mang lại một trải nghiệm gần như “đập tan định kiến” cho cả khách hàng lẫn vendor. Nhiều công ty dữ liệu/AI thực tế bỏ qua thị trường này vì cho rằng quá khó để cung cấp dịch vụ tại hiện trường của khách hàng. Nhưng với chúng tôi, thường xuyên phải nhấn mạnh rằng đây là no connectivity, xử lý hoàn toàn local thì khách hàng mới hiểu. Nếu hiện tượng này trở nên quen thuộc hơn trong lĩnh vực tiêu dùng nhờ local-first, thì lĩnh vực công nghiệp cũng sẽ chuyển mình nhanh hơn.
Ngay cả ngành SCADA gần đây cũng đang đẩy tất cả lên cloud. Khẩu hiệu kiểu “Hãy quản lý nhà máy bằng smartphone”. Nhưng điều đó cũng đồng nghĩa rủi ro tăng lên khi giờ đây ngay cả hacker nghiệp dư cũng có cửa can thiệp vào điều khiển nhà máy.
Lĩnh vực này rất thú vị, chúc bạn thành công. Có một điều tôi tò mò là nhìn trang nghề nghiệp thì thấy chỉ tuyển onsite, không có remote. Không biết là vì phát triển local-first thực sự cần làm việc offline tại chỗ, hay chỉ là vấn đề quản lý.
Các dự án tôi đang làm (selfhostblocks, skarabox) cũng nhắm đến việc giúp ai cũng có thể self-hosting dễ dàng trên nền NixOS. Chúng cung cấp gần như mọi thứ theo kiểu khai báo như https, SSO, LDAP, backup, ZFS snapshot, v.v. Có thể lưu phần lớn dữ liệu qua Vaultwarden, Nextcloud, đồng thời bao gồm cả các dịch vụ như Home assistant. Nó ở thế cạnh tranh với YUNoHost nhưng với mục tiêu tốt hơn. SelfHostBlocks là tập hợp nhiều building block package để ai cũng có thể tự do mở rộng và self-host. Nó mang cách tiếp cận giống thư viện hơn là framework. Cũng là một lựa chọn thay thế NAS, và hoàn toàn mã nguồn mở. Với người có kiến thức kỹ thuật thì có thể dễ, nhưng mục tiêu là hạ rào cản để cả người bình thường cũng có thể cài lên phần cứng mà không cần biết nix hay CLI.
Tôi thật sự ủng hộ những dự án như thế này. Có rất nhiều lựa chọn FOSS tuyệt vời, nhưng trên thực tế chỉ kỹ thuật viên mới cài dễ được (kiểu mức “docker compose up”), còn với người bình thường thì vẫn là bức tường. Nhiều ứng dụng có thể self-host lại có cấu trúc web app + DB + server + frontend, trong khi trường hợp như tôi thì thực ra gần như chỉ dùng trên một thiết bị. Chỉ cần một chương trình desktop hoàn toàn local là đủ, nhưng trên thực tế với người không phải developer thì ngay cả thế cũng quá khó. Rõ ràng đang có một sự lệch pha giữa FOSS self-host chất lượng cao và người dùng thực sự. Cần nhiều dự án hơn để lấp khoảng trống này. Tôi cũng định dùng thử selfhostblocks, chúc dự án phát triển tốt.
Việc có kèm hledger thật sự rất tuyệt. Với người mới làm quen các kiểu kế toán plaintext thì có thể hơi lạ, nhưng đây là phần mềm cực kỳ xuất sắc.
Cảm giác thật sự biết ơn vì bạn đã làm nó gọn gàng đến vậy.
Tôi lướt qua bài gốc thì thấy hầu hết các điểm cốt lõi đều đã được chạm tới, nhưng động cơ ở đoạn đầu tiên có vẻ hơi yếu. Nó đọc lên giống kiểu “bánh táo vừa ngon vừa bổ dưỡng, nhưng một ngày nào đó có thể đột nhiên bốc cháy biến mất, cuốn theo cả cái yếm tôi quý mến” vậy.