Mengapa aplikasi local-first belum menjadi arus utama?

• Aplikasi local-first menjanjikan respons yang cepat dan jaminan privasi dasar, tetapi memiliki keterbatasan besar karena implementasi dukungan offline yang sesungguhnya sangat sulit
• Alasan terbesarnya adalah kompleksitas sinkronisasi; ketika data diubah secara bersamaan di beberapa perangkat, hasilnya pada akhirnya harus berkonvergensi ke status yang persis sama
• Ada dua tantangan teknis utama: ketidakpastian urutan waktu dan konflik
• Untuk menyelesaikan masalah ini, diperlukan penerapan desain sistem terdistribusi seperti Hybrid Logical Clocks(HLCs) dan CRDTs
• Dengan memanfaatkan ekstensi berbasis SQLite, dimungkinkan untuk menyediakan arsitektur sinkronisasi yang andal dan sederhana, dan ini dapat digunakan di semua platform

---

Janji dan realitas aplikasi offline-first

• Aplikasi offline-first mengusung respons instan, jaminan privasi dasar, dan dapat digunakan tanpa menunggu loading bahkan di lingkungan jaringan yang tidak stabil
• Dalam praktiknya, sebagian besar aplikasi gagal mengimplementasikan dukungan offline dengan benar; kebanyakan hanya mengadopsi metode menyimpan perubahan sementara secara lokal lalu mengirimkannya saat koneksi jaringan tersedia nanti
• Implementasi seperti ini kurang andal, dan pada akhirnya memunculkan pesan peringatan seperti "perubahan mungkin tidak tersimpan"

Kesulitan mendasar sinkronisasi

• Saat membuat aplikasi local-first, pada dasarnya Anda tak terhindarkan membangun sistem terdistribusi
• Beberapa perangkat dapat mengubah data secara independen saat offline, dan ketika terhubung kembali nantinya, semuanya harus berkonvergensi secara akurat ke status yang sama
• Untuk itu ada dua tantangan besar
  • Ketidakpastian urutan peristiwa
  • Konflik pada data yang sama

1. Ketidakpastian urutan peristiwa

• Peristiwa terjadi di beberapa perangkat pada waktu yang berbeda, dan status dapat berubah tergantung urutannya
  • Contoh: perangkat A menetapkan x=3, perangkat B menetapkan x=5 → setelah masing-masing berubah saat offline lalu disinkronkan, bisa muncul hasil yang berbeda
• Database terpusat tradisional mengatasinya dengan konsistensi kuat, tetapi ini membutuhkan sinkronisasi global sehingga tidak cocok untuk sistem local-first
• Pada akhirnya, urutan yang tepat untuk tiap peristiwa harus ditentukan bahkan dalam lingkungan dinamis dan terdistribusi, sehingga dibutuhkan cara menentukan urutan tanpa jam pusat

Penerapan Hybrid Logical Clocks(HLCs)

• Hybrid Logical Clocks(HLCs) adalah algoritme sederhana namun efektif yang memungkinkan urutan peristiwa antarperangkat disepakati secara praktis
• HLC menggunakan gabungan informasi waktu fisik dan penghitung logis
• Sebagai contoh:
  • Perangkat A mencatat peristiwa pada pukul 10:00:00.100, HLC menjadi (10:00:00.100, 0)
  • Perangkat B yang menerima pesan, meskipun jamnya lebih lambat, menaikkan HLC menjadi (10:00:00.100, 1)
  • Dengan demikian, urutan peristiwa dapat ditentukan secara akurat terlepas dari perbedaan jam fisik kedua perangkat

2. Masalah konflik

• Menerapkan urutan yang benar saja tidak cukup; jika data yang sama dimodifikasi secara independen di perangkat berbeda, konflik pasti akan terjadi
• Sebagian besar sistem mengharuskan developer menulis kode penyelesaian konflik secara manual, tetapi ini menimbulkan risiko kesalahan dan beban pemeliharaan

Pemanfaatan CRDTs

• Menerapkan Conflict-Free Replicated Data Types(CRDTs) adalah pendekatan terbaik
• CRDTs menjamin bahwa apa pun urutan sinkronisasinya, atau meskipun diterapkan berulang, status tiap perangkat pada akhirnya akan selalu sama
• Strategi CRDT paling sederhana adalah Last-Write-Wins(LWW)
  • Memberi stempel waktu pada setiap pembaruan
  • Saat sinkronisasi, nilai dengan stempel waktu yang lebih baru dipilih

Keunggulan SQLite

• Saat membangun aplikasi local-first, DB lokal yang ringan dan andal sangat penting, dan SQLite adalah pilihan terbaik
• Jika fungsi sinkronisasi diimplementasikan lewat ekstensi framework berbasis SQLite, ada manfaat seperti berikut
  • Penerapan pesan sederhana: ambil nilai saat ini → jika stempel waktu baru lebih mutakhir maka timpa → jika tidak, abaikan
  • Pendekatan ini menjamin konvergensi status di semua perangkat tanpa bergantung pada urutan sinkronisasi

Makna arsitektur ini

• Struktur ini mewujudkan sinkronisasi yang sederhana dan andal
  • Tetap andal tanpa kehilangan data bahkan saat offline selama berminggu-minggu
  • Sifat deterministik yang selalu berkonvergensi ke status akhir
  • Dapat diselesaikan hanya dengan ekstensi SQLite ringan tanpa dependensi berat
  • Mendukung semua platform utama seperti iOS, Android, macOS, Windows, Linux, WASM

Saran untuk developer

• Perlu menghindari cara yang hanya 'meniru' dukungan mode offline dengan antrean permintaan sederhana
• Perlu menerima konsep eventual consistency dan memanfaatkan teknik sistem terdistribusi yang telah terbukti seperti HLC dan CRDT
• Dibanding framework besar dan kompleks, lebih baik mengejar struktur kecil tanpa dependensi
• Hasilnya, aplikasi dapat memperoleh keunggulan seperti langsung responsif, bisa digunakan offline, dan jaminan privasi dasar

Panduan rujukan open source SQLite-Sync

• Jika tertarik pada engine offline-first lintas platform open source yang siap langsung dipakai di production, Anda dapat merujuk ke ekstensi SQLite-Sync

[GN⁺]

Komentar Hacker News

• CRDT (Conflict-Free Replicated Data Types) sering disebut sebagai solusi, tetapi sebenarnya sangat sulit membuat model CRDT yang sesuai dengan ekspektasi pengguna yang intuitif sekaligus logika bisnis yang konsisten, dan karena model data harus diubah menjadi kumpulan pesan lalu terus-menerus direkonstruksi kembali menjadi keadaan aktual, ini menjadi sumber masalah yang sangat besar
  • Ada inisiatif baru sebagai standar web bernama BRAID. Ini menargetkan standar sinkronisasi state web, dengan menerapkan teknik operational transform (OT) dan CRDT ke HTTP untuk pada dasarnya menciptakan web sinkronisasi yang lebih ramah bagi manusia maupun mesin. Braid meningkatkan performa jaringan dan mendukung pengembangan native P2P, pengeditan kolaboratif, serta web app local-first. Tautan terkait: pertemuan BRAID, diskusi Braid di HN, diskusi RESTful API, dan penjelasan Braid HTTP
  • Pembicaraan tentang CRDT sering muncul seolah itu solusi universal, tetapi dalam praktiknya auto-merge tidak semudah itu. Secara teknis, algoritma last-writer-wins juga bisa dianggap sebagai CRDT, tetapi untuk merge teks yang kompleks, menghormati niat dan ekspektasi pengguna sekaligus adalah masalah yang nyaris mustahil. Bahkan dalam beberapa situasi, mencoba merge dengan CRDT justru bisa menjadi pendekatan yang salah. Misalnya saat memesan ruang rapat dan dua orang memesan ruangan yang sama pada waktu bersamaan, konflik itu seharusnya dikenali dan diselesaikan langsung oleh pengguna, bukan oleh algoritma
  • Saya setuju ini adalah bidang yang sulit dimasuki kalau terlalu takut mengambil risiko. Ada juga alternatif “tanpa CRDT” untuk orang yang tidak ingin sejauh itu, lihat di sini
  • Tim kami saat membuat app local-first memakai pendekatan yang pada dasarnya mengabaikan konflik. Perubahan terakhir yang menang. Sebagian besar konflik itu sepele atau mudah diselesaikan lewat audit log, dan banyak kasus memang tidak bisa diselesaikan otomatis sejak awal. Misalnya pada task tracker dengan dukungan offline, kalau dua orang memulai tugas yang sama pada saat bersamaan, itu harus ditangani lewat proses bisnis terpisah
• Dulu hampir semua software itu local-first, dan itu dianggap wajar. Namun sekarang dunia bergerak sepenuhnya oleh kontrol dan optimisasi profit, sehingga hasilnya adalah struktur yang membuat orang lebih sering dirugikan. Bahkan kalau ada ketidakpuasan pun, sering kali tidak ada alternatif yang benar-benar tersedia
  • Dulu saat membuat produk on-premises dan self-hosted, keluhan pelanggan terbesar justru adalah tidak adanya opsi cloud. Kebanyakan perusahaan tidak ingin self-hosting, dan lebih memilih membayar biaya bulanan agar dikelola pihak lain. Menurut saya HN terlalu meremehkan besarnya permintaan nyata terhadap layanan cloud
  • Klaim bahwa “kalau orang menginginkan layanan yang tidak terlalu merugikan mereka, pasti bisa menghasilkan uang” itu tidak tepat secara ekonomi. Masalahnya adalah orang-orang pada kenyataannya memang mentoleransi kerugian itu sampai tingkat tertentu. Mungkin akan berbeda jika edukasi atau kesadaran risiko jauh lebih tinggi, tetapi menurut saya itu PR yang sangat sulit diselesaikan
  • Sebagai alternatif, orang bisa memikirkan FOSS (perangkat lunak open source)
• Saya berharap app tidak bergantung pada semua konten hanya secara online. GPS Tesla bahkan tidak menyimpan tile yang sudah pernah diunduh, jadi saat offline peta tidak menampilkan apa-apa. App seperti Peacock dan Kanopy juga tidak meninggalkan daftar media atau objek hasil render di perangkat. Padahal 95% konten itu sudah ada di perangkat, dan saya ingin itu dimanfaatkan secara aktif. Cukup tandai UI sebagai dirty sambil menunggu keberhasilan penyimpanan async. Untuk desain app offline, kebanyakan masalah sebenarnya bisa diselesaikan dengan kebiasaan yang lebih baik tanpa harus menuntut perubahan besar
  • Banyak masalah bisa diselesaikan dengan memakai Cache-Control dengan benar pada respons API dan mematuhinya di lapisan jaringan. Dengan begitu, perubahan masa hidup cache di server bisa langsung berlaku tanpa perlu update app
  • Google Maps memungkinkan download peta offline dengan memilih area secara manual, dan juga bisa menyimpan beberapa area sekaligus. Saya pernah memakainya dengan baik saat mengunjungi taman nasional
  • Menanggapi klaim bahwa “tidak perlu mengubah desain app”, saya rasa tujuan perusahaan justru memang mengumpulkan lebih banyak data. Misalnya Apple juga menyediakan peta offline, tetapi sengaja membuat datanya kedaluwarsa agar pengguna tetap terkunci di ekosistem mereka. Saya juga menduga tile peta Tesla (atau Google) punya motif tersembunyi serupa
• Ada banyak kasus ketika fokus pada isu yang “panas secara politik” seperti local-first atau desentralisasi justru membuat orang melewatkan nilai inti yang benar-benar diinginkan pengguna
  • Saat beralih ke Immich, saya kira saya akan mengorbankan banyak hal karena harus self-hosting, tetapi ternyata jauh lebih baik daripada Apple atau Google. Produk seperti ini langka seperti unicorn
• Menurut saya, alasan app local-first tidak populer pada akhirnya adalah masalah ekonomi. Model SaaS atau berbasis iklan sudah sangat mapan, sedangkan app local-first jauh kurang menguntungkan. Orang yang menyukai model ini biasanya menghargai hal-hal seperti kedaulatan data, end-to-end encryption, dan penggunaan offline, yang justru bertentangan dengan model bisnis yang ada. Akhirnya semuanya bergantung pada semangat komunitas open source
  • Sekarang pilihannya hanya “bayar uang + data” atau “menonton iklan”, sementara model membayar dengan uang tunai saja dan data tetap terlindungi praktis tersingkir
  • Saya juga sedang membuat app local-first bernama Relay, yang menambahkan kolaborasi ala Google Docs ke Obsidian. Menurut saya model bisnisnya unik. Layanannya dibagi menjadi “lapisan identitas global” dan “Relay Server” (open source/self-hosted), sehingga pengguna tetap punya kendali penuh atas isi dokumen mereka. Ini menyediakan single sign-on dan manajemen izin yang sederhana, dan tampaknya cukup menarik terutama bagi perusahaan di bidang AI dan AI Safety atau perusahaan yang sangat peduli pada compliance. Tautannya: Relay.md
  • Fenomena yang sering saya lihat di sekitar saya adalah konsumen yang akhirnya tidak jadi membeli karena saat hendak membeli hanya tersedia model langganan. Mereka sebenarnya ingin membeli dulu dan memakainya nanti, tetapi berbagai syarat seperti masa diskon atau harga yang naik saat kembali lagi justru mematikan niat beli sejak awal. Saya rasa ini bukan model bisnis yang optimal
  • Menurut saya masalahnya bukan struktur data yang direplikasi. Bahkan game single-player yang sepenuhnya local-first pun sering tetap mewajibkan koneksi internet lewat launcher
  • App local-first juga punya masalah kompleksitas yang serius. Ia harus berjalan di berbagai perangkat dan lingkungan, sedangkan app cloud-first relatif lebih mudah karena cukup dijalankan untuk satu lingkungan saja di server, dan biaya pemeliharaannya juga lebih rendah
• Di masa lalu, software desktop dan mobile justru sering diperlakukan seperti pengecualian yang aneh, padahal itu masih merupakan cara distribusi software yang sangat umum. Sebaliknya, jika mencoba mewujudkan fitur local-first di browser, kita justru harus menanggung kelemahan browser, seperti masalah integrasi dengan sistem host
• Mungkin saya melewatkan sesuatu, tetapi secara umum saya merasa app “local-first” itu justru hal yang biasa. Kebanyakan pengguna juga banyak memakai app berbasis offline. Kalau yang dimaksud adalah “local-first web app”, mungkin itu lebih tepat. Sebenarnya “local-first web app” sendiri adalah konsep yang kontradiktif
  • Saya ingin balik bertanya apakah memang masih banyak app yang local-first dalam arti dipakai dengan membayar langsung. Selain game, sekarang tampaknya hampir tidak ada lagi perusahaan seperti itu, dan bahkan game single-player pun sering menuntut internet dengan alasan DRM, anti-cheat, update, dan sebagainya
  • Yang dimaksud ‘local-first’ di sini adalah app yang sejak awal menjadikan data lokal sebagai default, bukan cloud storage, lalu mendukung sinkronisasi dengan cloud
• Bahkan app offline-first pun tidak berbeda dalam hal spinner loading yang berputar saat koneksi jaringan terputus-putus. Misalnya Google Docs tertahan karena mencoba memastikan dokumen sudah versi terbaru, dan hanya langsung terbuka kalau dipaksa putus dengan Airplane Mode. Spotify juga macet saat mencoba mengambil info tambahan online bahkan untuk playlist yang sudah disimpan. Pada akhirnya, koneksi yang tidak stabil adalah sumber masalah terbesar dalam pengembangan app offline, karena app selalu mencoba sekali lagi untuk mengakses data cloud
• Solusi pada artikel itu juga tetap terkunci pada closed cloud offering. Seperti Firebase, itu sendiri tidak masalah, tetapi sayangnya hal itu tidak ditandai dengan jelas dan justru dibungkus dengan ungkapan seperti “hanya ekstensi sqlite”, padahal yang didukung hanya cloud komersial. Vendor seperti Powersync atau ElectricSQL setidaknya cukup transparan soal ini, dan Powersync bahkan memungkinkan self-hosting
  • Saya agak bingung apakah konsep local-first benar-benar bisa diterapkan ke developer tools. Perlu dipertimbangkan apakah software berbasis model penyimpanan lokal bisa dibangun dengan alat seperti SQLite-sync. ElectricSQL bisa di-self-host, dan sepertinya saya juga harus terus memperbarui daftar alat “sqlite sync” saya. Tautan terkait: artikel asli local-first, SQLSync, SQLiteSync, SQLite-Sync
• Saya rasa kita membutuhkan lebih banyak app local-only dan self-hosted. Atau struktur federated juga bagus. Saya merasa infrastruktur jaringan selama ini menjadi hambatan, tetapi dengan munculnya solusi seperti Tailscale, app seperti ini akan jauh lebih mudah dibuat
  • Saya sedang membuat software presentasi, dan itu harus benar-benar berjalan baik secara lokal, tetapi pada saat yang sama juga harus bisa diakses dari mana saja. Ternyata memenuhi keduanya sekaligus lebih sulit daripada yang saya kira. Namun seiring perkembangan teknologi, implementasi P2P seperti direct connection atau WebRTC menjadi semakin mudah. Menerapkannya ke produk nyata dan mengujinya masih merupakan tantangan. Meski begitu, saya rasa ke depan akan semakin banyak software yang local-first sekaligus punya kemampuan jaringan yang kuat. Ini open source. Lihat profil saya untuk detail lebih lanjut
  • Saya juga belakangan ini senang mengeksplorasi area ini. Tulisan detailnya bisa dilihat di sini. Membangun app dengan pendekatan baru seperti ini cukup menyenangkan.