Linear ने मुझे लोकल-फर्स्ट रैबिट होल में पहुँचा दिया
(bytemash.net)- Linear का उपयोग करते हुए वेब एप्लिकेशन डेवलप करने के तरीके की मेरी समझ में बड़ा बदलाव आया
- Linear local-first तरीके से काम करता है और तुरंत प्रतिक्रिया तथा बिना नेटवर्क लेटेंसी वाला इंटरैक्शन देता है
- इसमें क्लाइंट के पास independent database होता है और बदलाव asynchronous तरीके से server के साथ sync होते हैं
- लेकिन डिस्ट्रिब्यूटेड वातावरण में sync, conflict resolution, offline handling जैसे कामों की implementation कठिन होती है
- Jazz, Electric SQL, Zero आदि समेत local-first ecosystem में कई अलग-अलग solutions आ रहे हैं, और developer experience लगातार बेहतर हो रहा है
अवलोकन
Linear नाम का एक project management tool इस्तेमाल करते हुए मुझे local-first के शानदार performance और user experience से बहुत प्रेरणा मिली। पारंपरिक वेब ऐप्स में अक्सर महसूस होने वाली नेटवर्क देरी, loading state और page refresh जैसी चीज़ें लगभग महसूस ही नहीं हुईं। इस अनुभव ने मुझे local-first (लोकल-फर्स्ट) paradigm के तकनीकी सिद्धांत और वास्तविक implementation को गहराई से explore करने के लिए प्रेरित किया।
रैबिट होल में उतरना
Linear की तकनीकी परतें खोलते समय पता चला कि वे browser की IndexedDB को वास्तविक database की तरह use करते हैं। सभी बदलाव पहले local में तुरंत process होते हैं और फिर GraphQL तथा Websockets के जरिए background में sync किए जाते हैं।
- local-first शब्द को कभी UX strategy (तत्काल responsiveness) के तौर पर, कभी डेटा को local पर रखकर sync करने वाली philosophy के तौर पर समझा जाता है
- परंपरागत web apps में server ही single source of truth था, लेकिन local-first architecture में हर क्लाइंट का अपना database होता है
- database की दूरी user के करीब आते ही, यूज़र इंटरेक्शन से नेटवर्क लेटेंसी लगभग पूरी तरह हट जाती है
चुनौती: यह आसान नहीं है
जब मैंने Linear का तरीका खुद लागू करने की कोशिश की, तब समझ आया कि complexity काफी ज्यादा है।
- ऑनलाइन/ऑफलाइन स्विचिंग
- डिस्ट्रिब्यूटेड क्लाइंट्स के बीच conflict resolution
- partial sync (सारा डेटा नीचे डाउनलोड किए बिना design करना)
- cache data schema migration
- डिस्ट्रिब्यूटेड वातावरण में सुरक्षा और access control
- ये सभी area भारी engineering time और प्रयास मांगते हैं
2025 का Local-First ecosystem
2025 के हिसाब से, local-first ecosystem में कई मजबूत solutions मौजूद हैं।
- Electric SQL: Postgres पर आधारित sync engine
- PowerSync: एंटरप्राइज़-केंद्रित solution
- Jazz: local-first apps को आसानी से build करने वाला tool
- Replicache: पहले का प्रमुख solution (abandoned)
- Zero: Replicache टीम की नई दिशा
- Triplit: TripleStore आधारित sync
- Instant: developer experience पर focus करने वाला
- LiveStore: real-time synchronization layer उपलब्ध कराता है
Deep Dive: Jazz
Jazz का unique promise था: "local-first ऐप्स को सिर्फ state update बदलने जितना आसान बनाना"—इसने मेरा ध्यान खींचा।
The Mental Model
Jazz में Collaborative Values(CoValues) नाम का एक real-time collaboration primitive introduce किया गया है।
- Jazz और Zod से schema define करते हैं: यह सिर्फ simple type नहीं, बल्कि automatically sync होने वाले live objects की तरह काम करता है
- अलग API route, request/response logic, DTO जैसी चीज़ों की जरूरत नहीं; बस object state बदलते ही sync अपने आप हो जाता है
How Jazz Achieves This
Jazz की अंदरूनी संरचना यह है:
- Unique ID generation: हर data को स्वचालित रूप से unique ID दी जाती है
- Event sourcing: बदलाओं का history events के रूप में store होता है, जिससे real-time sync अधिक efficient बनता है
- End-to-End Encryption: sync से पहले client पर ही डेटा encrypt होता है; server सिर्फ encrypted blobs ही देख सकता है
- Group-based permission model: पारंपरिक ACL की जगह group-level permissions, जिसमें ownership स्पष्ट अलग होता है
The Trade-offs
यह संरचना prototyping और fast UI development में बेहद productive है। लेकिन कुछ design characteristics पर ध्यान देने की ज़रूरत है:
Your Server Is Blind
End-to-end encryption की वजह से server यूज़र का डेटा पढ़ नहीं सकता। अगर पहले से define न करें कि server को किन डेटा की access चाहिए, तो monitoring, abuse prevention आदि पर governance सीमित हो सकती है।
Time Travel Is Mandatory
Event sourcing से सारे बदलाव का इतिहास स्थायी रूप से store होता है। इससे Undo/Redo करना आसान है, लेकिन GDPR जैसी legal requirement के हिसाब से delete करना मुश्किल हो सकता है।
Storage Goes Brrr
delete न होने पर storage usage लगातार बढ़ती जाती है। छोटे projects के लिए ठीक है, लेकिन बड़े SaaS में storage खर्च काफी बढ़ सकता है।
Local Dev Still Has Quirks
Authentication का default तरीका Passkeys पर आधारित है, इसलिए custom implementation या local environment में शुरुआत में HTTPS, certificate management, key migration जैसे झंझट आते हैं। हालांकि Better Auth integration आदि से सुधार आने की संभावना है。
But Honestly? Still Worth It
इन सीमाओं के बावजूद, Jazz का developer experience और productivity बहुत impressive है। यह अभी शुरुआती दौर में है, लेकिन उम्मीद है कि आगे चलकर कई issues धीरे-धीरे resolve होंगे।
Exploring: Electric SQL and Zero
Jazz से अलग, Electric SQL और Zero अधिक incremental approach लेते हैं।
- existing Postgres tables सीधे उपयोग किए जा सकते हैं
- Electric SQL UI sync के लिए table का कुछ हिस्सा reactive query (Shape) के रूप में subscribe करने देता है
- बदलाव/म्यूटेशन handle करने का तरीका Jazz से अलग है, और LiveStore integration जैसे कई विकल्प मौजूद हैं
- Zero Electric जैसा ही है, लेकिन इसमें change sync support built-in है
When Does Local-First Make Sense?
लेख में local-first paradigm कब fit बैठता है और कब कठिन हो जाता है इसका summary दिया गया है।
उपयुक्त:
- क्रिएटिव tools (डिज़ाइन, writing, music आदि)
- collaborative apps
- मोबाइल ऐप्स जहाँ offline support जरूरी हो
- developer tools
- personal productivity apps
चुनौतीपूर्ण:
- बड़े server-side business logic वाले सिस्टम
- strict audit requirement
- large-scale analytics systems
- deeply integrated legacy systems
- server-side request deny करने वाली architecture
आगे की दिशा
local-first सिर्फ एक architectural tweak नहीं, बल्कि web development में paradigm shift है। Linear ने पहले ही user experience में बड़ा असर दिखाया है। डेवलपर को यह देखना होगा कि ये structural trade-offs उनके project के लिए सही हैं या नहीं।
लेखक खुद Jazz पर personal apps बनाकर practical pros/cons और abstraction limitations समझने की कोशिश कर रहा है। ecosystem अभी शुरुआती stage पर है, इसलिए tools और patterns को और mature होने में समय लगेगा। फिर भी डेटा को local पर रखने के benefits साफ दिखते हैं और ये trend खत्म होने वाला नहीं लगता।
अगर नए प्रोजेक्ट में ये constraints accept की जा सकती हैं, तो local-first जरूर try करने लायक है। खराब स्थिति में आप एक नया architecture pattern सीखेंगे, और बेहतर स्थिति में शायद बहुत तेज़ user experience बना पाएंगे—जहाँ 300ms प्रतिस्पर्धा में ये बड़ा edge हो सकता है।
1 टिप्पणियां
Hacker News टिप्पणी
Zero भी Electric जैसा फीचर देता है और mutation handling सीधे सपोर्ट करता है Zero का मुख्य फर्क यह है कि यह query-based sync है ऐप को query unit पर डिजाइन किया जा सकता है, और क्या sync करना है यह पहले से तय करने या सेट करने की जरूरत नहीं; सिर्फ query रन करने से जितना ज़रूरी हो या उससे कम डेटा sync हो जाता है अगर client के पास आवश्यक डेटा नहीं है तो query ऑटोमेटिकली server पर चली जाती है और synced डेटा आगे की query में तुरंत उपयोग के लिए उपलब्ध हो जाता है यह तरीका काफी practical है
मैं SSR को पसंद करता हूँ मेरे हिसाब से client में सिर्फ session token, current URL और DOM state होना चाहिए network और server लगातार तेज़ हो रहे हैं light speed fixed है, लेकिन हम अभी उसका पूरा फायदा नहीं ले पाए हैं Hollow core fiber जैसी टेक्नोलॉजी इंटरनेट latency को 30% तक घटाने की दिशा में भी आ रही है अगर RTT पहले से 500ms भी हो, तो SSR से 16ms के अंदर render की गई page आज की ज्यादातर वेबसाइटों से कहीं ज़्यादा instant लगेगी server पर 60Hz frame से भी ज्यादा समय HTML response render करने में लगाना मुझे गलत लगता है Zen5 core पर 30~40MB JSON serialization उसी समय में संभव है server perspective से देखें तो यह सिर्फ fancy UTF-8 strings हैं इन चीज़ों को ms नहीं, μs unit में नापना चाहिए transmit latency ज़्यादा होने का मतलब यह नहीं कि CPU time को lazy तरीके से खर्च कर सकते हैं मैंने SQLite use करके millisecond jail से निकल गया हूँ hosted SQL services जब 1ms से कम latency target करें तो अक्सर बाधा बनती हैं browser standards भी कुछ navigation delay problems को हल कर सकते हैं Speculation Rules API देखें
केवल यह assumption कि network और server तेज़ हो जाएँगे, SSR का आम आधार नहीं बन सकता इसका मतलब यह कि SSR की जरूरत केवल कुछ exception cases में है, जहाँ server compute ज्यादा हो या logic separation मुश्किल हो वैसे कई बार client-side rendering ज्यादा fast होती है rendering logic अक्सर data size की तुलना में बहुत complex होता है, और सभी client resources जोड़ दें तो server से ज्यादा भी हो सकते हैं अगर SSR ही अकेला विकल्प होता तो आज Web Assembly के hype की वजह समझ में नहीं आती local computation पर पोस्ट भी पढ़ने लायक है आखिर में कौन सा बेहतर है यह पहले से पता नहीं चल सकता, और request समय पर चुनना संभव होना चाहिए
Right Tool For The Right Job! उदाहरण के लिए, क्या Google Docs, Sheets जैसी collaboration docs को सिर्फ server-side rendering से handle किया जा सकता है? अगर सिर्फ SSR पर अड़े रहें तो यूज़र के बीच-edit के दौरान कोई दूसरा content बदल दे, ऐसा बार-बार होगा इन tools में बदलने का impact छोटा होता है और users तुरंत देख लेते हैं कि कोई साथ में काम कर रहा है, इसलिए ये ठीक से काम करते हैं जबकि hotel booking जैसे service में real-time sync की जरूरत नहीं होती दूसरी तरफ, बीच में unstable sync या पहले से ही poorly-designed enterprise app बाद में domain और system complexity के कारण consistency maintain करना मुश्किल बना देता है
अगर मौजूदा SSR ऐप में नीचे जैसी कोई library सरलता से जोड़ी जा सके, तो मैं तुरंत use करूँगा:
यह सच में happy-path engineering है real world में, जो लोग happy-path पर नहीं हैं, उनके लिए काफ़ी frustrating है
SSR की current और future main उपयोगिता first page load में है, खासकर मोबाइल पर उसके बाद केवल client-side state updates चाहिए होते हैं, इसलिए बाकी सब कुछ और तेज़ होना चाहिए अगर engineering skills कम हों, तो SSR भी किसी काम का नहीं लगता
मैं CRDT-based, local-first architecture वाला open-source task management software बना रहा हूँ motivation यह था कि मुझे collaboration feature की जरूरत नहीं थी और Linear जैसा tool मेरे use-case के लिए बहुत complex था इस architecture के benefits ये हैं:
मैं Jazz से बहुत प्रभावित हूँ DX कमाल का है, इसलिए coding लगभग synchronous और imperative महसूस होती है और development मज़ेदार लगता है सब कुछ तुरंत महसूस होता है, और offline काम संभव है इसलिए UX भी बेहतर है सबसे बड़ी समस्या deployment और लंबी अवधि की maintainability है; data लगातार बढ़ता रहेगा (हालाँकि ज़्यादातर clients को उसे सब नहीं देखना पड़ता) सबसे बड़ा issue यह कि changing public index के लिए अच्छी solution नहीं दिखती थ्योरी में public readable list of ids possible है, लेकिन अभी Anselm से बात करके पता चला कि वे इसे solve कर रहे हैं कुल मिलाकर local-first का cost कम नहीं है, लेकिन अगर Jazz traditional centralized server मॉडल की core weakness solve कर दे, तो लगभग हर मामले में Firestore को replace कर सकता है
ElectricSQL और TanStack DB दोनों अच्छे हैं, लेकिन web पर local-first पर इतना focus क्यों है, यह समझ नहीं आता मोबाइल पर ऑफलाइन कारणों से local-first की जरूरत कहीं ज्यादा महसूस होती है web browser users में तो इंटरनेट अक्सर connected ही रहता है ऊपर से ये local-first techs theory में ठीक लगती हैं, मगर conflict resolution ठीक से न हो तो practical world में जल्दी break हो जाती हैं मोबाइल ऐप को local-first बनाने की process से जो सीख मिली, उसी से मैं CRDT पर आया
web tech से local-first app बनाना native की तुलना में कहीं कठिन है native app install होते ही offline support डिफ़ॉल्ट होता है web में AppManifest, ServiceWorker जैसी अतिरिक्त चीज़ों से मुश्किल से offline जोड़ना पड़ता है native में 30 साल पुराने C code से disk पर फाइलें freely read/write कर सकते हैं, बस यही पर्याप्त होता है web में IndexedDB सच में nightmare है, localStorage scale होने पर usable नहीं रहता, OriginPrivateFileSystem भी सीमित है अगर यूज़र एक महीने में एक बार भी साइट नहीं खोलता, तो Safari local browser state delete कर देता है JavaScript या Emscripten से wasm build करने जैसी कोशिशें करने पर भी async web APIs को कोई-न-किसी तरह चलाकर काम करना पड़ता है Apple ने 2015 से ही CoreData + CloudKit combo के साथ local+sync का almost complete solution दे रखा है Google की तरफ से शायद Firebase ही करीब लगता है
मैं Replicache और Zero के developer के नाते अक्सर सोचता हूँ कि web पर focus क्यों है सही जवाब अभी नहीं मिला, लेकिन मेरा take है:
मोबाइल पर web से कहीं मजबूत offline primitives उपलब्ध हैं लेकिन real productivity/ collaboration अधिकतर web पर होता है, और web पर्यावरण कहीं ज्यादा hostile है tabs के बीच state sync, storage deletion जैसी complex समस्याएँ हैं इसलिए local-first के कई प्रयास web-first होकर विकसित हो रहे हैं
sync engines पहले web target करते हैं क्योंकि ये technologies अभी युवा हैं और updates बहुत आते हैं मोबाइल ऐप अपडेट करना सच में pain है, जबकि web app अपडेट करना आसान मुझे लगता है कि PWA capability अब काफी अच्छी हो गई है iOS PWA में भी push notifications आ गए हैं, और मैं मोबाइल ऐप जैसा दिखने वाले web app से भी satisfied हूँ
यहाँ core point यह नहीं कि 'कौन सा feature ले सकते हैं' बल्कि उस 'fun' में है जो बेहद तेज़ और responsive product चलाने पर मिलता है इसलिए मैं local-first pursue करता हूँ
Local-first/sync engines के future में भरोसा है local-first framework landscape की अलग-अलग tables का summary बहुत useful है personally मुझे Triplit.dev सबसे अच्छा लगा, और इसे TanStack DB के साथ भी combine किया जा सकता है PowerSync और NextGraph भी explore करने लायक options हैं recent LocalFirst Conf videos में NextGraph का talk देखना मुझे अच्छा लगा: YouTube वीडियो
इन tools में DB migration support कितना practical है, यह देखना चाहता हूँ long-term बिना server के क्लाइंट को support करते समय बहुत पुराने schema state से forward migration करना बड़ा blocker नहीं होगा? वास्तविकता में single-user frontend bug troubleshooting already कठिन है, अगर schema state भी handle करनी पड़े तो complexity बहुत बढ़ सकती है
Meteor याद आता है
ये approaches पुराने approaches जैसा ही लगता है
Triplit ज़रूर try करना है, पूछना चाहता हूँ किसी ने InstantDB use किया है क्या? मुझे भी interest था, पर अभी तक try नहीं किया
मैं लंबे समय से Electric का approach पसंद करके देख रहा हूँ Electric ने complexity का बड़ा हिस्सा developer और API पर छोड़कर इसे cleaner बनाया है bidirectional sync solutions अक्सर simple Todo apps में ही ठीक से काम करते दिखते हैं जैसे-जैसे permissions, business logic evolution, migrations और product growth आते हैं, durability पर सवाल खड़े हो जाते हैं Electric सिर्फ read sync को view के रूप में सपोर्ट करता है और writes को existing API/REST/RPC से सीधे लेता है, इसलिए existing projects में adopt करना आसान है
curious हूँ कि couchdb / pouchdb सूची में क्यों नहीं हैं ये अभी भी काफी अच्छे tools हैं