Local-first apps अभी तक मुख्यधारा में क्यों नहीं बन पाए?

• Local-first apps तेज़ response speed और डिफ़ॉल्ट privacy का वादा करते हैं, लेकिन व्यवहार में offline support को लागू करना बहुत कठिन होता है
• सबसे बड़ा कारण synchronization की जटिलता है; जब कई devices पर एक साथ data बदला जाता है, तो अंततः वह ठीक उसी समान state पर converge होना चाहिए
• इसमें दो बड़े technical challenges हैं: समय-क्रम की अनिश्चितता और conflicts
• इस समस्या को हल करने के लिए Hybrid Logical Clocks(HLCs) और CRDTs जैसी distributed systems design तकनीकों को लागू करना ज़रूरी है
• SQLite आधारित extension capabilities का उपयोग करके विश्वसनीय और सरल synchronization architecture दिया जा सकता है, और इसे सभी platforms पर इस्तेमाल किया जा सकता है

---

Offline-first apps का वादा और वास्तविकता

• Offline-first apps तुरंत response, डिफ़ॉल्ट privacy, और अस्थिर network environment में भी बिना loading wait के उपयोग की बात करते हैं
• लेकिन वास्तव में ज़्यादातर apps offline support को सही तरह से लागू नहीं कर पाते; अधिकांश सिर्फ changes को local में अस्थायी रूप से save करके बाद में network जुड़ने पर भेजने का तरीका अपनाते हैं
• ऐसी implementation की reliability कम होती है, और अंत में "हो सकता है कि changes save न हुए हों" जैसे warning messages दिखाई देते हैं

Synchronization की मूलभूत कठिनाई

• Local-first app बनाते समय अनिवार्य रूप से एक distributed system बन जाता है
• कई devices offline environment में एक-दूसरे से स्वतंत्र रूप से data बदल सकते हैं, और बाद में दोबारा connect होने पर उन्हें ठीक उसी समान state पर सही ढंग से converge करना चाहिए
• इसके लिए दो बड़ी चुनौतियाँ मौजूद हैं
  • events के क्रम की अनिश्चितता
  • एक ही data पर conflicts

1. Event order की अनिश्चितता

• कई devices पर events अलग-अलग समय पर होते हैं, और उनके क्रम के अनुसार state बदल सकती है
  • उदाहरण: device A ने x=3 सेट किया, device B ने x=5 सेट किया → दोनों ने offline रहते हुए बदलाव किए, फिर sync के समय अलग-अलग परिणाम संभव हैं
• पारंपरिक centralized databases इसे strong consistency से हल करते हैं, लेकिन इसके लिए global synchronization चाहिए, इसलिए यह local-first systems के लिए उपयुक्त नहीं है
• अंततः हर event के लिए उचित क्रम को dynamic और distributed environment में भी तय करना पड़ता है; यानी central clock के बिना order तय करने का तरीका चाहिए

Hybrid Logical Clocks(HLCs) का उपयोग

• Hybrid Logical Clocks(HLCs) एक सरल लेकिन प्रभावी algorithm हैं, जो अलग-अलग devices के बीच events के क्रम पर व्यावहारिक सहमति बनाने में मदद करते हैं
• HLC physical time information और logical counter को मिलाकर काम करता है
• उदाहरण के लिए:
  • device A ने 10:00:00.100 पर event रिकॉर्ड किया, HLC होगा (10:00:00.100, 0)
  • message पाने वाला device B, भले उसकी clock पीछे हो, HLC को (10:00:00.100, 1) तक बढ़ा देता है
  • इससे दोनों devices की physical clock में अंतर होने पर भी event order को सही तरीके से तय किया जा सकता है

2. Conflict की समस्या

• सिर्फ सही order लागू करना काफ़ी नहीं है; अगर अलग-अलग devices एक ही data को स्वतंत्र रूप से edit करें, तो conflict होना अनिवार्य है
• ज़्यादातर systems developers से conflict resolution code manually लिखने की अपेक्षा करते हैं, लेकिन इससे errors का जोखिम और maintenance burden बढ़ता है

CRDTs का उपयोग

• Conflict-Free Replicated Data Types(CRDTs) को लागू करना सबसे अच्छा तरीका है
• CRDTs यह गारंटी देते हैं कि sync किसी भी order में हो, या duplicate apply हो जाए, तब भी हर device की state अंत में हमेशा समान रहेगी
• सबसे सरल CRDT strategy है Last-Write-Wins(LWW)
  • हर update को एक timestamp दिया जाता है
  • sync के समय नया timestamp वाला value चुना जाता है

SQLite के फ़ायदे

• Local-first apps बनाते समय विश्वसनीय और हल्का local DB अनिवार्य है, और SQLite सबसे उपयुक्त विकल्प है
• SQLite आधारित framework extension के ज़रिए synchronization लागू करने पर ये फ़ायदे मिलते हैं
  • message apply करना सरल है: current value पढ़ो → अगर नया timestamp अधिक recent है तो overwrite करो → नहीं तो ignore करो
  • यह तरीका sync order से स्वतंत्र होकर सभी devices पर state convergence की गारंटी देता है

Architecture का महत्व

• यह संरचना सरल और विश्वसनीय synchronization को संभव बनाती है
  • कई हफ़्तों तक offline रहने पर भी data loss के बिना reliability
  • हमेशा अंतिम state पर converge होने वाली deterministic property
  • भारी dependencies के बिना सिर्फ lightweight SQLite extension से समाधान
  • iOS, Android, macOS, Windows, Linux, WASM जैसे सभी प्रमुख platforms का support

Developers के लिए सुझाव

• सिर्फ request queue के सहारे offline mode का 'दिखावा' करने वाले तरीकों से बचने की ज़रूरत है
• eventual consistency की अवधारणा को अपनाकर HLC और CRDT जैसी साबित distributed systems techniques का उपयोग करना चाहिए
• बड़े और जटिल frameworks की बजाय छोटी और dependency-free structure का लक्ष्य रखना बेहतर है
• इसका परिणाम यह होगा कि apps को तुरंत चलना, offline उपयोग, और डिफ़ॉल्ट privacy जैसे लाभ मिल सकेंगे

Open source SQLite-Sync संदर्भ

• अगर आप production में तुरंत इस्तेमाल किए जा सकने वाले cross-platform offline-first engine में रुचि रखते हैं, तो open source SQLite-Sync extension को देख सकते हैं

[GN⁺]

Hacker News राय

• CRDT(Conflict-Free Replicated Data Types) को समाधान कहा जाता है, लेकिन वास्तव में ऐसा CRDT मॉडल बनाना जो सहज user expectations और consistent business logic दोनों से मेल खाए, बेहद कठिन है. ऊपर से data model को message bundles में बदलकर उसे लगातार वास्तविक state में फिर से reconstruct करना पड़ता है, जो बहुत बड़ा सिरदर्द है
  • नए web standard के रूप में BRAID नाम की एक initiative है. इसका लक्ष्य web state synchronization standard बनाना है, जो operational transform(OT) और CRDT तकनीकों को HTTP पर लागू करके मूल रूप से इंसानों और मशीनों दोनों के लिए अधिक friendly synchronization web बनाना चाहता है. Braid network performance बढ़ाता है और native P2P, collaborative editing, local-first webapp development को support करता है. संबंधित links हैं BRAID meeting, Braid HN चर्चा, RESTful API चर्चा, Braid HTTP व्याख्या
  • CRDT की बात अक्सर किसी universal solution की तरह होती है, लेकिन वास्तव में auto-merge आसान नहीं है. तकनीकी रूप से last-writer-wins algorithm को भी CRDT माना जा सकता है, लेकिन complex text merge में user intent और expectations दोनों का सम्मान करना लगभग असंभव जैसी कठिन समस्या है. कुछ परिस्थितियों में CRDT से merge करने की कोशिश खुद ही गलत approach हो सकती है. उदाहरण के लिए, meeting room booking में अगर दो लोग एक ही समय पर एक ही कमरा बुक कर दें, तो इसे algorithm नहीं बल्कि users को खुद conflict पहचानकर सुलझाना चाहिए
  • यह सच में ऐसा क्षेत्र है जिसमें डरपोक लोगों के लिए उतरना मुश्किल है. जो लोग साहस नहीं करना चाहते, उनके लिए “CRDT के बिना” एक alternative भी है, उसके लिए यहाँ देखें
  • हमारी team local-first app बनाते समय conflicts को बस ignore करने का तरीका अपनाती है. यानी last change wins. ज़्यादातर conflicts मामूली होते हैं, या तो audit log जैसी चीज़ों से आसानी से सुलझ जाते हैं, या फिर वैसे भी उन्हें अपने-आप हल नहीं किया जा सकता. उदाहरण के लिए, offline support वाले task tracker में अगर दो लोग एक ही task एक साथ शुरू कर दें, तो यह business process से अलग handle करना होगा
• पहले लगभग हर software local-first था, और यह स्वाभाविक माना जाता था. लेकिन आज दुनिया पूरी तरह control और profit optimization से चलती है, और नतीजा यह है कि लोग ज़्यादा बार नुकसान उठाने वाली संरचना में फँसते हैं. शिकायत होने पर भी उनके पास खास alternatives नहीं होते
  • जब हम पहले on-premise, self-hosted products बनाते थे, तो सबसे बड़ी customer complaint यह होती थी कि cloud option नहीं है. ज़्यादातर कंपनियाँ self-hosting नहीं चाहतीं, वे monthly fee देकर किसी और से manage करवाना पसंद करती हैं. लगता है HN cloud services की वास्तविक demand को कम आँकता है
  • “अगर लोग ऐसी service चाहते हैं जिसमें उनके साथ कम बुरा हो, तो उससे पैसा कमाया जा सकता है” — यह दावा आर्थिक रूप से सही नहीं है. समस्या यह है कि लोग वास्तव में कुछ हद तक नुकसान सहन कर रहे हैं. अगर education या risk awareness कहीं ज़्यादा बढ़ जाए तो बात बदल सकती है, लेकिन मुझे लगता है कि वह बहुत कठिन समस्या है
  • एक alternative के तौर पर FOSS(open source software) के बारे में सोचा जा सकता है
• काश apps हर content के लिए केवल online होने पर निर्भर न रहें. Tesla GPS भी पहले से डाउनलोड किए गए tiles को cache नहीं करता, इसलिए offline होने पर map में कुछ नहीं दिखता. Peacock और Kanopy जैसे apps भी media list या rendered objects को device पर नहीं रखते. जबकि 95% content पहले से device में होता है, उसे सक्रिय रूप से इस्तेमाल करना चाहिए. UI को dirty mark करके asynchronous save के सफल होने का इंतज़ार किया जा सकता है. offline app design में कोई बड़ा बदलाव माँगे बिना, सिर्फ बेहतर आदतों से ज़्यादातर समस्याएँ आसानी से हल हो सकती हैं
  • API responses में Cache-Control का सही इस्तेमाल करके और network layer पर उसका पालन करवाकर कई समस्याएँ हल की जा सकती हैं. इससे server पर cache lifetime बदलने पर app update के बिना भी तुरंत असर लागू हो सकता है
  • Google Maps में offline maps के लिए manually area चुनकर download किया जा सकता है, और कई zones को एक साथ cache भी किया जा सकता है. national parks जाते समय मैंने इसे offline अच्छे से इस्तेमाल किया है
  • “app design बदले बिना भी काम चल सकता है” वाली बात पर, मुझे लगता है vendors का असली लक्ष्य ज़्यादा data इकट्ठा करना है. उदाहरण के लिए, Apple ने भी offline maps दिए, लेकिन उसने जानबूझकर data expire होने दिया ताकि users उसके ecosystem में बँधे रहें. Tesla या Google के map tiles के पीछे भी शायद ऐसा ही कोई hidden motive हो
• apps की local-first प्रकृति या decentralization जैसे “राजनीतिक रूप से hot” मुद्दों पर ध्यान देते-देते, लोग असल में जो core value चाहते हैं, वह अक्सर छूट जाती है
  • Immich पर switch करते समय लगा था कि self-hosting की वजह से कुछ compromise करना पड़ेगा, लेकिन हैरानी हुई कि यह Apple या Google से कहीं बेहतर है. ऐसा product बहुत दुर्लभ है
• मुझे लगता है local-first apps के लोकप्रिय न होने की वजह आखिरकार economic है. SaaS और ad-based models मज़बूती से स्थापित हैं, जबकि local-first apps की profitability काफी कम है. इस model को पसंद करने वाले लोग data sovereignty, end-to-end encryption, offline use जैसी उन खूबियों को महत्व देते हैं जो पारंपरिक revenue models से टकराती हैं. अंत में open source community के जुनून पर निर्भर रहना पड़ता है
  • अब स्थिति यह है कि या तो “पैसा + data” दो, या “ads देखो”. सिर्फ असली cash देकर data protection पाने वाला model लगभग बाहर कर दिया गया है
  • मैं भी Relay नाम का एक local-first app बना रहा हूँ, जो Obsidian में Google Docs जैसी collaboration जोड़ता है. मुझे इसका business model काफ़ी अनोखा लगता है. service को “global identity layer” और “Relay Server”(open source/self-hosted) में बाँटा गया है, ताकि user document content पर पूरा control रख सके. यह simple single sign-on और permissions management देता है, और AI तथा AI Safety क्षेत्र की कंपनियों या compliance-महत्वपूर्ण संगठनों की इसमें खास दिलचस्पी है. लिंक है Relay.md
  • मैं अपने आसपास अक्सर यह देखता हूँ कि consumers subscription-only model देखकर खरीदते ही नहीं. वे पहले खरीद लेना चाहते हैं और बाद में इस्तेमाल करना चाहते हैं, लेकिन restrictions जैसे discount period, दोबारा आने पर बढ़ी हुई कीमत आदि की वजह से उनका खरीदने का मन ही खत्म हो जाता है. मुझे नहीं लगता कि यह सबसे अच्छा business model है
  • मुझे नहीं लगता कि replicated data structures ही समस्या हैं. कई बार single-player games पूरी तरह local-first होते हुए भी launcher के ज़रिए internet connection माँगते हैं
  • local-first apps में complexity की समस्या भी गंभीर है. उन्हें हर तरह के device और environment में चलना चाहिए, जबकि cloud-first apps को सिर्फ server के एक environment में चलाना होता है, इसलिए वे अपेक्षाकृत आसान और सस्ते पड़ते हैं
• पहले desktop और mobile software को कभी-कभी अजीब अपवाद की तरह देखा जाता है, लेकिन यह आज भी software distribution का बहुत आम तरीका है. इसके उलट, browser में local-first features लागू करने की कोशिश करने पर host system integration जैसी browser की कमियाँ ही ज़्यादा झेलनी पड़ती हैं
• शायद मैं कुछ मिस कर रहा हूँ, लेकिन सामान्य तौर पर तो “local-first” apps ही सामान्य लगते हैं. ज़्यादातर users अभी भी offline-based apps बहुत इस्तेमाल करते हैं. अगर मतलब “local-first web app” है, तो वह बात ज़्यादा सही लगती है. सच कहें तो “local-first web app” अपने-आप में ही विरोधाभासी concept है
  • मैं यह भी पूछना चाहूँगा कि क्या ज़्यादातर apps सच में local-first हैं, जिनके लिए user सीधे पैसे देता है. games को छोड़ दें तो अब ऐसी कंपनियाँ लगभग नहीं दिखतीं, और single-player games भी DRM, anti-cheat, updates वगैरह के बहाने internet माँगते हैं
  • यहाँ “local-first” से मतलब ऐसे apps हैं जिनमें cloud storage नहीं, बल्कि local data ही मूल आधार होता है, और cloud sync को support किया जाता है
• offline-first apps भी unstable network connection में loading spinner घूमने की समस्या से बच नहीं पाते. उदाहरण के लिए, Google Docs दस्तावेज़ के latest होने की पुष्टि करने में अटक जाता है, और उसे तुरंत खोलने के लिए Airplane Mode से connection काटना पड़ता है. Spotify भी saved playlist तक के लिए online supplementary info लेने की कोशिश में रुक जाता है. आखिरकार unreliable connection offline app development की सबसे बड़ी परेशानी है, क्योंकि apps हमेशा एक बार और cloud data तक पहुँचने की कोशिश करते रहते हैं
• article का solution भी closed cloud offering के अंदर फँसा हुआ है. Firebase की तरह वह अपने-आप में ठीक हो सकता है, लेकिन यह बात साफ़-साफ़ लिखी नहीं जाती और “बस sqlite extension” जैसे शब्दों के पीछे यह छिप जाता है कि support सिर्फ commercial cloud का है. Powersync और ElectricSQL जैसे vendors कम-से-कम यह बात पारदर्शी रूप से बताते हैं, और Powersync self-hosting भी संभव बनाता है
  • मुझे थोड़ा संदेह है कि local-first concept developer tools पर लागू हो सकता है या नहीं. SQLite-sync जैसे tools से local storage model पर आधारित software बनाना संभव है या नहीं, इसे परखने की ज़रूरत लगती है. ElectricSQL self-hosting support करता है, और मुझे अपनी “sqlite sync” tools list भी अपडेट करते रहना चाहिए. संबंधित links हैं local-first मूल लेख, SQLSync, SQLiteSync, SQLite-Sync
• मुझे लगता है कि और ज़्यादा local-only, self-hosted apps की ज़रूरत है. या फिर federated structure भी अच्छा विकल्प हो सकता है. मुझे लगता है कि network infrastructure अब तक बड़ी बाधा था, लेकिन Tailscale जैसे solutions आने से ऐसे apps बनाना बहुत आसान हो जाएगा
  • मैं presentation software बना रहा हूँ, जिसे local पर बेहतरीन चलना ही चाहिए, लेकिन साथ ही कहीं से भी accessible भी होना चाहिए. इन दोनों बातों को एक साथ पूरा करना अपेक्षा से ज़्यादा कठिन है. फिर भी technology आगे बढ़ने के साथ direct connection या WebRTC जैसे P2P implementations आसान होते जा रहे हैं. इन्हें वास्तविक product में ढालना और test करना अभी भी चुनौती है. फिर भी लगता है कि आगे local-first और बेहतरीन networking वाले software लगातार बढ़ेंगे. यह open source है. ज़्यादा जानकारी के लिए profile देखें
  • मैं भी इन दिनों इसी दिशा को मज़े से explore कर रहा हूँ. विस्तार से यहाँ पढ़ा जा सकता है. apps बनाने का यह नया तरीका काफ़ी मज़ेदार है