- Lapisan data manajemen state yang dirancang agar pengembangan aplikasi berperforma tinggi dapat dilakukan tanpa beban mengembangkan logika sinkronisasi
- Ditandai dengan penggunaan SQLite yang reaktif dan mesin sinkronisasi bawaan
- Local-first sehingga tetap memberikan performa tinggi saat offline, serta mendukung sinkronisasi otomatis ketika jaringan pulih
- Semua operasi manajemen state dijalankan dengan cepat di atas database SQLite lokal
- Aliran data reaktif: saat data berubah, event langsung dipicu ke listener yang terhubung ke UI sehingga perubahan state dapat tercermin secara real-time
- Dapat diterapkan di berbagai lingkungan (web, mobile, desktop, dll.)
- Dibandingkan alat manajemen state yang sudah ada, memberikan hasil yang lebih unggul dalam performa native dan konsistensi data
2 komentar
Demo di halaman utama situsnya benar-benar dibuat dengan sangat baik. Setelah beberapa kali mengklik Demo, jadi terasa ingin mencobanya.
Komentar Hacker News
Halo, saya co-founder LiveStore (sebelumnya membuat Prisma).
Selama 4 tahun terakhir, saat membangun klien musik berperforma tinggi setara native bernama Overtone, saya akhirnya mengembangkan LiveStore untuk dipakai sendiri.
LiveStore menambahkan lapisan sinyal reaktif ke SQLite, lalu menggabungkannya dengan sinkronisasi berbasis event sourcing (mirip Git)
Saya sudah mengevaluasi berbagai pendekatan local-first, dan hampir tidak ada solusi yang menyelesaikannya serapi LiveStore
Alat lain yang tingkat kematangannya mirip mungkin tinyBase, tetapi strukturnya berbeda (CRDT vs event sourcing)
Saya penasaran, kenapa kapasitas data dibatasi sampai 1GB, dan apakah mungkin ada opsi untuk menyimpan data yang lebih besar di SQLite dan mempertahankannya di disk
Mungkin mode persistence cukup bisa diubah hanya lewat konfigurasi?
Multitenancy juga tampak seperti skenario yang menarik, misalnya seperti JIRA saat tiap organisasi membutuhkan namespace terpisah, dan akan bagus kalau tiap pengguna tidak menerima seluruh tiket, melainkan hanya tim/divisinya sendiri
Pada dasarnya struktur ini membuat database lokal menjadi subset dari keseluruhan data. Akan sangat keren kalau ada server sinkronisasi yang langsung bisa dijalankan di Bun/Node (tanpa perlu Cloudflare) tersedia out of the box
Sepertinya ini juga cocok untuk ide proyek yang sedang saya evaluasi saat ini, terutama karena multitenancy adalah kebutuhan wajib
Bulan lalu saya sempat cek LiveStore untuk dipakai di proyek hobi, tetapi karena masih beta preview jadi sulit diakses
Semoga saya bisa meninjaunya lebih dalam segera. Kesan saya, kalian sangat aktif mendorong diskusi soal local-first
Siapa pun yang pernah membuat web app dengan sinkronisasi offline akan langsung paham betapa bergunanya engine sinkronisasi
Presentasinya di Local-First Conf hari ini benar-benar bagus
Penjelasan tentang struktur menerapkan event sourcing dengan SQLite sangat jelas dan meyakinkan
Terima kasih sudah aktif mempromosikan SQLite, terutama OPFS Wasm SQLite, di web
PowerSync juga sangat mendukung SQLite, jadi menyenangkan melihat kisah sukses seperti LiveStore
Saat LiveStore menskalakan model event sourcing secara global, biasanya sinkronisasinya dilakukan lewat backend sinkronisasi terpusat untuk semua klien. Saya penasaran apakah itu memang syarat wajib
Apakah mungkin juga mendukung node federasi atau mode P2P sepenuhnya? Saya juga sedang mempertimbangkan penerapannya untuk kasus SNS terdistribusi
Saya penasaran apakah LiveStore, jika dipadukan dengan React dan WASM, bisa menggantikan framework Juce yang dipakai kebanyakan aplikasi musik
Saya seorang beatmaker, dan kombinasi Juce dengan C++ selalu terasa sulit dan menakutkan. Saya ingin tahu apakah LiveStore bisa menjadi alternatif yang baik bagi orang yang ingin masuk ke pengembangan aplikasi musik
Saya melihat presentasinya di Local-first Conf, dan belakangan ini memang banyak sekali engine sinkronisasi bermunculan
LiveStore sedang menggali dengan serius area menarik yang menggabungkan event sourcing dan engine sinkronisasi
Saya terkejut karena sistem ini sudah menjadi sistem yang kokoh secepat ini
Dalam beberapa minggu terakhir saya memakainya langsung untuk proyek baru, dan benar-benar berjalan mulus
Selamat atas peluncurannya! Saya penasaran apakah sistem ini cocok dengan strategi "1. Serialization" yang dijelaskan di sini
Seperti yang disebutkan di ProseMirror-collab, saya ingin tahu apakah di LiveStore juga bisa muncul masalah ketika klien berlatensi rendah yang sering mengirim update menghambat update dari klien berlatensi tinggi
Sepertinya LiveStore menggunakan wa-sqlite
Saya ingin mendengar lebih detail tentang strategi persistensi data offline, khususnya apakah menggunakan OPFS (varian seperti AccessHandlePoolVFS) atau IndexedDB, atau keduanya
Saya juga penasaran bagaimana kalian menangani ketidakstabilan OPFS antar-browser dan kebijakan penyimpanan 7 hari IndexedDB di Safari
Saya juga ingin tahu kenapa memilih wa-sqlite padahal SQLite menyediakan build WASM resmi
Saya sempat memperkenalkan LiveStore secara singkat di podcast LocalFirst.fm baru-baru ini (lihat tautan https://www.localfirst.fm/24)
Ini terlihat seperti proyek yang sangat menjanjikan, tetapi saya juga sedikit berhati-hati jangan sampai terjebak dalam ekspektasi berlebihan (hype trap)
Saya juga sedang bereksperimen membangun aplikasi local-first serupa secara kustom dengan dukungan multi-device
Saya penasaran apakah mungkin menambahkan enkripsi E2E secara opsional. Dari dokumentasinya terlihat bahwa enkripsi bisa ditambahkan di level payload event, dan sepertinya hampir memungkinkan kecuali kompresi log di server menjadi lebih sulit
Saya membangun LiveStore sendiri berdasarkan kebutuhan yang muncul saat mengerjakan Overtone
LiveStore maupun Overtone sama-sama dibuat dengan tujuan keberlanjutan jangka panjang. Enkripsi E2E adalah sesuatu yang sudah memungkinkan dalam strukturnya
Saya sendiri belum mencobanya, tetapi saya dengan senang hati akan membantu jika ada kendala
Mungkin salah satu cara adalah mencoba compaction log hanya di sisi klien. Saat melakukan engineering, saya pasti akan tetap mengingat use case ini
Saya skeptis dengan klaim dukungan lintas platform, karena hal pertama yang saya lihat justru web tidak didukung di Android
Perkembangannya bisa dilihat di GitHub resmi (https://github.com/livestorejs/livestore/issues/321)
Harap dimaklumi bahwa dukungan web API berbeda-beda di tiap platform, jadi membangun sistem ambisius seperti ini memang membutuhkan sangat banyak usaha dan waktu
Ada satu hal menarik dari video demo! Di menit 1:07 ada gejala audio condong ke kiri. Memang sepele, tapi saya rasa layak diberi tahu
Menarik melihat kalian juga menyediakan developer tools, sepertinya ini sudah cukup lama diuji di proyek internal sendiri
Saya penasaran bagaimana rencananya menangani compaction pada aplikasi/halaman yang berjalan jangka panjang, dan walaupun event sourcing adalah konsep yang keren, seiring lapisan aplikasi berkembang, pengelolaan kode (klien versi lama, migrasi skema, dan sebagainya) bisa menjadi sulit
Sepertinya Overtone mendukung banyak sumber. Saya penasaran apakah akan ada pemutaran offline, terutama karena UI Spotify terasa tidak nyaman dan saya sangat ingin ada alternatif
Ide utamanya adalah memberi tiap event lebih banyak informasi semantik agar bisa mendefinisikan tumpang tindih antar-event
Misalnya, di aplikasi todo, event "todoCompleted" untuk ID tugas yang sama bisa mengompaksi event "todoCompleted"/"todoUncompleted" lain untuk tugas tersebut
Perkembangannya bisa dilihat di GitHub (https://github.com/livestorejs/livestore/issues/254)
Event sourcing memang sangat bergantung pada disiplin dan desain. Dalam data tidak ada "makan siang gratis", jadi yang terpenting adalah trade-off
Untuk penggunaan utama saya seperti Overtone, saya merasa trade-off event sourcing lebih menguntungkan
Untuk dukungan versi lama dan sebagainya, ada beberapa cara sederhana yang bisa dipakai; pada akhirnya itu bergantung pada karakteristik dan trade-off masing-masing aplikasi
Terima kasih sudah tertarik pada Overtone. Saya juga memulai proyek ini karena frustrasi terhadap Spotify. Untuk pemutaran offline, itu bergantung pada penyedia sumber audio
Misalnya album milik sendiri dari Dropbox bisa didukung, tetapi layanan streaming seperti Spotify bisa berbeda tergantung kebijakan mereka
Saya suka arsitektur ini, terutama event sourcing-nya
Tetapi event sourcing memang perlu kehati-hatian. Bergantung pada view yang diinginkan, materialisasi (view materialization) bisa lambat, dan akan makin lambat saat data membesar
Solusinya adalah pembaruan materialisasi perlu dikelola langsung di dalam transaksi, misalnya dengan trigger
Hal ini juga perlu dipertimbangkan saat replikasi atau sinkronisasi, dan untuk penyelesaian konflik, konsep CRDT juga tetap perlu dipahami
Akan sangat bagus kalau ada database mirip SQLite3 dengan fitur bahasa Postgres, sehingga local-first dan remote-first bisa dipakai hanya dengan mengganti konfigurasi
Soal biaya materialisasi, compaction akan terus kami tingkatkan ke depan, dan seluruh LiveStore adalah framework yang dirancang dengan sangat hati-hati dengan tujuan optimisasi performa