- sync logic development का बोझ लिए बिना, high-performance application development को संभव बनाने के लिए डिज़ाइन की गई state management data layer
- reactive SQLite और built-in sync engine का उपयोग इसकी मुख्य विशेषता है
- Local-first होने के कारण यह offline में भी high performance देता है, और network बहाल होने पर automatic sync को support करता है
- सभी state management operations स्थानीय SQLite database पर तेज़ी से किए जाते हैं
- reactive data stream: data बदलते ही UI से जुड़े listeners को तुरंत event मिलता है, जिससे state changes को real time में reflect किया जा सकता है
- इसे web, mobile, desktop आदि जैसे विभिन्न environments में लागू किया जा सकता है
- मौजूदा state management tools की तुलना में, native performance और data consistency में बेहतर परिणाम देता है
2 टिप्पणियां
होमपेज के मेन पर जो Demo है, वह सच में बहुत बढ़िया बनाया गया है। Demo पर थोड़ा क्लिक करते-करते ही इसे आज़माने का मन होने लगता है।
Hacker News राय
नमस्ते, मैं LiveStore का cofounder हूँ (पहले Prisma बनाया था)।
पिछले 4 सालों से Overtone नाम का native-grade high-performance music client बनाते हुए, अपने ही उपयोग के लिए LiveStore विकसित किया।
LiveStore, SQLite में reactive signal layer जोड़ता है और उसे event-sourcing based sync (Git जैसा) के साथ जोड़ता है
मैंने local-first ecosystem में काफ़ी विकल्पों का आकलन किया है, लेकिन LiveStore जितना साफ़-सुथरा समाधान बहुत कम दिखा
tinyBase भी कुछ हद तक समान रूप से mature tool है, लेकिन उसका architecture अलग है (CRDTs vs event sourcing)
एक सवाल है: data size को 1GB तक सीमित क्यों रखा गया है, और क्या बड़े data को SQLite में store करके disk पर बनाए रखने का option दिया जा सकता है?
क्या केवल configuration से persistence mode बदला नहीं जा सकता?
multi-tenancy भी एक दिलचस्प scenario हो सकता है। JIRA की तरह अगर हर organization को अलग namespace चाहिए, और हर user को सारे tickets के बजाय सिर्फ़ अपनी team/department का data मिले, तो यह उपयोगी होगा।
मूल रूप से local database पूरे data का subset होगा। अगर Bun/Node पर सीधे चलने वाला sync server (Cloudflare की ज़रूरत बिना) साथ में मिले, तो वह शानदार होगा।
यह उस project idea के लिए भी काफ़ी उपयुक्त लगता है जिसे मैं अभी देख रहा हूँ, खासकर क्योंकि उसमें multi-tenancy अनिवार्य है।
पिछले महीने मैं LiveStore को एक hobby project में आज़माना चाहता था, लेकिन beta preview होने की वजह से access आसान नहीं था।
उम्मीद है कि जल्द इसे और गहराई से देख पाऊँगा। local-first पर चर्चा को सक्रिय रूप से आगे बढ़ाने का आपका तरीका प्रभावशाली है।
जिसने भी offline sync वाला web app बनाया है, वह sync engine की उपयोगिता तुरंत समझ जाएगा।
आज Local-First Conf में आपका talk बहुत अच्छा लगा।
SQLite के साथ event sourcing लागू करने वाली संरचना की व्याख्या साफ़ और विश्वसनीय थी।
वेब पर SQLite, खासकर OPFS Wasm SQLite, को सक्रिय रूप से बढ़ावा देने के लिए धन्यवाद।
PowerSync भी SQLite का मज़बूत समर्थक है, इसलिए LiveStore जैसी सफलता की कहानी देखकर अच्छा लगा।
जब LiveStore event sourcing model को global scale पर बढ़ाता है, तब आम तौर पर सभी clients के लिए central sync backend के ज़रिए sync किया जाता है। क्या यह अनिवार्य requirement है?
क्या federated nodes या पूरी तरह P2P mode भी संभव है? मैं distributed social network जैसे use case पर भी विचार कर रहा हूँ।
React और WASM के साथ मिलकर क्या LiveStore, ज़्यादातर music apps में इस्तेमाल होने वाले Juce framework का विकल्प बन सकता है?
मैं एक beatmaker हूँ, और Juce + C++ का संयोजन हमेशा कठिन और डराने वाला लगा है। music app development में प्रवेश करने वालों के लिए क्या LiveStore अच्छा alternative हो सकता है?
मैंने Local-first Conf में यह प्रस्तुति देखी, और आजकल सच में कई तरह के sync engine सामने आ रहे हैं।
LiveStore, event sourcing और sync engine के संयोजन वाले एक दिलचस्प क्षेत्र में गहराई से काम कर रहा है।
यह देखकर हैरानी हुई कि यह पहले से इतना robust system बन चुका है।
पिछले कुछ हफ़्तों में मैंने इसे एक नए project में खुद इस्तेमाल किया है, और यह सच में smoothly काम कर रहा है।
लॉन्च के लिए बधाई! मैं जानना चाहता हूँ कि क्या यह system यहाँ बताई गई "1. Serialization" strategy में फिट बैठता है।
ProseMirror-collab में जैसा बताया गया है, क्या बार-बार update करने वाले low-latency clients, high-latency clients के updates को रोकने वाली समस्या LiveStore में भी पैदा कर सकते हैं?
लगता है LiveStore wa-sqlite का उपयोग करता है।
मैं offline data persistence strategy के बारे में विस्तार से सुनना चाहूँगा। खास तौर पर, क्या यह OPFS (जैसे AccessHandlePoolVFS variants) का उपयोग करता है, या IndexedDB का, या दोनों का?
साथ ही, OPFS की browsers के बीच instability और Safari IndexedDB की 7-दिन retention policy को आप कैसे handle कर रहे हैं?
और जबकि SQLite खुद official WASM build देता है, तब wa-sqlite चुनने का कोई खास कारण था क्या?
हाल ही में LocalFirst.fm podcast में LiveStore का संक्षिप्त परिचय दिया था (https://www.localfirst.fm/24 लिंक देखें)।
यह बहुत रोमांचक project लगता है, लेकिन थोड़ा डर भी है कि कहीं यह hype trap में न फँस जाए।
मैं भी इसी तरह एक custom local-first app बनाकर multi-device support के साथ प्रयोग कर रहा हूँ।
क्या इसमें वैकल्पिक रूप से E2E encryption जोड़ना संभव होगा? docs देखकर लगता है कि event payload स्तर पर encryption जोड़ी जा सकती है; server-side log compaction मुश्किल हो जाएगा, बस यही एक बाधा दिखती है।
Overtone पर काम करते हुए जो ज़रूरतें सामने आईं, उन्हीं के आधार पर मैं LiveStore खुद बना रहा हूँ।
LiveStore/Overtone, दोनों को long-term sustainability को ध्यान में रखकर बनाया जा रहा है। E2E encryption के लिए संरचना पहले से सक्षम है।
मैंने खुद इसे लागू नहीं किया है, लेकिन अगर कोई समस्या आए तो मदद करने में खुशी होगी।
सिर्फ़ client side पर log compaction आज़माना भी एक तरीका हो सकता है। engineering के दौरान मैं इस use case को ज़रूर ध्यान में रखूँगा।
cross-platform support के दावे को लेकर मैं skeptical हूँ, क्योंकि सबसे पहले जो दिखा वह Android web का unsupported होना था।
प्रगति आधिकारिक GitHub पर देखी जा सकती है (https://github.com/livestorejs/livestore/issues/321)।
अलग-अलग platforms पर web API support अलग होता है, इसलिए ऐसा ambitious system बनाने में बहुत ज़्यादा मेहनत और समय लगता है—उम्मीद है इसे समझा जाएगा।
demo video में एक दिलचस्प बात! 1 मिनट 7 सेकंड पर audio left channel की तरफ़ झुका हुआ लगा। छोटी बात है, लेकिन reference के लिए बता रहा हूँ।
developer tools साथ देना प्रभावशाली है; लगता है इसे काफ़ी समय तक internal projects में test किया गया है।
मेरा सवाल है कि long-running apps/pages में compaction को आप लंबे समय में कैसे handle करने वाले हैं, और event sourcing भले ही शानदार concept हो, लेकिन जैसे-जैसे application layer evolve होती है, code management (पुराने clients, schema migration आदि) मुश्किल हो सकता है।
लगता है Overtone कई sources को support करता है; क्या इसमें offline playback भी होगा? खासकर इसलिए पूछ रहा हूँ क्योंकि Spotify UI से मैं परेशान हूँ और एक विकल्प की सख़्त ज़रूरत है।
मुख्य विचार यह है कि हर event को और अधिक semantic information दी जाए ताकि events के बीच overlap को परिभाषित किया जा सके।
उदाहरण के लिए, एक todo app में किसी एक task ID के लिए "todoCompleted" event, उसी task के "todoCompleted"/"todoUncompleted" events को compact कर सकता है।
प्रगति GitHub पर देखी जा सकती है (https://github.com/livestorejs/livestore/issues/254)।
event sourcing में सचमुच discipline और design महत्वपूर्ण हैं। data के मामले में कोई “free lunch” नहीं होता, इसलिए trade-offs ही असली बात हैं।
Overtone जैसे मेरे मुख्य use cases में event sourcing के trade-offs मुझे बेहतर लगते हैं।
पुराने versions के support वगैरह के लिए कई सरल तरीके मौजूद हैं; अंततः यह हर application की प्रकृति और trade-offs पर निर्भर करता है।
Overtone में रुचि दिखाने के लिए धन्यवाद। मैंने भी यह project Spotify से असंतोष के कारण शुरू किया था। offline playback, music source provider पर निर्भर करेगा।
उदाहरण के लिए Dropbox जैसी जगहों पर आपकी अपनी album collection support की जा सकती है, लेकिन Spotify जैसी streaming services में यह policy पर निर्भर करेगा।
मुझे यह architecture पसंद आया, खासकर event sourcing।
लेकिन event sourcing में सावधानी ज़रूरी है। मनचाहा view पाने के लिए materialization धीमी हो सकती है, और data बढ़ने के साथ यह और धीमी होती जाती है।
इसका समाधान यह है कि triggers वगैरह के ज़रिए transaction के भीतर materialized state update को खुद manage किया जाए।
replication या sync करते समय भी इसे ध्यान में रखना पड़ता है, और conflict resolution के लिए CRDT concepts को समझना भी ज़रूरी है।
अगर Postgres language features वाला SQLite3 जैसा database हो, तो local-first और remote-first को सिर्फ़ configuration बदलकर उपयोग करना वास्तव में बहुत अच्छा होगा।
और materialization cost वाली मुख्य बात पर, compaction को आगे और बेहतर किया जाएगा, और LiveStore पूरा का पूरा performance optimization को ध्यान में रखकर बहुत सावधानी से design किया गया framework है।