Software Local-First: Memiliki Data Anda Sendiri di Era Cloud (2019)

 (inkandswitch.com)
2 poin oleh GN⁺ 2025-07-06 | 1 komentar | Bagikan ke WhatsApp
  • Aplikasi cloud telah sangat meningkatkan kolaborasi dan akses dari banyak perangkat, tetapi karena salinan data yang otoritatif berada di server, kepemilikan dan kendali pengguna menjadi lebih lemah
  • Software local-first menempatkan penyimpanan lokal di laptop, tablet, dan ponsel sebagai salinan data utama, sementara server dibatasi pada peran pendukung untuk sinkronisasi dan pencadangan
  • Pendekatan ini berupaya sekaligus menghadirkan respons cepat, kerja offline, sinkronisasi banyak perangkat, kolaborasi real-time, pelestarian jangka panjang, serta keamanan dan privasi secara default
  • File, email, aplikasi web, sinkronisasi ala Dropbox, Git, Firebase, CloudKit, Realm, dan CouchDB masing-masing punya sebagian keunggulan, tetapi belum memenuhi kolaborasi dan kepemilikan data sekaligus
  • Prototipe berbasis CRDT dan Automerge menunjukkan potensi, tetapi masih ada tantangan seperti performa, komunikasi jaringan, stabilitas P2P, dan UI dokumen terdistribusi

Benturan antara kolaborasi cloud dan kepemilikan data

  • Aplikasi cloud seperti Google Docs, Figma, Slack, dan Trello diakses melalui browser atau aplikasi mobile dan menyimpan data di server
  • Model ini menawarkan keunggulan berupa kolaborasi real-time dan akses dari mana saja, tetapi semua akses data harus melewati server
    • Hanya operasi yang diizinkan server yang dapat dilakukan
    • Jika layanan berhenti, bukan hanya softwarenya, akses ke data yang dibuat dengan software tersebut juga bisa terblokir
    • Sekalipun data dapat diekspor, sulit untuk terus menjalankan software yang sama tanpa server
  • Sebaliknya, aplikasi lokal lama membaca dan menulis file di disk lokal, sehingga pengguna dapat mengendalikan sendiri pencadangan, penyimpanan jangka panjang, manipulasi dengan program lain, dan penghapusan
  • Ketegangan intinya adalah cloud memberi kolaborasi, sementara aplikasi lokal memberi kepemilikan; local-first adalah arah desain yang mencoba mendapatkan keduanya sekaligus

Model dasar software local-first

  • Software local-first memprioritaskan penyimpanan lokal dan jaringan lokal dibanding server di pusat data jarak jauh
  • Dalam aplikasi cloud, data di server adalah sumber otoritatif, sementara data di klien lebih mirip cache yang bergantung pada server
  • Dalam aplikasi local-first, data lokal di tiap perangkat adalah salinan utama, sementara server memiliki salinan pendukung yang membantu akses dari banyak perangkat dan pencadangan
  • Perubahan sudut pandang ini berdampak langsung pada performa, penggunaan offline, pelestarian jangka panjang, privasi, dan kendali pengguna

7 ideal local-first

  • 1. Operasi instan tanpa spinner

    • Aplikasi cloud menimbulkan latensi karena perubahan data dan banyak kueri memerlukan perjalanan bolak-balik ke server
    • Optimistic UI menyembunyikan latensi dengan menampilkan seolah-olah permintaan sudah selesai, tetapi ketika terjadi error jaringan, latensi kembali terlihat
    • Aplikasi local-first memiliki data utama di perangkat lokal, sehingga input pengguna lebih jarang perlu menunggu respons server
    • Sinkronisasi berjalan di latar belakang, dan aplikasi dapat merespons input hampir seketika

  • 2. Kerja yang tidak terkurung di satu perangkat

    • Pengguna berpindah-pindah di antara banyak perangkat, misalnya menangkap ide di smartphone, merapikannya di tablet, lalu mendokumentasikannya di laptop
    • Aplikasi local-first juga perlu sinkronisasi antar semua perangkat kerja sambil tetap menaruh data di tiap perangkat
    • Sebagian besar layanan sinkronisasi antarperangkat juga menyimpan salinan di server, sehingga berperan sebagai cadangan offsite
    • Jika beberapa orang mengedit file yang sama secara bersamaan, konflik dapat muncul, sehingga desain kolaborasi menjadi penting

  • 3. Jaringan sebagai opsi

    • Pesawat, terowongan, lift, tempat parkir, WiFi yang tidak stabil, biaya roaming, serta kondisi internet yang belum memadai di negara berkembang dan wilayah pedesaan menciptakan kebutuhan untuk bekerja offline
    • Aplikasi cloud umumnya lemah saat offline, dan menambahkan dukungan offline belakangan ke model yang berpusat pada server juga sulit
    • Aplikasi local-first menyimpan data utama di filesystem lokal tiap perangkat, sehingga tetap dapat dibaca dan ditulis saat offline
    • Setelah jaringan tersedia, aplikasi melakukan sinkronisasi dengan perangkat lain; sinkronisasi dapat dilakukan tidak hanya lewat internet, tetapi juga melalui Bluetooth atau WiFi lokal
    • Untuk pengalaman offline yang baik, executable yang terpasang secara lokal lebih cocok daripada tab browser

  • 4. Kolaborasi mulus dengan rekan kerja

    • Software lama berbasis file lokal mudah mengalami konflik ketika beberapa orang mengedit file yang sama secara bersamaan
    • Aplikasi cloud seperti Google Docs memopulerkan pengalaman beberapa pengguna mengedit dokumen secara bersamaan tanpa memikirkan konflik
    • Ideal local-first adalah mendukung kolaborasi real-time yang setara atau lebih baik daripada aplikasi cloud terbaik saat ini
    • Alur ketika satu pengguna mengusulkan perubahan dan pengguna lain meninjaunya lalu menerapkan secara selektif juga penting
      • suggesting mode di Google Docs
      • pull request di GitHub

  • 5. Long Now: aksesibilitas jangka panjang

    • Aspek penting dari kepemilikan data adalah data harus tetap dapat diakses untuk waktu yang lama di masa depan
    • Aplikasi lokal lama dapat terus digunakan jika ada data dan salinan software yang dapat dijalankan, dan sistem operasi atau komputer lama pun dapat dijalankan lewat mesin virtual atau emulator
    • Meski media penyimpanan berubah, file dapat disalin ke media baru
    • Aplikasi cloud bergantung pada asumsi bahwa layanan akan terus tersedia, dan rentan terhadap penutupan layanan, kehilangan data, perubahan harga atau fitur, serta upgrade paksa yang tidak diinginkan
    • Software local-first meningkatkan peluang pelestarian jangka panjang karena data dan software untuk membaca serta mengubah data tersebut disimpan secara lokal
    • plain text, JPEG, dan PDF kemungkinan besar akan tetap dapat dibaca untuk waktu lama, dan Library of Congress AS merekomendasikan XML, JSON, dan SQLite sebagai format pelestarian dataset

  • 6. Keamanan dan privasi sebagai default

    • Aplikasi cloud mengumpulkan data semua pengguna dalam database terpusat, sehingga menjadi target menarik bagi penyerang
    • Karyawan internal atau peretas yang mendapatkan akses ke server dapat membaca atau memanipulasi data, dan pelanggaran data tetap menjadi risiko umum
    • Ketentuan Google Drive menyatakan bahwa sistem otomatis menganalisis konten pengguna untuk hasil pencarian yang dipersonalisasi serta deteksi spam dan malware
    • Bagi pengguna yang menangani data sensitif, seperti tenaga medis, jurnalis investigasi, serta pejabat pemerintah dan diplomatik, penggunaan aplikasi cloud dapat berbenturan dengan regulasi dan kewajiban kerahasiaan
    • Aplikasi local-first menyimpan hanya data milik pengguna sendiri di masing-masing perangkat lokal, dan dapat menaruh di server hanya salinan yang dienkripsi end-to-end
    • iMessage, WhatsApp, Signal, Keybase, dan Tarsnap disebut sebagai contoh enkripsi end-to-end atau berbagi file dan pencadangan terenkripsi

  • 7. Kepemilikan dan kendali final

    • Dalam aplikasi cloud, penyedia layanan dapat membatasi akses pengguna
    • Pada Oktober 2017, sebagian pengguna Google Docs diblokir dari mengakses dokumen mereka karena sistem otomatis keliru menandai dokumen sebagai berbahaya
    • Di sini, kepemilikan bukan berarti hak kekayaan intelektual, melainkan agensi pengguna, otonomi, dan kendali atas data
    • Dalam software local-first, byte yang membentuk data berada di perangkat pengguna, sehingga pengguna memiliki kebebasan untuk memprosesnya dengan cara apa pun
    • Kepemilikan data juga disertai tanggung jawab untuk menjaga cadangan, mencegah kehilangan data, merespons ransomware, dan mengelola arsip file
    • Local-first tidak harus selalu open source; software komersial dan tertutup pun bisa mendekati ideal ini jika tidak membatasi penggunaan file secara artifisial
    • Contoh pembatasan artifisial yang disebutkan adalah PDF yang mencegah pencetakan, pembaca eBook yang menghambat copy-paste, dan DRM pada file media

Keterbatasan Model Penyimpanan dan Berbagi yang Ada

  • File dan lampiran email

    • File tradisional unggul untuk melihat dan mengedit secara offline, kendali pengguna, backup, pelestarian jangka panjang, dan akses cepat
    • Untuk akses dari banyak perangkat, dibutuhkan cara seperti email, USB, NAS/NFS/FTP/rsync, sinkronisasi file ala Dropbox, atau Git
    • Lampiran email mudah dipahami dan dapat dipercaya, dan bahkan setelah 6 bulan lampiran tetap ada dalam bentuk aslinya
    • Kelemahannya adalah kolaborasi
      • Biasanya hanya satu orang yang bisa mengedit file pada satu waktu
      • Jika beberapa orang mengedit, diperlukan penggabungan manual
      • Muncul kebingungan nama file seperti Budget draft 2 (Jane's version) final final 3.xls
    • Aplikasi yang ingin menerapkan gagasan local-first dapat mulai dengan menyediakan ekspor ke format yang didukung luas seperti plain text, PDF, PNG, dan JPEG

  • Aplikasi web

    • Aplikasi web seperti Google Docs, Trello, Figma, dan Pinterest memiliki browser atau aplikasi mobile sebagai thin client, sementara penyimpanan data berada di server
    • Aplikasi web menetapkan standar untuk kolaborasi real-time, dan keunggulannya besar dalam kerja tim karena versi terbaru bisa dilihat dari mana saja
    • Sebaliknya, kepemilikan dan kendali sangat berkurang
      • Data server menjadi acuan, dan data klien lebih mirip cache
      • Bahkan saat jaringan terputus sebentar, akses di tengah pekerjaan bisa terhalang
      • Dukungan offline terbatas seperti Google Docs offline plugin lebih mirip fitur yang ditempelkan belakangan pada arsitektur berpusat server
    • Klien desktop terinstal seperti Milanote dan Figma pun pada dasarnya adalah browser yang dikemas ulang, sehingga keterbatasannya terlihat saat terjadi gangguan jaringan, server berhenti, atau layanan ditutup

  • Dropbox, Google Drive, Box, OneDrive

    • Dropbox, Google Drive, Box, dan OneDrive memantau folder tertentu di desktop dan menyalin file yang berubah ke komputer lain
    • Karena menggunakan filesystem lokal, ini cepat dan memungkinkan kerja offline; meskipun layanan sinkronisasi ditutup, file di disk lokal tetap ada
    • Jika terjadi kerusakan hard disk, file dapat dipulihkan dengan memasang aplikasi dan menunggu sinkronisasi, sehingga ada keunggulan dari sisi jangka panjang dan kendali
    • Di iOS dan Android mobile, modelnya lebih mirip thin client yang mengambil file satu per satu dari server, bukan menyinkronkan seluruh folder
    • Opsi “Make available offline” harus ditentukan sebelumnya, merepotkan, dan hanya bekerja saat aplikasi terbuka
    • Titik terlemahnya adalah kolaborasi real-time
      • Jika file yang sama diedit di dua perangkat, muncul konflik yang perlu digabungkan secara manual
      • Kemampuan menyinkronkan format file apa pun adalah keunggulan kompatibilitas, tetapi juga menjadi kelemahan karena tidak bisa melakukan penggabungan khusus per format

  • Git dan GitHub

    • Git dan GitHub terutama digunakan untuk kolaborasi kode sumber, dan saat ini dinilai sebagai paket software yang paling mendekati local-first
    • Repositori Git adalah salinan data utama di filesystem lokal dan tidak bergantung pada server
    • Git menyediakan kerja offline penuh, operasi cepat, kendali pengguna, dan kesesuaian untuk pelestarian jangka panjang
    • GitHub menyediakan kolaborasi, akses dari banyak perangkat, serta lokasi backup dan arsip, tetapi tidak mengenkripsi repositori
    • Kelemahan besar Git ada dua
      • Tidak ada kolaborasi dengan penggabungan otomatis real-time yang halus seperti Google Docs, Trello, atau Figma
      • Git dioptimalkan untuk kode dan teks berbasis baris, sementara format file lain diperlakukan sebagai blob biner yang sulit diedit dan digabungkan secara bermakna
    • Fakta bahwa banyak software engineer enggan memakai editor dan lingkungan eksekusi berbasis cloud seperti Cloud9, Repl.it, dan Colaboratory dengan alasan “lambat”, “tidak percaya”, dan “ingin menyimpan kode di sistem lokal” berkaitan dengan motivasi local-first

Opsi dari Perspektif Infrastruktur Developer

  • Aplikasi web thin client

    • Ini adalah model tempat server Rails, Django, PHP, atau Node.js menyimpan data di database SQL atau NoSQL dan menyajikan halaman web lewat HTTPS
    • Tidak perlu instalasi, pengguna cukup mengunjungi URL, dan tanggung jawab pengelolaan data berada pada tim engineering dan DevOps yang menerapkannya
    • Meteor, ShareDB, Pusher, Ably, dan WebSocket mempermudah penambahan fitur kolaborasi real-time ke aplikasi web
    • Jika setiap tindakan pengguna memerlukan permintaan ke server, aplikasi menjadi lambat; meski JavaScript klien menyembunyikan waktu bolak-balik, koneksi internet yang tidak stabil mudah merusak pengalaman
    • Meski ada upaya seperti manifest, localStorage, service worker, dan Progressive Web Apps, arsitektur aplikasi web pada dasarnya tetap berpusat pada server
    • Jika cookie di browser dihapus, data penyimpanan lokal sering ikut terhapus, sehingga tidak cocok untuk menyimpan data penting dalam jangka panjang
    • Jika pengguna meng-host sendiri aplikasi web open source, sebagian sifatnya dapat diperbaiki, tetapi karena sebagian besar pengguna tidak ingin menjadi administrator sistem, self-hosting bukan pilihan realistis bagi mayoritas

  • Aplikasi mobile yang memakai penyimpanan lokal

    • Aplikasi iOS dan Android mengunduh biner dan memasangnya secara lokal, tetapi banyak aplikasi seperti Twitter, Yelp, dan Facebook adalah thin client yang memerlukan server agar dapat berjalan
    • Aplikasi yang terlebih dahulu menyimpan data di perangkat lokal lewat lapisan persistensi seperti SQLite, Core Data, atau file biasa lebih dekat dengan ideal local-first
    • Clue dan Things adalah contoh yang dimulai sebagai aplikasi satu pengguna, lalu menambahkan backend cloud untuk sinkronisasi antarperangkat atau berbagi
    • Aplikasi thick client seperti ini cepat dan tetap berjalan offline karena sinkronisasi server dilakukan di background
    • Tingkat kesulitannya naik ketika beberapa perangkat atau beberapa pengguna kolaboratif mengubah data
    • Developer aplikasi mobile biasanya ahli pengembangan aplikasi pengguna akhir, bukan ahli sistem terdistribusi
    • Algoritme diff, merge, dan resolusi konflik ad hoc sering kali kurang andal dan rentan

  • Firebase, CloudKit, Realm

    • Firebase adalah BaaS mobile yang menggabungkan database perangkat lokal, layanan database cloud, dan sinkronisasi keduanya
    • Firebase mendukung berbagi di banyak perangkat dan penggunaan offline, tetapi karena merupakan layanan hosting proprietary, skornya rendah untuk privasi dan jangka panjang
    • Parse diakuisisi Facebook lalu ditutup pada 2017, sehingga aplikasi yang bergantung padanya harus pindah ke backend lain
    • Firebase console memberi developer pengalaman yang baik untuk melihat, mengubah, dan menghapus data, tetapi pengguna tidak memiliki sarana akses, manipulasi, dan pengelolaan data yang sepadan
    • Apple CloudKit menyediakan pengalaman yang mirip Firebase untuk aplikasi yang dapat dibatasi pada iOS dan Mac
      • Penyimpanan key-value dan sinkronisasi
      • Fitur offline yang baik
      • Terintegrasi dengan platform sehingga mengurangi kerepotan pembuatan akun dan login
    • Realm populer sebagai library persistensi lokal iOS, dan Realm Object Server bersifat open source serta dapat di-host sendiri sehingga mengurangi risiko ketergantungan pada layanan

  • CouchDB

    • CouchDB menarik perhatian dengan pendekatan multi-master replication, yaitu banyak mesin memiliki salinan database lengkap dan tiap replika dapat membuat perubahan secara independen
    • Cloudant adalah versi hosting-nya, sementara PouchDB dan Hoodie dirancang untuk berjalan di perangkat pengguna akhir dengan memakai protokol sinkronisasi yang sama
    • Secara filosofis, CouchDB dekat dengan prinsip local-first, tetapi data yang berubah bersamaan harus diselesaikan konfliknya secara eksplisit oleh kode aplikasi
    • Dalam aplikasi kolaboratif bergranularitas halus seperti Google Docs, di mana setiap input tombol dapat menjadi perubahan terpisah, menulis kode resolusi konflik yang benar itu sulit
    • Alasan CouchDB tidak diadopsi luas mencakup skalabilitas database terpisah per pengguna, embedding klien JavaScript di dalam aplikasi native iOS dan Android, resolusi konflik, serta model kueri MapReduce yang terasa asing

CRDT dan teknologi fondasi yang lebih baik

  • Lapisan data untuk pengembangan aplikasi yang ada belum memenuhi semua ideal local-first
  • Ink & Switch telah meneliti sejak 3 tahun lalu untuk mencari solusi, dan mengajukan Conflict-free Replicated Data Types atau CRDT sebagai fondasi yang menjanjikan
  • CRDT adalah struktur data serbaguna yang muncul dari riset akademis ilmu komputer pada 2011
  • Seperti struktur data semacam hashmap dan list, CRDT menyimpan status dokumen, tetapi sejak awal dirancang dengan mempertimbangkan lingkungan multi-pengguna
  • Editor teks, spreadsheet, dan aplikasi grafis vektor masing-masing mempertahankan status dokumennya sebagai struktur data, dan dalam aplikasi multi-pengguna kolaboratif, struktur tersebut dapat diganti dengan CRDT

  • Cara kerja penggabungan CRDT

    • Pengguna dapat melihat dan mengubah status aplikasi di perangkat lokal meski sedang offline
    • CRDT melacak perubahan dan, ketika jaringan tersedia, menyinkronkannya dengan perangkat lain di latar belakang
    • Jika tugas baru ditambahkan secara bersamaan dari perangkat berbeda, status hasil penggabungan akan berisi semua item yang ditambahkan dalam urutan yang konsisten
    • Perubahan bersamaan pada objek yang berbeda dapat digabungkan dengan mudah
    • Kasus yang sulit diselesaikan otomatis adalah ketika beberapa pengguna memperbarui properti yang sama dari objek yang sama secara bersamaan; CRDT melacak nilai yang berkonflik dan menyerahkannya kepada aplikasi atau pengguna untuk diselesaikan
    • CRDT mirip dengan Git, tetapi bekerja pada tipe data yang lebih kaya daripada file teks
    • Kanal sinkronisasi bisa berupa apa saja: server, koneksi P2P, Bluetooth, USB stick, dan sebagainya
    • Unit perubahan bisa sekecil satu ketukan tombol, memungkinkan kolaborasi real-time ala Google Docs, atau dapat dikirim sebagai bundel besar seperti pull request Git

  • Automerge dan Hypermerge

    • Ink & Switch mengembangkan implementasi CRDT JavaScript open-source Automerge
    • Automerge didasarkan pada riset JSON CRDT
    • Automerge digabungkan dengan Dat networking stack untuk membuat Hypermerge
    • Sulit mengatakan bahwa library-library ini sudah sepenuhnya mewujudkan ideal local-first, dan masih diperlukan banyak pekerjaan
    • CRDT berpotensi menjadi teknologi fondasi bagi software kolaboratif yang memberi pengguna kepemilikan data, seperti packet switching pada internet atau capacitive touchscreen pada smartphone

Prototipe Ink & Switch

  • Validasi algoritme dan teori CRDT telah mengalami kemajuan di dunia akademis, tetapi penggunaannya di industri masih sedikit dan sebagian besar berada pada komputasi yang berpusat pada server
  • Contoh sistem berpusat pada server yang menggunakan CRDT antara lain Azure Cosmos DB, Redis, Riak, Weave Mesh, SoundCloud Roshi, dan Facebook OpenR
  • Ink & Switch membuat prototipe aplikasi kolaboratif local-first untuk pekerjaan kreatif yang menggunakan CRDT pada perangkat pengguna akhir
  • Eksperimen ini membahas tiga pertanyaan
    • Kemungkinan teknis: seberapa dekat CRDT dengan software nyata
    • Pengalaman pengguna: apakah kolaborasi real-time seperti Google Docs dan kolaborasi asinkron ramah offline seperti Git dapat dilakukan tanpa server otoritas pusat
    • Pengalaman developer: bagaimana lapisan data CRDT berbeda dari SQL DB, filesystem, dan Core Data
  • Tiga prototipe dibuat dengan Electron, JavaScript, dan React, dan software yang dapat diunduh serta diinstal dianggap penting bagi rasa kepemilikan

  • Trellis

    • Trellis adalah Kanban board yang dimodelkan berdasarkan Trello
    • WebRTC dicoba sebagai lapisan komunikasi jaringan
    • Riwayat perubahan dirancang dengan inspirasi dari Git dan fitur “See New Changes” di Google Docs
    • Pengguna dapat melihat tugas di Kanban board dan kembali melihat status dokumen sebelumnya

  • Pixelpusher

    • Pixelpusher adalah program menggambar kolaboratif yang menambahkan pengalaman kolaborasi real-time ala Figma ke Pixel Art to CSS karya Javier Valencia
    • Komunikasi jaringan dicoba dengan library P2P dari proyek Dat
    • Eksperimen mencakup URL berbagi dokumen, branch/merge visual yang terinspirasi Git, penyelesaian konflik yang menyorot piksel bermasalah dengan warna merah, serta identifikasi pengguna dasar berbasis avatar yang digambar pengguna

  • PushPin

    • PushPin adalah mixed media canvas workspace yang mirip dengan Miro atau Milanote
    • Sebagai proyek ketiga berbasis Automerge, prototipe ini memiliki tingkat penyelesaian paling tinggi di antara ketiganya
    • Penggunaan nyata oleh tim dan pengguna uji eksternal memberi beban lebih besar pada underlying data layer
    • Eksperimen mencakup dokumen bersama yang bersarang dan saling terhubung, berbagai renderer untuk dokumen CRDT, sistem identitas yang lebih maju termasuk model outbox, serta berbagi data sementara seperti penyorotan pilihan

Hasil yang Didapat dari Prototipe

  • Tujuan dari tiga prototipe tersebut adalah mengevaluasi kemungkinan teknis, pengalaman pengguna, dan pengalaman developer dari software local-first dan CRDT
  • Digunakan secara rutin oleh 5 orang di tim pengembangan, dan uji kegunaan individual dilakukan dengan sekitar 10 pengguna eksternal
    • Pengguna eksternal mencakup desainer profesional, product manager, dan software engineer
    • Pendekatan yang digunakan bersifat eksploratif, bukan metodologi evaluasi formal

  • Teknologi CRDT berfungsi

    • Keandalan Automerge lebih baik dari perkiraan
    • Developer aplikasi dalam tim dapat mengintegrasikan library ini dengan relatif mudah, dan penggabungan data otomatis hampir selalu terasa intuitif dan mulus

  • Pengalaman pengguna offline terasa baik

    • Alur berpindah ke offline, bekerja selama yang diinginkan, lalu terhubung kembali dan menggabungkan perubahan dari rekan kerja berjalan dengan baik
    • Bahkan ketika aplikasi lain menampilkan peringatan “offline” dan error yang menghalangi pekerjaan, prototipe local-first tetap berjalan normal terlepas dari status jaringan
    • Berbeda dari sistem berbasis browser, pengguna tidak lagi terlalu khawatir apakah aplikasi akan berjalan atau datanya tersedia, dan ini memberi rasa kepemilikan atas alat serta hasil kerja

  • Cocok dengan model FRP React

    • Model Functional Reactive Programming milik React cocok dengan CRDT
    • Pada lapisan data berbasis CRDT, dokumen menerima input pengguna lokal dan perubahan dari pengguna/perangkat lain melalui jaringan secara bersamaan
    • Model FRP menyinkronkan status aplikasi yang terlihat dengan underlying state dari dokumen bersama secara stabil
    • Developer terbebas dari pekerjaan merepotkan untuk melacak perubahan dari pengguna lain dan menyesuaikannya dengan layar saat ini
    • Jika semua perubahan status dilewatkan melalui satu fungsi reducer, mengirim perubahan lokal terkait ke pengguna lain juga menjadi mudah

  • Konflik lebih ringan dari perkiraan

    • Pengguna jarang menemui konflik saat berkolaborasi, dan mekanisme penyelesaian umum bekerja dengan baik
    • Automerge melacak perubahan pada tingkat granular dan mempertimbangkan makna tipe data
    • Jika dua pengguna secara bersamaan menyisipkan item di posisi yang sama dalam sebuah array, kedua item digabungkan dalam urutan deterministik
    • Sistem version control teks seperti Git dapat menganggapnya sebagai konflik yang perlu diselesaikan secara manual
    • Pengguna memiliki intuisi tentang kolaborasi, sehingga kadang secara implisit membagi area kerja agar tidak mengedit bagian yang sama pada saat bersamaan
    • Pada aplikasi Kanban, jika satu pengguna memberi komentar pada kartu dan pengguna lain memindahkan kartu itu ke kolom lain, kedua perubahan tetap tercermin
    • Konflik hanya terjadi ketika properti yang sama dari objek yang sama diedit secara bersamaan; contohnya ketika dua pengguna mengubah posisi objek gambar yang sama pada saat yang sama
    • Dalam prototipe, semantik penggabungan default Automerge sudah cukup, dan tidak ditemukan kasus yang membutuhkan semantik kustom

  • Visualisasi riwayat dokumen penting

    • Dalam sistem kolaborasi terdistribusi, banyak perubahan dari pengguna lain bisa tiba kapan saja
    • Karena tidak ada server pusat yang memediasi perubahan, diperlukan alat untuk memahami jalur yang membuat dokumen berada pada status saat ini, versi yang ada, dan asal kontribusi
    • Trellis bereksperimen dengan antarmuka “time travel” yang memungkinkan pengguna berpindah dan melihat status masa lalu dari dokumen yang sudah digabungkan
    • Mereka juga bereksperimen dengan cara menyorot otomatis elemen perubahan yang baru diterima

  • Berbagi URL terasa alami

    • Di antara berbagai mekanisme berbagi dokumen, model URL yang terinspirasi dari web terasa paling alami bagi pengguna dan developer
    • URL dapat disalin dan ditempel, serta dibagikan melalui kanal komunikasi seperti email atau chat
    • Hak akses dokumen di luar URL rahasia masih menjadi pertanyaan riset terbuka

  • Sistem P2P tidak terbagi sederhana menjadi online dan offline

    • Sistem tersentralisasi biasanya mendefinisikan status “up” atau “down” berdasarkan apakah koneksi ke server stabil
    • Dalam sistem terdistribusi, setiap pengguna dapat memiliki perspektif berbeda tergantung data apa yang mereka miliki, bagikan, dan terima
    • Edit yang ada di laptop di dalam pesawat dapat didistribusikan ke pengguna lain setelah mendarat dan tersambung kembali
    • Pengguna lain dapat menerima semua, sebagian, atau sama sekali tidak menerima perubahan tersebut ke versi dokumen mereka sendiri
    • Seperti repositori Git, “master” milik pengguna tertentu menjadi fungsi dari kapan terakhir kali ia berkomunikasi dengan pengguna lain
    • Dokumen terdistribusi memberi pengguna kendali atas data, tetapi apa maknanya dari sudut pandang UI nyata masih memerlukan riset lebih lanjut

  • Riwayat perubahan yang panjang menimbulkan masalah performa

    • Ketika PushPin digunakan untuk dokumen nyata seperti perencanaan sprint, performa serta penggunaan memori dan disk dengan cepat menjadi masalah
    • CRDT menyimpan seluruh riwayat, termasuk pengeditan teks per karakter
    • Riwayat tidak dapat dipotong begitu saja karena mungkin saja enam bulan kemudian seseorang terhubung kembali ke dokumen dan harus menggabungkan perubahan sejak titik waktu itu
    • Optimisasi Automerge terus berlanjut dan tetap menjadi area pekerjaan utama yang sedang berjalan

  • Komunikasi jaringan belum terselesaikan

    • Algoritme CRDT hanya menangani penggabungan data, bukan bagaimana edit dari pengguna lain secara fisik sampai ke komputer yang sama
    • Dalam eksperimen, mereka mencoba WebRTC, implementasi sneakernet yang menyalin file dengan Dropbox dan USB key, kemungkinan protokol IPFS, serta library P2P Hypercore dari Dat
    • CRDT tidak harus membutuhkan lapisan jaringan P2P; komunikasi melalui server juga memungkinkan
    • Untuk sepenuhnya mewujudkan tujuan jangka panjang local-first, solusi terdesentralisasi yang bertahan lebih lama daripada layanan backend vendor adalah tujuan akhir yang logis
    • Teknologi P2P belum cukup siap untuk produksi, dan khususnya NAT traversal kurang andal tergantung router atau topologi jaringan
    • Pengalaman berkolaborasi real-time secara langsung antarkomputer tanpa akses internet menunjukkan potensi besar di dunia yang bergantung pada API pusat

  • Server cloud tetap berperan sebagai pendukung

    • Prototipe kolaborasi real-time seperti PushPin dapat berbagi dokumen tanpa server perantara, sehingga baik untuk privasi dan kepemilikan
    • Namun jika pengguna menutup laptop setelah membagikan dokumen sebelum pihak lain terhubung, keduanya tidak dapat terhubung karena tidak online pada saat yang sama
    • Dalam dunia local-first, server dapat berperan bukan sebagai otoritas pusat, melainkan sebagai cloud peer
      • Menyimpan salinan dokumen lalu meneruskannya ketika peer lain online
      • Menyediakan lokasi arsip dan backup
      • Menjadi bridge ke API server tradisional seperti prakiraan cuaca atau harga saham
      • Menyediakan burst computing seperti rendering video dengan GPU yang kuat
    • Perbedaan antara sistem tradisional dan sistem local-first bukanlah ada atau tidaknya server, melainkan bahwa server mengambil peran pendukung, bukan sumber kebenaran

Pekerjaan yang Diperlukan ke Depan

  • Peneliti sistem terdistribusi dan bahasa pemrograman

    • Riset CRDT dan teknologi P2P dapat berkontribusi besar pada software local-first
    • Riset CRDT saat ini biasanya mengasumsikan model di mana semua kolaborator segera menerapkan edit ke satu versi dokumen
    • Aplikasi local-first di dunia nyata harus dapat menolak edit dari kolaborator lain, atau membuat perubahan privat pada versi dokumen yang tidak dibagikan
    • Masih kurang riset yang memperluas konsep kontrol sumber terdistribusi seperti branch, fork, dan rebase menjadi model kolaborasi di mana beberapa versi dokumen dan branch dapat hidup berdampingan
    • Tipe, migrasi skema, dan kompatibilitas juga merupakan isu penting
      • Setiap kolaborator dapat menggunakan versi dan fitur aplikasi yang berbeda
      • Karena tidak ada server DB pusat, tidak ada skema “saat ini” yang otoritatif untuk data
      • Beberapa versi aplikasi harus dapat saling beroperasi dengan aman saat format data berevolusi

  • Peneliti HCI

    • Pada sistem tersentralisasi, ada banyak contoh yang menampilkan status sinkronisasi dengan server, tetapi sistem terdesentralisasi memiliki persoalan UI baru
    • Diperlukan riset tentang cara menyampaikan status online/offline dan tersedia/tidak tersedia dalam sistem di mana semua pengguna dapat memiliki salinan data yang berbeda
    • Ketika kolaborasi langsung dengan node lain dimungkinkan tanpa internet luas, arti “online” pun berubah
    • Karena setiap dokumen dapat memiliki riwayat versi yang kompleks hanya melalui penggunaan sehari-hari, diperlukan UI yang membantu pengguna memahami versi, penerimaan perubahan, dan proses pembentukan dokumen
    • Saat ini, manajemen perubahan didominasi oleh model diff/patch ala kode sumber dan model suggestion/comment ala Google Docs
    • Cara menggeneralisasi ide ini ke format data selain teks masih menjadi masalah terbuka
    • Dalam local-first, pengguna yang memiliki data tidak dapat dicegah untuk mengubahnya secara lokal, dan konsep izin berubah menjadi model di mana pengguna lain memilih apakah akan berlangganan perubahan tersebut

  • Praktisi

    • Engineer, desainer, manajer produk, dan developer independen yang membuat software produksi dapat mengambil langkah bertahap menuju masa depan local-first
    • Untuk aplikasi yang cepat, kurangi spinner saat membuka dokumen dengan caching agresif dan pra-unduh, serta pada dasarnya percayai cache lokal
    • Multi-perangkat dapat didukung relatif mudah dengan infrastruktur sinkronisasi seperti Firebase dan iCloud, tetapi ada kekhawatiran soal keberlanjutan jangka panjang dan privasi
    • Untuk offline di web, Progressive Web Apps, Service Workers, dan app manifest dapat membantu
    • Pengujian aplikasi dapat dilakukan dengan mematikan WiFi atau mengubah kondisi jaringan menggunakan alat seperti Chrome DevTools network condition simulator dan iOS network link conditioner
    • Untuk kolaborasi, selain CRDT, Operational Transformation yang diimplementasikan di ShareDB dan lainnya adalah teknologi yang lebih mapan
    • Untuk preservasi jangka panjang, aplikasi harus dapat mengekspor dengan mudah ke format stabil seperti JSON dan PDF
      • Ekspor massal seperti Google Takeout
      • Backup berkelanjutan dalam format file stabil milik GoodNotes
      • Pengunduhan dokumen JSON dari Trello
    • Dari sisi privasi, pengguna harus diberi tahu dengan jelas apakah data hanya disimpan di perangkat atau dikirim ke backend
    • Untuk kontrol pengguna, backup, duplikasi, dan penghapusan dokumen di dalam aplikasi harus mudah dilakukan; Google Docs yang mengimplementasikan ulang operasi filesistem dasar melalui Google Drive disajikan sebagai contoh

Peluang Startup dan Kesimpulan

  • Bagi pendiri yang ingin membangun infrastruktur developer, “Firebase for CRDTs” disajikan sebagai peluang pasar yang menarik
  • Startup semacam itu harus menyediakan pengalaman developer yang baik dan library persistensi lokal seperti SQLite atau Realm
  • Harus mendukung iOS, Android, Windows, Mac, Linux, Electron, dan Progressive Web Apps
  • Kontrol pengguna, privasi, dukungan multi-perangkat, dan kolaborasi harus disertakan secara default
  • Uji lakmus keberhasilannya adalah apakah aplikasi pelanggan tetap berfungsi selamanya meskipun semua server dimatikan
  • Software cloud telah menghadirkan kolaborasi dan aplikasi modern yang dapat diakses dari mana saja, tetapi dengan menempatkan kepemilikan data di server, ia membuat pengguna seperti penyewa atas data mereka sendiri
  • Pendekatan local-first menunjukkan bahwa pengguna dapat mempertahankan kepemilikan dan kontrol atas data sambil tetap memperoleh kolaborasi dan aksesibilitas ala cloud
  • Untuk implementasi nyata, masih diperlukan lebih banyak dukungan offline, pemanfaatan penyimpanan on-device, perbaikan algoritme, model pemrograman, dan antarmuka pengguna, serta produkisasi CRDT dan jaringan P2P

Bacaan terkait

1 komentar

 
GN⁺ 2025-07-06
Komentar Hacker News

  • Sepenuhnya setuju. Saya sudah muak dengan tren semua layanan mengambil data saya ke cloud mereka, lalu membuat saya membayar biaya langganan agar bisa menggunakannya dengan layak
    Aplikasi pelacak kebugaran yang sedang saya buat akan memakai model “beli sekali, dapat pembaruan selama X tahun, sinkron dengan semua perangkat, lalu tetap bisa dipakai selamanya setelah itu”. Jika setelah X tahun butuh pembaruan, pengguna bisa membeli versi baru lagi; kalau fitur yang ada sekarang sudah cukup, tinggal terus dipakai
    Saya berharap sebagian besar software bisa dibeli dengan harga wajar seperti ini, produknya sendiri bagus, dan tidak dikunci sehingga tidak bisa dipakai tanpa cloud. Hal terbaik dari software local-first adalah ia menghidupkan kembali insentif yang sehat untuk mendapatkan uang dari kualitas produk, bukan dari iklan, pelacakan, atau memaksimalkan engagement

    • Obsidian juga model yang bagus untuk dijadikan referensi. Kliennya sepenuhnya gratis, dan mereka hanya menjual layanan sinkronisasi opsional
      Semua catatan berupa file Markdown, sehingga kliennya sendiri pun menjadi opsional
    • Saya penasaran bagaimana rencananya melakukan sinkronisasi tanpa infrastruktur cloud
    • “Pembaruan X tahun + sinkronisasi perangkat + penggunaan selamanya” terdengar bagus, tetapi dengan cara ini Anda harus menerima total biaya langganan untuk 1–2 tahun sekaligus
      Server sinkronisasi juga harus terus dioperasikan, dan Anda perlu mempertimbangkan kasus ketika pengguna menyinkronkan data setahun penuh dalam satu hari. Orang yang mengerjakan pengembangan di masa depan juga harus terus digaji, jadi jika dilihat hanya dari sudut pandang developer, ada bagian yang terlewat
    • Beberapa tahun lalu, sebuah pabrik lokal menghentikan produksi selama dua hari akibat gangguan server pemasok IT, dan saya memikirkan skenario terburuk lalu punya pemikiran serupa
      https://rodyne.com/?p=1439
    • Backend bisa saja menjadi bagian dari fitur, seperti kolaborasi real-time atau sinkronisasi. Namun jika bisa dikeluarkan dari cloud (ejectable) dan kapan saja dialihkan ke self-hosting atau dikembalikan lagi, itu dapat menjamin kepemilikan dan keberlanjutan jangka panjang atas data maupun layanan
      IDE catatan/tugas yang kami buat juga memakai pendekatan seperti ini: https://thymer.com/local-first-ejectable

  • Di Berlin ada Local-first Software Conference tahunan yang diselenggarakan oleh Ink and Switch, dan pada November tahun ini di SF juga akan ada acara turunan bernama Sync Conf
    https://www.localfirstconf.com/
    https://syncconf.dev/
    Tahun ini ada panel menarik dari para penulis bersama makalah aslinya yang membahas apa itu software local-first dalam konteks tooling pengembang, dan apa saja yang telah mereka pelajari sejak makalah awal: https://youtu.be/86NmEerklTs?si=Kodd7kD39337CTbf
    Komunitasnya sedang mengerucut pada pandangan bahwa “sinkronisasi” adalah salah satu komponen local-first, tetapi merupakan teknologi yang bisa diterapkan jauh lebih luas. Local-first adalah karakteristik software untuk pengguna akhir, sedangkan tooling pengembang seperti mesin sinkronisasi adalah alat yang memungkinkannya, bukan sesuatu yang dengan sendirinya harus local-first
    Seluruh presentasi beberapa tahun terakhir ada di sini: https://youtube.com/@localfirstconf?si=uHHi5Tsy60ewhQTQ
    Ini masa yang menarik bagi komunitas local-first/mesin sinkronisasi. Mereka telah membangun alat yang memungkinkan pengalaman kolaborasi real-time dan kolaborasi asinkron, dan dengan hadirnya AI, pasar ini sedang membesar. Semua aplikasi AI pada dasarnya adalah sistem kolaborasi multi-pengguna dengan agen ikut berpartisipasi sebagai aktor, sehingga membutuhkan teknologi yang selama ini ditangani komunitas mesin sinkronisasi

    • Ada juga podcast Local First yang bagus, yang mewawancarai para engineer pembuat aplikasi dan infrastruktur local-first
      https://www.localfirst.fm/

  • Layak dibaca, dan sebelumnya juga sudah beberapa kali ada diskusi yang aktif
    https://news.ycombinator.com/item?id=19804478 - Mei 2019, 191 komentar
    https://news.ycombinator.com/item?id=21581444 - November 2019, 241 komentar
    https://news.ycombinator.com/item?id=23985816 - Juli 2020, 9 komentar
    https://news.ycombinator.com/item?id=24027663 - Agustus 2020, 134 komentar
    https://news.ycombinator.com/item?id=26266881 - Februari 2021, 90 komentar
    https://news.ycombinator.com/item?id=31594613 - Juni 2022, 30 komentar
    https://news.ycombinator.com/item?id=37743517 - Oktober 2023, 50 komentar

  • Ketergantungan pada online pasti membawa pemeliharaan dan biaya berkelanjutan. Jika sebuah sistem tidak local-first, atau sebisa mungkin hanya lokal, berarti sistem itu tidak dirancang untuk keandalan jangka panjang
    Perangkat rumah tangga dan mobil yang terhubung, dari sudut pandang praktis, mendekati rekayasa paling bodoh

    • Semuanya karena pendapatan langganan
      Perusahaan yang memperoleh pendapatan langganan punya pendapatan lebih besar dan valuasi lebih tinggi, sehingga lebih mudah mendapatkan pendanaan tambahan, lalu mengalahkan perusahaan yang tidak mengikuti model ini. Karena struktur yang memperkuat dirinya sendiri seperti ini, saya rasa software local-first sudah mati
    • Jika melihat storage gratis/berbayar dari tempat seperti Dropbox atau Apple, biaya sebenarnya terlihat. Kira-kira 10 dolar per bulan untuk 2TB
      Cloudflare menyediakan hosting file statis nyaris gratis, dan biayanya hampir seperti kesalahan pembulatan. Bahkan jika 1000 aplikasi local-first tersinkronisasi ke Dropbox, semuanya bisa berjalan dengan storage 10 dolar per bulan. Storage ini bukan alat mentah tingkat rendah seperti S3, melainkan layanan konsumen yang sudah dilengkapi autentikasi, dukungan, hingga program sinkronisasi. Sebagian besar biaya cloud sebenarnya tidak diperlukan
    • Jika Anda termasuk orang yang menentang inisiatif Stop Killing Games, sebaiknya baca komentar ini
      Tidak ada yang memaksa game bergantung hanya pada layanan online. Itu bukan tuntutan hukum maupun regulasi. Seperti banyak hal dalam software, itu hanya sebuah pilihan. Memilih untuk bergantung pada layanan online lalu kemudian berkata “membalikkan ini akan membutuhkan biaya” adalah pandangan picik, menyedihkan, dan tidak boleh diterima

  • Lebih banyak aplikasi seharusnya local-first. Jika pengguna tidak ingin menyinkronkan datanya ke cloud, opsi itu harus tersedia
    Selama beberapa waktu saya membuat Brisqi, aplikasi offline-first atau local-first, dan sejak awal dirancang dengan filosofi offline-first
    https://brisqi.com
    Aplikasi local-first harus dirancang agar dapat berjalan sepenuhnya offline tanpa batas waktu. Pengalaman lokal adalah fondasinya, bukan sarana cadangan, dan sinkronisasi cloud seharusnya menjadi fitur pendukung, bukan persyaratan
    Aplikasi yang bergantung pada cache sementara tidak saya anggap offline-first. Aplikasi offline-first yang sesungguhnya harus mempertahankan data secara persisten di database lokal. Banyak aplikasi yang disebut “offline-first” sebenarnya lebih dekat ke offline-tolerant, hanya menyediakan fungsi offline terbatas dan pada akhirnya bergantung pada koneksi ulang ke internet
    Aplikasi offline-first jelas lebih sulit dibuat daripada aplikasi web yang hanya online, dan mekanisme sinkronisasinya harus cukup andal agar data tetap konsisten saat berpindah antara offline/online, tersinkronisasi ke cloud, dan tidak hilang. Saya menuliskan lebih banyak tentang pendekatannya di blog: https://blog.brisqi.com/posts/how-i-designed-an-offline-first-app-an-outline

    • Saya khawatir model ini mungkin lebih sulit berkelanjutan sebagai bisnis, dan penasaran bagaimana kenyataannya sejauh ini

  • Menarik bahwa prinsip ini dijelaskan untuk ranah konsumen, tetapi saat ini kami melakukan hal yang sama di sisi aset industri/data industri
    Di www.sentineldevices.com, seluruh proses pembelajaran, analisis, dan pengambilan keputusan berlangsung di atas peralatan pelanggan. Bahkan tidak ada server untuk mengirim data; modelnya secara eksplisit menjalankan semuanya di dalam perangkat
    Dalam SCADA/otomasi industri, ada banyak use case yang datanya tidak bisa dibawa keluar. Perusahaan data/AI mengabaikan basis pelanggan dan use case yang sangat besar karena sulit menyediakan layanan di tempat pelanggan berada, dan sebagai gantinya berusaha membawa data kepada mereka sambil mempertahankan vendor lock-in
    Saat berbicara dengan pelanggan, kami justru harus sangat menekankan “tidak, ini lokal dan tidak ada koneksi eksternal”. Karena mereka hampir tidak pernah mendengar hal seperti ini, sering kali kami harus menjelaskannya langkah demi langkah sampai mereka memahami bahwa semuanya terjadi secara lokal, dan vendor software pun tidak terlalu bisa menerima konsep ini. Semoga software local-first makin mapan di ranah konsumen sehingga di ranah industri juga menjadi lebih familier

    • Tidak membantu juga bahwa semua vendor SCADA ikut-ikutan tren cloud dan mendorong ke arah itu
      “Operasikan pabrik Anda dari smartphone!” Hebat, sekarang satu zero-day saja bisa membuat script kiddie bermain-main dengan pompa saya
    • Ini bidang yang menarik, dan senang mendengar Anda mengerjakannya
      Saya melihat halaman kariernya dan semua posisi tidak remote; saya penasaran apakah itu karena keterbatasan bahwa membuat software local-first harus bertatap muka langsung, atau terutama karena alasan manajerial

  • Secara pribadi saya tidak setuju dengan pendekatan ini. Ini terlihat seperti upaya menyelesaikan masalah bisnis “tidak bisa memercayai penyedia cloud” lewat kompromi teknis “menghindari arsitektur terpusat”.
    Kurangnya kendali dan keandalan pada perangkat lunak tertutup sudah diatasi lewat model bisnis baru berupa pengembangan open source, lisensi baru, dan cara menghasilkan pendapatan seperti kontrak pemeliharaan alih-alih biaya lisensi.
    Demikian pula, masalah pada penyedia cloud membutuhkan solusi di tingkat model bisnis. Misalnya, bisa dibuat kontrak/lisensi standar yang mendefinisikan hak-hak agar pengguna dapat memercayai hubungan mereka dengan penyedia cloud. Seiring waktu, pengguna mungkin hanya akan bertransaksi dengan penyedia yang memiliki lisensi semacam ini.
    Di dalamnya bisa ada klausul seperti perjanjian akhir masa pakai, jaminan portabilitas data, dan transparansi privasi data yang mengaudit akses data serta memberi tahu siapa/apa/kapan data dibaca. Masalahnya adalah adopsi. Intinya, mengapa penyedia cloud harus menerimanya; jika mereka takut churn, mereka bisa menawarkan kontrak seperti ini hanya untuk langganan tahunan atau mengenakan harga lebih tinggi.

    • Jika masalah bisnis atau politik bisa diselesaikan dengan solusi teknis, biasanya itu pendekatan yang kuat. Sebab masalah seperti itu ditimbulkan oleh pihak yang bersifat adversarial, dan solusi teknis menghilangkan kemampuan pihak tersebut untuk berkhianat.
      Enkripsi saat memakai layanan cloud adalah contoh yang bagus. Mencoba melindungi data dengan kebijakan privasi dan aturan birokratis hampir sia-sia. Data bernilai, pelanggan atau pemerintah sulit mengetahui apakah perusahaan diam-diam menjualnya, dan juga sulit mengetahui apakah mereka menghemat biaya keamanan sebelum semuanya terlambat.
      Namun jika data dienkripsi di perangkat klien dan dapat dibuktikan secara matematis bahwa server tidak bisa mengakses plaintext, kita tidak perlu mengkhawatirkan hal-hal itu. Masalahnya muncul ketika server tidak hanya menyimpan data, tetapi juga harus memprosesnya; pada saat itu solusi teknisnya adalah memakai server sendiri.
    • Saya ragu kontrak seperti itu benar-benar menyelesaikan masalah. Sekalipun layanan cloud mendokumentasikan bahwa mereka akan memberi pemberitahuan X bulan sebelum penutupan dan mengizinkan ekspor data, setelah layanan benar-benar berakhir yang tersisa di tangan bisa saja pada praktiknya hanya file JSON raksasa yang tidak berguna.
      Sulit memanfaatkannya kecuali Anda membuat aplikasinya sendiri atau ada orang baik yang membuatkannya. Itu lebih baik daripada tidak ada apa-apa, tetapi tidak sebagus aplikasi lokal yang bisa tetap berjalan selama bertahun-tahun atau puluhan tahun setelah perusahaan tutup atau menghentikan dukungan.
    • Model ini bisa membuat penyedia cloud menjadi seperti bank. Penyedia cloud menyimpan semacam properti di dalam akun pengguna, dan pengguna memiliki hak yang jelas atas properti itu serta kemampuan hukum untuk mengambilnya kembali dari akun.
      Dalam keuangan, pengambilan kembali setara dengan menerima uang atau properti; di cloud, itu bisa berupa menerima file Zip besar berisi seluruh isi akun.
      Namun menerima penyerahan itu tidak selalu praktis atau diinginkan. Dalam keuangan, rekening bisa dipindahkan ke penyedia lain, dan dalam layanan cloud pun dalam banyak kasus pemindahan akun kemungkinan jauh lebih berguna.
      Yang sulit di sini adalah portabilitas. Bahkan jika hak milik dan hak pengguna atas akun cloud didefinisikan dengan baik, masih samar apa artinya menerima “teman Facebook” sebagai penyerahan, atau apa makna memindahkan akun Facebook ke tempat lain.
    • Menurut saya penafsiran itu tidak tepat. Para penulis cukup mengakui bahwa kasus bisnis untuk local-first belum sepenuhnya terselesaikan dan merupakan masalah yang berkaitan erat.
      Masalah ini membutuhkan solusi bisnis dan teknis sekaligus, dan makalah tersebut mengusulkan karakteristik seperti apa yang seharusnya dimiliki solusi.
      Tidak benar juga bahwa local-first mengadvokasi desentralisasi. Martin Kleppmann secara eksplisit menyatakan bahwa ia tidak melihat teknologi terdesentralisasi sebagai cara menyelesaikan masalah ini untuk pasar massal. Ia mendukung mesin sinkronisasi standar yang tersentralisasi yang memungkinkan ideal local-first.
      Lihat presentasi Local-first conf tahun lalu: https://youtu.be/NMq0vncHJvU?si=ilsQqIAncq0sBW95
    • Jaminan portabilitas data tidak praktis untuk data yang ukurannya sudah cukup besar. Memigrasikan database lingkungan produksi ke database baru bisa memakan waktu berbulan-bulan hingga bertahun-tahun agar berjalan mulus.
      Dalam situasi krisis, itu bisa dilakukan dalam beberapa minggu, tetapi hasilnya bisa sangat berantakan. Bahkan memindahkan antar-database open source dengan versi yang sama pun demikian, karena ada banyak perbedaan antar-layanan cloud.
      Solusi terbaik adalah sejak awal menaruh data di lingkungan sendiri dan memutus koneksi bila perlu. Ini dimungkinkan dengan menggabungkan pengelolaan BYOC dan open source. Perusahaan kami juga mengoperasikan produk data BYOC, jadi kami punya kepentingan ekonomi dalam pendekatan ini, tetapi saya tahu ini mungkin karena saya sudah melihatnya benar-benar berjalan.

  • Dengan proyek saya https://github.com/ibizaman/selfhostblocks dan https://github.com/ibizaman/skarabox, saya mencoba membuat hal itu tersedia luas
    Tujuan umumnya adalah membuat self-hosting lebih mudah diakses oleh khalayak umum
    Berbasis NixOS, saya berusaha menyediakan https, SSO, LDAP, backup, ZFS dengan snapshot, dan lainnya secara bawaan dengan pendekatan sedeklaratif mungkin
    Dengan memaketkan Vaultwarden dan Nextcloud, sebagian besar data bisa disimpan, sehingga ini menjadi pesaing cloud hosting, dan juga menyediakan layanan seperti Home Assistant
    Ini juga pesaing YUNoHost, tetapi lebih baik atau berupaya menjadi lebih baik karena dengan komponen yang disediakan SelfHostBlocks, Anda bisa melakukan self-hosting paket yang diinginkan sendiri. Lebih dekat ke library daripada framework
    Ini juga bersaing dengan NAS, tetapi menurut saya lebih baik karena semuanya open source. Saat ini pengguna masih harus cukup teknis, tetapi batasan itu sedang dihilangkan, dan salah satu tujuannya adalah memungkinkan orang menginstalnya di hardware sendiri tanpa perlu tahu Nix atau menyentuh command line

    • Bagus sekali. Belakangan saya sering memikirkan hal ini. Aneh rasanya, padahal ada begitu banyak alternatif free open source yang hebat, tetapi meski bagi orang teknis relatif mudah sebatas “docker compose up”, bagi nonteknis itu masih tetap sulit dijangkau
      Cukup banyak aplikasi yang bisa di-self-host adalah aplikasi web dengan database, server, dan frontend, tetapi untuk banyak use case, orang hanya memakainya di satu komputer dan tidak membutuhkan versi hosting atau sinkronisasi dengan perangkat lain. Misalnya, akuntansi pribadi cukup dilakukan sebulan sekali di komputer, jadi tidak perlu menjalankan web app 24 jam di suatu tempat. Tinggal buka programnya, kerjakan, lalu tutup
      Ada ketidaksesuaian besar antara jumlah alternatif free open source berkualitas tinggi yang bisa di-self-host dan jumlah orang yang benar-benar bisa menggunakannya. Kita butuh lebih banyak proyek yang memperkecil kesenjangan itu. Saya ingin mencoba selfhostblocks untuk beberapa hal dan berkontribusi
    • Saya suka karena menyertakan hledger. Bagi orang yang belum terbiasa dengan akuntansi plain text mungkin terasa agak asing, tetapi ini benar-benar software yang luar biasa

  • Tidak ada alasan semua aplikasi harus punya platform sinkronisasi sendiri. Framing seperti ini tampaknya berasal dari aplikasi mobile yang tidak memiliki komposabilitas atau modularitas antarprogram
    Jika benar-benar menganggap “local-first” secara serius, cukup gunakan file system, dan pengguna bisa memilih dari berbagai solusi seperti git, Box, dan lainnya
    Keharusan berlangganan sinkronisasi milik sendiri sama tidak menyenangkannya dengan SaaS lain, bahkan lebih buram dan rapuh

    • Saya setuju bahwa tidak semua aplikasi membutuhkan engine sinkronisasi sendiri, tetapi saya tidak setuju dengan framing bahwa file system adalah cara universal untuk menerima local-first
      Pertama, saya menginginkan local-first, tetapi juga menginginkan concurrency. Jika hanya sekadar local-first, sinkronisasi apa pun tidak masalah, tetapi saya menginginkan lebih dari itu. Saya ingin semuanya berjalan mulus seperti Dropbox tanpa perlu dipikirkan, dan meski berada di area tanpa komunikasi, saya dan istri tetap bisa mengedit secara terpisah di ponsel masing-masing
      Kedua, sinkronisasi bekerja jauh lebih baik ketika sangat memahami struktur dan makna data. git dan Box sama-sama punya batasan yang cukup besar, dan jika ada kebutuhan concurrency, batasan itu makin besar
    • Secara umum saya setuju, tetapi dalam praktiknya tidak selalu sesederhana itu. Saya pernah membuat aplikasi yang bekerja persis seperti itu, tetapi karena tidak bisa mengoordinasikan kapan klien mana diizinkan mengedit file, pada akhirnya konflik file tidak terhindarkan

  • Secara teori, saya suka pendekatan pengembangan local-first. Ini sangat cocok dengan filosofi small tech yang memandang privasi dan kepemilikan data sebagai hal mendasar
    Namun dalam praktiknya sulit. Pada dasarnya kita harus membuat engine sinkronisasi, menangani penyelesaian konflik, dan mengelola migrasi skema
    Meski begitu, dalam beberapa tahun terakhir alat pengembangan software local-first tampaknya sudah membaik. Saya sedang mengamati jazz.tools, electric-sql, dan Zero dari Rocicorp, dan penasaran apakah ada yang lain

    • CouchDB di server dan PouchDB di klien adalah upaya untuk menciptakan lingkungan seperti itu
      https://couchdb.apache.org/
      https://pouchdb.com/
      Pemikiran lebih lanjut tentang pengembangan aplikasi local-first sekitar 10 tahun lalu juga bisa dilihat di sini: https://unhosted.org/
    • Selama sekitar sebulan terakhir saya cukup serius memakai instantdb untuk proyek sampingan aplikasi anggaran pribadi
      Saya seharusnya menulis posting blog, tetapi sebelumnya saya sudah meneliti PowerSync, electricSQL, LiveStore, PowerSync, dan juga sempat melihat jazz.tools, namun saya menginginkan sesuatu yang lebih terstruktur
      Sejauh ini cukup mengesankan. Saya sedang menulisnya dengan Vue dan library komunitas; perizinannya agak rumit, tetapi setelah dipahami ternyata sederhana. Saya juga suka login email ajaibnya, dan fitur dashboard/responsnya bagus, tetapi tampaknya perlu beberapa perubahan besar agar tidak terlalu merepotkan
      Saya suka karena ini open source dan bisa self-hosting jika mau. jazz kurang memiliki struktur, dan LiveStore terlihat terlalu merepotkan dengan event store-nya, meski tetap menarik. Sayang alat pengembangannya berada di balik paywall, tetapi bisa dimengerti. electricSQL hanya menyediakan setengah solusi, yaitu baca saja, dan kurang pada model tulisnya. CouchDB/PouchDB juga bagi saya kurang memiliki struktur, dan saya ingin dukungan antardokumen yang lebih jelas tertanam secara bawaan. Zero belum saya teliti dengan benar
    • Saya penasaran apakah Anda tahu situs ini: https://www.localfirst.fm
      Sebenarnya saya ingin menunjuk tautan “landscape” di menu atas, tetapi URL-nya cukup merepotkan
    • Beberapa waktu lalu saya melihat seseorang menyebut Automerge
      https://automerge.org/
      Ada implementasi Rust dan JavaScript, serta menyediakan beberapa strategi jaringan. Tidak disertai susunan produk gratis/berbayar seperti jazz.tools, tetapi cukup bagus
    • Ditto juga layak dilihat
      https://www.ditto.com
      Ini adalah platform local-first yang mendukung sinkronisasi real-time dengan CRDT sebagai inti, sehingga pengelolaan penyelesaian konflik menjadi jauh lebih mudah. Dirancang untuk menangani use case offline-first dan sinkronisasi peer-to-peer secara bawaan, jadi tidak perlu membangun engine sinkronisasi sendiri dari nol
      Mendukung berbagai platform seperti Swift, Kotlin(Android), Flutter/Dart, React Native, JavaScript(Web/Node), .NET(C#), C++, Java, Rust, dan lain-lain. Dokumentasi lebih lanjut bisa dilihat di sini: https://docs.ditto.live/home/about-ditto