Linear Membuat Saya Menjelajahi Lubang Kelinci Local-First

• Linear mengubah secara signifikan sudut pandang saya dalam pengembangan aplikasi web
• Linear bekerja dengan pendekatan local-first yang memberikan reaksi instan dan interaksi tanpa latensi jaringan
• Pendekatan ini membuat klien memiliki database mandiri, dan perubahan disinkronkan secara asinkron ke server
• Namun implementasi pada sinkronisasi lingkungan terdistribusi, resolusi konflik, dan penanganan offline memiliki tingkat kesulitan yang tinggi
• Solusi beragam dari ekosistem local-first seperti Jazz, Electric SQL, dan Zero terus bermunculan, dan pengalaman pengembang juga makin membaik

---

Ringkasan

Saat menggunakan alat manajemen proyek bernama Linear, saya mendapatkan inspirasi besar dari kecepatan dan pengalaman pengguna pola local-first yang luar biasa. Yang paling mengesankan adalah tidak terasa adanya latensi jaringan, status pemuatan, atau refresh halaman seperti yang sering dialami di aplikasi web biasa. Dari pengalaman itu, saya terdorong untuk menyelami lebih dalam prinsip teknis dan kasus penggunaan nyata dari paradigma local-first ini.

Menyelam ke Lubang Kelinci

Saat membedah sisi teknis Linear, saya mengetahui bahwa tim mereka memanfaatkan IndexedDB browser seolah-olah sebagai database sungguhan. Setiap perubahan diproses segera di lokal terlebih dahulu, lalu disinkronkan di latar belakang menggunakan GraphQL dan Websockets.

• Istilah local-first dapat diartikan sebagai strategi UX (respon langsung) atau sebagai falsafah di mana data disimpan di lokal dan disinkronkan
• Pada aplikasi web tradisional, server adalah sumber kebenaran tunggal, tetapi pada arsitektur local-first setiap klien memiliki database sendiri
• Saat lokasi database berpindah ke dekat pengguna, latensi jaringan pada interaksi pengguna menjadi sepenuhnya hilang

Tantangan: Ini Tidak Mudah

Ketika mencoba menerapkan pendekatan yang digunakan Linear secara langsung, saya menyadari bahwa tingkat kompleksitasnya cukup tinggi.

• Transisi offline/online
• Resolusi konflik antar klien terdistribusi
• Sinkronisasi parsial (desain agar tidak perlu mengunduh seluruh data)
• Migrasi skema untuk data cache
• Keamanan dan kontrol akses dalam lingkungan terdistribusi
• Area-area ini memerlukan waktu dan upaya rekayasa insinyur yang besar

Ekosistem Local-First di Tahun 2025

Pada 2025, ekosistem local-first menghadirkan beberapa solusi kuat.

• Electric SQL: mesin sinkronisasi berbasis Postgres
• PowerSync: solusi berorientasi enterprise
• Jazz: alat untuk membangun aplikasi local-first dengan lebih mudah
• Replicache: solusi andalan lama (dihentikan pengembangannya)
• Zero: arah baru dari tim Replicache
• Triplit: sinkronisasi berbasis TripleStore
• Instant: berfokus pada pengalaman pengembang
• LiveStore: menyediakan lapisan sinkronisasi real-time

Pendalaman: Jazz

Jazz menarik perhatian berkat janji uniknya bahwa itu membuat membangun aplikasi local-first semudah memperbarui state.

Model Mental

Jazz memperkenalkan struktur kolaboratif bernama Collaborative Values (CoValues).

• Skema didefinisikan dengan Jazz dan Zod: definisi ini bukan sekadar tipe biasa, melainkan objek hidup yang disinkronkan secara otomatis
• Tanpa perlu jalur API terpisah, logika request/response, atau DTO, cukup ubah keadaan objek dan sinkronisasi terjadi otomatis

Cara Kerja Jazz Mencapai Ini

Struktur internal Jazz adalah sebagai berikut:

• Penjaminan keunikan: setiap data otomatis diberi ID unik
• Event sourcing: riwayat perubahan disimpan sebagai event, sehingga sinkronisasi real-time lebih efisien
• Enkripsi end-to-end: data dienkripsi di klien sebelum sinkronisasi. Server hanya bisa melihat blob terenkripsi
• Desain berbasis grup untuk izin: bukan ACL tradisional, melainkan izin berbasis grup dengan kepemilikan yang jelas dipisahkan

Kompromi

Struktur ini sangat produktif untuk prototipe dan pengembangan UI cepat. Namun ada beberapa hal yang perlu dipertimbangkan.

Server Anda Buta

Karena enkripsi end-to-end, server tidak dapat membaca data pengguna. Jika tidak mendefinisikan dengan jelas data apa yang perlu diakses server sebelumnya, akan ada batasan pada pengawasan atau pencegahan penyimpanan berbahaya.

Perjalanan Waktu Itu Wajib

Dengan event sourcing, semua riwayat perubahan tersimpan secara permanen. Ini membuat fitur Undo/Redo sangat praktis, tetapi menjadi kelemahan saat mempertimbangkan kebutuhan hukum seperti GDPR karena penghapusan menjadi sulit.

Penyimpanan Semakin Membengkak

Karena tidak ada penghapusan yang efektif, penggunaan ruang simpan meningkat seiring waktu. Untuk proyek kecil biasanya masih aman, tetapi pada SaaS berskala besar biaya penyimpanan bisa naik drastis.

Pengembangan Lokal Masih Memiliki Kekhasan

Metode autentikasi berbasis Passkeys menjadi default, dan untuk pengembangan internal/ lokal sering kali merepotkan di tahap awal karena HTTPS, pengelolaan sertifikat, dan migrasi kunci. Namun ada rencana penyempurnaan seperti integrasi Better Auth.

Tapi Jujur? Tetap Layak

Meski ada keterbatasan, pengalaman pengembang dan produktivitasnya sangat mengesankan. Versinya memang masih awal, namun berbagai masalah diproyeksikan akan teratasi seiring waktu.

Menjelajahi: Electric SQL dan Zero

Berbeda dengan Jazz, Electric SQL dan Zero mengambil pendekatan bertahap.

• Masih dapat memanfaatkan tabel Postgres yang ada
• Electric SQL dapat menyinkronkan UI dengan berlangganan reactive query (Shape) untuk sebagian tabel
• Cara menangani mutasi berbeda dari Jazz, dan terdapat berbagai opsi termasuk integrasi LiveStore
• Zero mirip dengan Electric, tetapi memiliki dukungan bawaan untuk sinkronisasi perubahan

Kapan Local-First Masuk Akal?

Mereka merangkum kapan paradigma local-first cocok dan kapan menantang:

Cocok:

• Alat kreatif (desain, menulis, musik, dan sejenisnya)
• Aplikasi kolaboratif
• Aplikasi mobile yang membutuhkan dukungan offline
• Alat pengembang
• Aplikasi produktivitas pribadi

Menantang:

• Logika bisnis skala besar di sisi server
• Kebutuhan audit yang ketat
• Sistem analitik berskala besar
• Sistem yang sangat terintegrasi
• Sistem yang sering menolak permintaan di server

Melihat ke Depan

Local-first menandai pergeseran paradigma dalam pengembangan web. Linear sudah membuktikan manfaat besar dalam pengalaman pengguna. Pengembang harus menilai apakah kompromi struktural ini sesuai dengan proyek mereka.

Melalui pembuatan aplikasi pribadi menggunakan Jazz, saya sedang merasakan langsung kelebihan, kekurangan, dan batasan abstraksi di lapangan. Ekosistemnya masih pada tahap awal, sehingga alat dan pola diperkirakan akan matang dan membaik di masa depan. Namun, manfaat menempatkan data di lokal cukup jelas dan tampaknya tidak akan hilang.

Jika proyek baru Anda bisa menerima batasan-batasan ini, mencoba local-first sudah cukup bernilai. Pada skenario terburuk, Anda mempelajari pola arsitektur baru; pada skenario terbaik, Anda dapat menghadirkan pengalaman pengguna yang terasa super cepat hingga titik yang hampir mustahil dicapai sebelumnya. Dalam kompetisi respons 300ms, ini menjadi keuntungan yang signifikan.

[GN⁺]

Komentar Hacker News

• Zero juga menyediakan fitur yang mirip dengan Electric dan mendukung pemrosesan mutasi secara langsung Kunci diferensiasi utama Zero adalah sinkronisasi berbasis query Aplikasi dapat dirancang per query, dan tanpa harus memutuskan atau mengonfigurasi sebelumnya apa yang akan disinkronkan, menjalankan query saja sudah cukup untuk mensinkronkan data secukupnya Jika data yang dibutuhkan klien belum ada, query otomatis dialihkan ke server dan setelah disinkronkan data itu langsung bisa dipakai pada query berikutnya Pendekatan ini sangat praktis

  • Cocok untuk aplikasi segala skala (tidak selalu mungkin menyinkronkan semua data ke klien)
  • Bagus untuk membangun layar awal dengan cepat (loading halaman publik lebih cepat)
  • Penanganan akses pun bisa diselesaikan lewat query tanpa sistem terpisah Jadi pengalaman memakai Zero terasa dekat dengan database yang reaktif seperti Convex atau RethinkDB Namun karena memakai Postgres standar, kita juga bisa menikmati reaktivitas instan dari mesin sinkronisasi

• Aku lebih memilih SSR Menurutku, klien seharusnya hanya menyimpan state berupa token sesi, URL saat ini, dan DOM Jaringan dan server terus dipercepat Kecepatan cahaya itu tetap, tapi kita belum memanfaatkannya secara penuh Akan ada teknologi seperti hollow core fiber yang bisa menurunkan latency internet secara keseluruhan hingga 30% Bahkan jika RTT-nya 500ms, halaman yang dirender dengan SSR dalam 16ms akan terasa jauh lebih instan daripada sebagian besar situs web online saat ini Menurutku, tidak masuk akal jika server merender respons HTML lebih lama dari frame 60Hz Dalam rentang waktu itu, core Zen5 bisa melakukan serialisasi 30~40MB JSON Dari sudut server, itu hanya string UTF-8 yang “cantik” Aspek ini seharusnya diukur dalam microseconds, bukan milliseconds Latency transmisi yang tinggi bukan alasan untuk membuat waktu CPU dipakai secara malas Aku keluar dari “millisecond jail” dengan menggunakan SQLite Layanan SQL hosting menjadi penghalang saat mengejar latency di bawah 1ms Standar browser juga dapat menyelesaikan sebagian masalah latency navigasi Lihat Speculation Rules API

  • Bahwa jaringan dan server makin cepat bukanlah justifikasi universal untuk SSR Ini mengacu pada kasus-kasus pengecualian seperti server tertentu dengan daya komputasi lebih besar, atau ketika pemisahan logika sulit dilakukan sehingga SSR diperlukan Faktanya sering kali rendering di client lebih cepat Banyak kasus di mana logika rendering jauh lebih kompleks dibanding ukuran data, dan jika dijumlahkan, seluruh sumber daya klien bisa lebih besar dari server Kalau SSR satu-satunya opsi, antusiasme saat ini terhadap Web Assembly jadi sulit dijelaskan Ada juga artikel tentang local computation yang layak dibaca Pada akhirnya, kita tidak bisa tahu sebelumnya mana yang lebih baik, jadi harus bisa memilih saat request datang

  • Right Tool For The Right Job! Misalnya, apakah mungkin mengerjakan dokumen kolaboratif seperti Google Docs dan Sheets hanya dengan SSR? Jika tetap memaksakan SSR, pengguna akan tetap berada di situasi di mana orang lain bisa mengubah konten saat mereka sedang mengedit Tool ini bekerja baik karena dampak perubahannya kecil, dan karena pengguna langsung sadar sedang berkolaborasi lalu menerima pembaruan real-time Sebaliknya, layanan seperti reservasi hotel tidak memerlukan sinkronisasi real-time Selain itu, sinkronisasi yang goyah dan aplikasi enterprise yang kurang matang desain awalnya biasanya sulit menjaga konsistensi saat domain serta kompleksitas sistem berkembang

  • Jika aku bisa dengan mudah menambahkan library seperti ini ke aplikasi SSR yang sudah ada, aku akan menggunakannya:

    • ukuran 50kb (gzipped)
    • tidak perlu perubahan kode, baik sekarang maupun di masa depan
    • mendukung sinkronisasi otomatis tanpa menurunkan UX di kondisi offline/low bandwidth Kalau ada, aku akan langsung memakai Masalah yang diabaikan para pendukung SSR adalah asumsi bahwa pengalaman offline/low bandwidth harus dikorbankan demi kenyamanan developer dan UX yang baik Bahkan, mereka menjadikan prediksi perbaikan jaringan di masa depan sebagai pembenaran Kenyataannya, kebutuhan low bandwidth memang selalu menjadi keunggulan penting Aku pikir ini makin terasa di wilayah dengan internet lambat, daerah terpencil, atau lingkungan seperti Comcast

  • Ini benar-benar engineering jalur happy path Bagi yang tak berada di jalur happy path, ini cukup mematahkan semangat

  • Peran utama SSR saat ini dan ke depannya adalah loading halaman pertama, terutama di mobile Sesudahnya, yang dibutuhkan cuma update status di klien, jadi semuanya harus makin cepat Jika kemampuan engineering kurang, SSR pun tidak banyak berarti

• Aku mengembangkan perangkat lunak manajemen tugas open source berbasis arsitektur local-first berbasis CRDT Motivasiku karena tidak membutuhkan fitur kolaborasi, dan tools seperti Linear terlalu kompleks untuk kebutuhanku Kelebihan arsitektur ini:

  1. Menyimpan data secara lokal membuat respons sangat cepat
  2. Mengekspor/ mengimpor seluruh database sangat mudah
  3. Logika server diringankan sehingga overhead kinerja dan kompleksitas pengembangan rendah, dan seluruh logika bisnis diimplementasikan di klien
  4. Pengembangan fitur jadi lebih sederhana (cukup menulis logika lokal) Kekurangannya juga ada:
  5. Cocok untuk data teks saja, untuk gambar atau file besar sebaiknya gunakan object storage atau layanan lain
  6. Kode sinkronisasi harus ditulis dengan sangat berhati-hati saat pengembangan (bug dapat menimbulkan masalah besar)
  7. E2E encryption dan fitur kolaborasi relatif kompleks Susunan teknisnya:
  8. Berbasis pustaka CRDT open source Loro, sehingga aku bisa fokus hanya pada logika bisnis
  9. Alur pemrosesan data: Interaksi pengguna memperbarui model CRDT, mengekspor status itu ke JSON untuk memperbarui UI Sambil menyimpan data itu ke DB lokal dan menyinkronkan dengan server
  10. Layer penyimpanan lokal diabstraksi menjadi tiga antarmuka umum: list/save/read, dengan platform masing-masing memakai IndexedDB (browser), filesystem (Electron), dan Capacitor Filesystem (iOS/Android)
  11. Implementasi enkripsi E2E dan sinkronisasi inkremental Berdasarkan selisih versi server dan klien, lalu dienkripsi dengan AES sebelum diunggah Server menyimpan base version + patch inkremental Jika akumulasi patch membesar, enkripsi seluruh DB dan unggah sebagai base version baru agar patch berikutnya tetap ringan Jika tertarik pada proyek ini, lihat repo Hamsterbase Tasks

• Jazz meninggalkan kesan yang sangat kuat padaku DX-nya sangat baik karena membuat coding menjadi nyaris sinkron dan imperatif, jadi menyenangkan Semuanya terasa instan, dan juga memungkinkan kerja offline sehingga UX-nya bagus Masalah utamanya adalah deployment dan maintainability jangka panjang karena data makin membesar (kebanyakan klien tidak perlu melihat semuanya, jadi tidak aku khawatirkan terlalu banyak) Isu utamanya adalah masih kurang solusi bagus untuk public index yang sering berubah Secara teoritis, public readable list of ids itu memungkinkan, tapi kemarin aku berdiskusi dengan Anselm dan katanya ini sedang dalam proses penyelesaian Secara umum, local-first pun tetap punya biayanya, tapi jika Jazz menyelesaikan kelemahan utama pendekatan server terpusat tradisional, aku pikir ia bisa menggantikan Firestore di hampir semua aspek

  • Aku merasa Jazz benar-benar keren DX-nya juga sangat menonjol Saat aku memakainya, dukungan untuk enkripsi berbasis passkey berjalan baik, sehingga di Windows tidak berjalan dengan baik dan praktis tidak bisa dipakai Aku pikir autentikasi tradisional akan segera didukung Yang paling penting, enkripsi E2E-nya sangat baik dan pengalaman penggunaannya sangat menyenangkan

• ElectricSQL dan TanStack DB keduanya luar biasa, tapi aku penasaran kenapa begitu fokus pada local-first di web Di mobile, karena kebutuhan offline, local-first menurutku justru lebih dibutuhkan Pada penggunaan browser web, internet pada akhirnya kebanyakan tetap terhubung Selain itu, teknologi local-first ini secara teori terlihat meyakinkan, tetapi mudah runtuh jika penyelesaian konflik tidak mengikuti Pengalaman saat membuat aplikasi local-first untuk mobile membuatku menyimpulkan untuk memakai CRDT

  • Membangun aplikasi local-first dengan teknologi web dibanding native jauh lebih sulit Aplikasi native langsung bisa offline begitu terpasang Di web, dukungan offline hanya bisa ditempelkan lewat trik seperti AppManifest, ServiceWorker, dan lain-lain Di native, dengan C code 30 tahun, membaca dan menulis file ke disk itu sudah semuanya Di web, IndexedDB benar-benar mimpi buruk, localStorage tidak bisa dipakai jika skalanya besar, dan OriginPrivateFileSystem juga terbatas Jika pengguna tidak mengunjungi situs selama sebulan pun, Safari menghapus state browser lokal Meski mencoba dengan JavaScript atau build wasm via Emscripten, tetap harus mengolah async web API dengan berbagai cara Apple telah menyediakan solusi local+sync yang matang sejak 2015 lewat kombinasi CoreData + CloudKit Dari sisi Google, Firebase mungkin paling mirip

  • Sebagai pengembang Replicache dan Zero, aku sudah banyak mempertanyakan kenapa fokusnya di web Aku belum tahu jawabannya, tapi begini pendapatku:

    • Keunggulan web: loop feedback cepat, tanpa gatekeeper, dan secara keseluruhan aku merasa web lebih baik
    • Aplikasi desktop/prod produktivitas sebagian besar berjalan di web, dan aku ingin interaktivitas instan pada aplikasi produktivitas Namun semuanya beralih ke arsitektur client-server, jadi latency terasa di berbagai titik; aku ingin mengubahnya
    • Sistem seperti ini membutuhkan logika database terdistribusi kelas berat di sisi klien Pemilihan bahasa pun jadi rumit Secara teori kita bisa porting C++ atau Rust ke wasm, tapi kenyataannya JS paling serbaguna dan paling mudah diakses di web dan mobile (RN, dll)
    • Nyatanya, aplikasi produktivitas yang kompleks membuat sistem klien menjadi kompleks, sehingga mayoritas memakai teknologi web dan diimplementasikan dengan satu bahasa (JS)

  • Fitur offline di mobile secara native jauh lebih kuat daripada web Tapi justru banyak produktivitas/kolaborasi terjadi di web, dan web adalah lingkungan yang lebih menantang Ada isu rumit seperti sinkronisasi lintas tab dan penghapusan storage Jadi local-first berkembang terutama berpusat di web

  • Sync engine menargetkan web dulu karena teknologinya masih muda dan banyak update Update aplikasi mobile memang menyakitkan, tetapi update web app lebih mudah Aku juga merasa kapabilitas PWA sekarang sudah bagus PWA iOS pun sudah support push notification, dan buatku web app yang tampil seperti aplikasi mobile sudah cukup

  • Di sini poinnya bukan “fitur apa yang bisa dipakai”, tapi “kenikmatan” saat memakai produk yang super cepat dan responsif Karena itu aku tetap mengarah ke local-first

• Aspek kolaborasi pada local-first/sync engine terasa sangat kurang dibahas Aku sedang membangun proyek pengganti Google Sheets bisnis teman dengan Zero Kami berada di Google Meet, membuka sheet secara real-time dan mengolah data bersama Aku sebelumnya tidak pernah membayangkan pengalaman ini bisa diwujudkan sebagai web app Aku sudah sering membuat UI real-time dengan WebSocket, tapi menyisipkan data masuk ke posisi yang tepat dan mengelolanya dengan benar itu sangat kompleks Kalau sel data ratusan atau ribuan, kebingungannya sulit dibayangkan Dengan Zero, cukup pilih data lewat query, ubah lewat mutator, dan semuanya tersinkronisasi langsung untuk semua orang Jadi pengembangannya terasa benar-benar menyenangkan

• Saat Google Docs pertama kali diluncurkan (aku masih 12 tahun), aku melihat sinkronisasi real-time dan kursor kolaboratif masuk, lalu merasa, “Pengalaman web ke depan pasti akan serba kolaboratif” Saat itu cloud computing lagi jadi istilah populer, dan walaupun aku salah, aku juga percaya kolaborasi real-time adalah definisi dari cloud computing Namun pada akhirnya masa depan itu tak terwujud Sudah 20 tahun berlalu, tapi kebanyakan produk web tetap memberikan pengalaman CRUD (situs ini juga begitu) Aku terus merasa inovasi akan segera datang: berharap Meteor.js, React, dan sebagainya, tapi itu belum jadi default Aku masih berharap ini benar-benar menjadi arus utama, dan suatu hari akan benar-benar terjadi Tapi ternyata ini lebih sulit, karena tooling-nya tidak semurah yang kukira untuk dipakai di semua kasus

  • Contoh kolaborasi real-time antara lain Discord (yang pada dasarnya tidak beda jauh dari IRC 90-an), Zoom (semua konferensi video), dan lain-lain Menjadi aplikasi CRUD, seperti HN, adalah kelebihannya Pembaruan real-time justru bisa membuat sibuk dan mengganggu, jadi aku tak menginginkannya

  • Kecepatan cahaya memang jadi batas nyatanya Cahaya butuh 56ms untuk memutar setengah bumi, sinyal nyata lebih berkelok, lewat konversi, plus hambatan tambahan (load balancer, perlindungan DDOS, dll), sehingga makin lambat Latency kadang memang lebih buruk dibanding dulu

  • Aku juga pernah merasakan keajaiban awal real-time ini, tapi masa depannya terasa masih tersisa di suatu tempat Meski begitu, aku tetap sedang membuat alat messaging real-time bergaya Google Docs sejati (tanpa input box dan tombol kirim): kraa.io/hackernews

• Aku percaya pada masa depan local-first dan sync-engine Tabel landscape framework local-first yang sangat membantu Secara pribadi Triplit.dev terasa paling baik, dan ini juga dapat digabungkan dengan TanStack DB PowerSync dan NextGraph juga opsi yang ingin aku pelajari Aku juga lagi menonton presentasi terkait NextGraph di video LocalFirst Conf yang seru: video YouTube

  • Aku penasaran bagaimana dukungan migrasi database pada tools-tool ini Jika mendukung klien tanpa akses server untuk waktu lama, roll-forward migration dari skema yang sangat lama tampak seperti hambatan besar Menyelesaikan bug frontend pengguna tunggal saja sudah susah, apalagi jika harus mempertimbangkan status skema, kompleksitasnya lebih dari bayangan

  • Mengingatkan pada Meteor

  • Pendekatan ini juga semacam cara lama di masa lalu

  • Aku harus sekali mencoba Triplit, penasaran juga apakah kamu sudah pernah coba InstantDB Aku tertarik juga, tapi belum sempat mencobanya

• Aku cukup menyukai pendekatan Electric dan sudah lama mengamati Pendekatan Electric justru bersih karena menyerahkan kompleksitas penulisan kepada developer dan API Solusi sinkronisasi dua arah umumnya hanya berfungsi baik pada aplikasi Todo yang sederhana Ketika otorisasi, evolusi logika bisnis, migrasi, dan pertumbuhan produk masuk, timbul keraguan pada ketahanannya Electric hanya mendukung sinkronisasi read lewat view, sedangkan write tetap ditangani oleh API/REST/RPC yang sudah ada, jadi lebih mudah diadopsi ke proyek yang sudah berjalan

• Aku penasaran kenapa couchdb / pouchdb tidak ada di daftar Ini tetap menjadi alat yang cukup baik

  • Menyebut “berjalan baik” saja sudah meremehkan Kebanyakan solusi local-first akhirnya akan kehilangan data dalam kondisi konflik Berbeda dengan itu, couchdb/pouchdb memberi otoritas akhir pada developer dalam penyelesaian konflik Orang-orang di kubu CRDT tampaknya lebih mengutamakan kenyamanan developer daripada keamanan data Ini adalah trade-off yang bisa dipilih tiap orang sesuai preferensi dan tujuan Tapi aku masih sulit memahami mengapa topik keamanan data seperti ini tidak sering disinggung