SQLite3 WebAssembly दस्तावेज़ इंडेक्स

 (sqlite.org)
2 पॉइंट द्वारा GN⁺ 2024-10-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • आधुनिक WASM-support वाले ब्राउज़र में sqlite3 को सीधे इस्तेमाल करना चाहने वाले developers के लिए WebAssembly·JavaScript API दस्तावेज़ों को एक जगह समेटने वाला hub
  • तुरंत शुरू करने के लिए 3-step HOWTO से शुरुआत करें, और download·npm module·build·Emscripten की विस्तृत docs से installation और deployment paths देख सकते हैं
  • API docs loading methods, client code recipes, persistent storage, JS API में C structs, virtual tables और table-valued functions लिखने तक फैली हैं
  • SQLime, Evolu, SQLiteNext, sqlite-wasm-esm, sqlite-wasm-http जैसे वास्तविक use cases और sql.js, wa-sqlite, absurd-js जैसे पूर्ववर्ती projects को साथ में व्यवस्थित किया गया है
  • Browser SQLite, OPFS, IndexedDB, WASI से जुड़ी सामग्री को जोड़कर web environment में SQLite इस्तेमाल करने के implementation options की जल्दी तुलना की जा सकती है

sqlite3 WASM दस्तावेज़ों का दायरा

  • यह SQLite project की WebAssembly·JavaScript API documentation है, और आधुनिक WASM-support वाले browsers में sqlite3 इस्तेमाल करने में सक्षम बनाने वाली API को कवर करती है

  • Project guide और support channels

  • Run·install·build docs

    • three-step HOWTO: sqlite3 WASM module और संबंधित JavaScript API को include करके run करने का तरीका दिखाता है
    • Downloads: main project download page पर उपलब्ध
    • Building sqlite3 WASM: sqlite3 WASM और संबंधित JS code की build procedure को कवर करता है

  • API और implementation details docs

    • The API index: कई API variants और loading·access methods समझाता है
    • Cookbook: client-level code के लिए recipes
    • Persistent storage options: persistent storage options
    • C-structs: JS API में C structs का उपयोग करने का तरीका
    • virtual tables: JS में virtual tables और table-valued functions बनाने का तरीका
    • API changes: clients को प्रभावित कर सकने वाले API changes
    • module symbols app: JavaScript/WASM module में sqlite3 API symbols की list generate करता है

  • Documentation और repository maintenance

Use cases और संबंधित ecosystem

  • इस project का उपयोग करने वाले third-party projects

    • SQLime: database browser interface प्रदान करता है
    • Evolu: privacy, ease of use, और vendor lock-in न होने पर केंद्रित local-first platform
    • SQLiteNext: इस project को next.js के साथ integrate करने का demo
    • sqlite-wasm-esm: Vite toolchain में इस project का उपयोग करने का तरीका दिखाता है
    • sqlite-wasm-http: HTTP के ज़रिए सीधे serve किए जाने वाले database पर read-only access देने वाला SQLite VFS

  • Prior work और adjacent projects

    • Alon Zakai का sql.js: WebSQL को छोड़कर browser में sqlite3 को सीधे इस्तेमाल करने का पहला ज्ञात उदाहरण, और यह 2012 commit तक पीछे जाता है
    • Roy Hashimoto का wa-sqlite: sqlite3 database के OPFS storage का पहला ज्ञात implementation, और इसमें JS-side SQLite VFS से जुड़ा काम भी शामिल है
    • James Long का absurd-js: sqlite3 database को IndexedDB database के अंदर store करने का तरीका दिखाता है
    • postgres-wasm: browser में Postgres database server चलाता है
    • Jaccwabyt: WASM में hosted C structs को JS code से manipulate करने वाली छोटी JS library, जिसे इस project के OPFS sqlite3_vfs implementation support के लिए बनाया गया था
    • CoWasm: “Collaborative WebAssembly for Servers and Browsers” है, और demo app में sqlite3 shell application का WASM build शामिल है
    • absurder-js: Nicholas G. Piesco द्वारा absurd-js की फिर से कल्पना किया गया project, और इसका SQLite forum announcement भी है
    • sqlite-wasm-rs: wasm32-unknown-unknown builds के लिए Rust SQLite bindings प्रदान करता है

  • External docs और articles

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-16
Hacker News की टिप्पणियां

  • ब्राउज़र में इन-मेमरी SQLite चलाते हुए, अगर WAL लॉग की कॉपी को सर्वर पर उसी तरह स्ट्रीम किया जाए जैसे Litestream और Cloudflare Durable Objects इस्तेमाल करते हैं, तो यह दिलचस्प होगा
    इसके लिए WebSocket इस्तेमाल किया जा सकता है, या कभी-कभार fetch() POST भी संभव लगता है। बाद की विज़िट में सर्वर-साइड डेटा का उपयोग करके क्लाइंट SQLite को फिर से भरने का तरीका होगा
    हालांकि SQLite फोरम पोस्ट को देखें तो डिफ़ॉल्ट SQLite WASM बिल्ड में WAL मोड शामिल नहीं है, इसलिए शायद कस्टम बिल्ड की ज़रूरत पड़ेगी

    • इसमें कई स्तरों पर “यह ऐसे काम नहीं करता” वाली बात है
      इन-मेमरी SQLite WAL का उपयोग नहीं करता, और ब्राउज़र Wasm, SQLite के WAL मोड द्वारा अपेक्षित shared memory API जैसी चीज़ों को सपोर्ट नहीं करता
      Litestream को बहुत सटीक WAL कॉन्फ़िगरेशन चाहिए, और native SQLite की डिफ़ॉल्ट कॉन्फ़िगरेशन में यह संयोग से ठीक बैठ जाता है, लेकिन Wasm में इसे दोहराना मुश्किल है
      Cloudflare Durable Objects भले ही Litestream से प्रेरित रहे हों, लेकिन उनका वास्तविक कामकाज काफी अलग है, और LiteFS या Turso के साथ भी ऐसा ही है
      SQLite बदलावों को स्ट्रीम करने का बड़ा विचार अपने आप में संभव है, लेकिन काम बहुत बड़ा है, और ब्राउज़र Wasm के concurrency model के कारण implementation पेचीदा है
      वह फोरम पोस्ट मैंने पहले लिखी थी और server-side Wasm SQLite बिल्ड में WAL चलाया था, लेकिन ब्राउज़र में इस्तेमाल के लायक या संभव विकल्प नहीं था
    • अगस्त 2022 में मैंने इसी जैसा एक proof of concept बनाया था और Twitter DM भेजा था, लेकिन जवाब नहीं मिला। हैंडल justjs14 है
      उस समय का कोड ढूंढना पड़ेगा, लेकिन ब्राउज़र में VFS वाले SQLite को Wasm में compile करके DB खोलना, बदलाव करना, और WAL को सर्वर पर push/pull करने देना संभव बनाया था। मैन्युअल रूप से या WebRTC के ज़रिए ब्राउज़र-टू-ब्राउज़र sync भी संभव था, और अगर ब्राउज़र क्लाइंट को GitHub token दें तो यह GitHub Pages पर भी चलता था
      रुचि हो तो मैं इसे फिर से शुरू से चलने लायक बना सकता हूं। उस समय इस approach के साथ काफी प्रयोग किए थे, और मुझे लगता है कि कम से कम कुछ applications के लिए यह उपयोगी हो सकता है
      केवल pull feature वाला demo भी यहां है: https://just.billywhizz.io/sqlite/demo/#https://just.billywhizz.io/sqlite/demo/db/chinook.db
    • यहां के दूसरे विचारों के विपरीत, मुझे लगता है कि WAL कॉपी स्ट्रीमिंग तकनीकी रूप से संभव है। हालांकि इसे VFS के अंदर implement करना होगा
      “shared memory” SharedArrayBuffer हो सकती है, और अगर DB connection एक बार में सिर्फ एक ही खोला जाए तो सामान्य buffer भी संभव है। उदाहरण के लिए, पहले से आम SharedWorker के अंदर ऐसा किया जा सकता है
      implementation आसान नहीं होगा, लेकिन निश्चित रूप से संभव है। असल में बड़ी समस्या यह है कि यह row-level नहीं, बल्कि block-level changes को capture करता है
      इसलिए इसे पूरे DB replication के लिए इस्तेमाल किया जा सकता है, लेकिन कुछ rows को दूसरे users के साथ साझा करने जैसी partial sync मुश्किल है
      partial sync के लिए अगर row-level changes चाहिए, तो triggers या SQLite session extension जैसी चीज़ें इस्तेमाल करनी होंगी: https://sqlite.org/sessionintro.html
      PowerSync में client-side triggers इस्तेमाल किए जा रहे हैं, और trigger maintenance के काम के अलावा कोई बड़ा नुकसान नहीं दिखा
    • क्या आप https://electric-sql.com/ जैसी किसी चीज़ के बारे में सोच रहे हैं?
    • मैं इस “hydration” idea को पूरी तरह नहीं समझ पाया, लेकिन हाल ही में Wasm का उपयोग करके backend logic का कुछ हिस्सा ब्राउज़र में चलाने में दिलचस्पी हुई है
      उदाहरण के लिए, सामान्य template rendering या कुछ Htmx endpoints को Wasm में चलाने से, सामान्य server-side web framework में भी OP द्वारा कही गई चीज़ जैसी SQLite Wasm storage के साथ offline feature दिया जा सकता है
      पूरा Django example: https://github.com/m-butterfield/django_webassembly
      macros से client/server को अलग करने वाला minimal Rust example: https://github.com/richardanaya/wasm-service
      Wasm के बिना, ज़्यादा macros के साथ मिलती-जुलती चीज़ करने वाला Clojure Electric: https://github.com/hyperfiddle/electric
      हाल के Microsoft web tools में B से शुरू होने वाला भी कुछ है
      पिछले कुछ वर्षों में Python ecosystem के आश्चर्यजनक रूप से बड़े हिस्से को Wasm support मिला है, जिससे यह approach उपयोगी हो सकता है। स्पष्ट machine learning libraries के अलावा Pygame, Pyxel जैसी game libraries भी हैं, और SDL2 ने support जोड़ दिया है, इसलिए multitouch UI library Kivy support भी जल्द संभव लगता है
      किसी भी computer पर code चलाने, और ज़रूरत पड़ने पर web browser sandbox के अंदर platform bureaucracy या fees से बचने की कई नई संभावनाएं दिखती हैं

  • दस्तावेज़ में लिखा है कि ये components पहली बार 3.40 में public beta के रूप में आए थे, और community feedback के आधार पर 3.41 में API को स्थिर करने की योजना थी
    लेकिन SQLite की नवीनतम release 2024-08-13 की 3.46.1 है, इसलिए शायद API पहले ही स्थिर हो चुकी है, बस दस्तावेज़ अपडेट नहीं हुआ लगता है
    अगर SQLite team WASM version को bundle करके कोई आधिकारिक npm package निकाले, तो वह distribution का अच्छा तरीका होगा। बाद में देखा तो replies के मुताबिक यह पहले से मौजूद है
    व्यक्तिगत रूप से मेरा पसंदीदा SQLite-in-WASM अब भी Pyodide वाला variant है। यह official SQLite implementation से काफ़ी पहले से मौजूद था, और Pyodide इस्तेमाल करने पर Python standard library के हिस्से के रूप में WASM SQLite साथ आता है
    https://lite.datasette.io/ में इसका इसी तरह इस्तेमाल हो रहा है, और https://pyodide.org/en/stable/console.html पर भी इसे आज़माया जा सकता है
    sqlite3.connect(':memory:') से select sqlite_version() चलाने पर 2022-06-25 का 3.39.0 आता है, इसलिए लगता है Pyodide को version upgrade की ज़रूरत है। लगता है यह version emscripten से inherit होता है: https://github.com/emscripten-core/emscripten/blob/main/tools/ports/sqlite3.py

    • API स्थिर हो चुकी है, यह सही है। अगली बार कंप्यूटर के सामने बैठूंगा तो उस वाक्य को अपडेट करने की कोशिश करूंगा
      हालांकि SQLite team की ओर से official npm package जारी होने वाला नहीं है। हम केवल pure JS distribute करते हैं, और language के बाहर tooling support वाले rabbit hole में जाने से साफ़ मना करते हैं। project members में से कोई भी ऐसे tools इस्तेमाल नहीं करता
      Thomas Steiner द्वारा maintain किया गया “officially blessed” npm build हम support करते हैं, लेकिन किसी भी JS framework को सक्रिय रूप से development target नहीं बनाते
      किसी खास framework, npm सहित, को सीधे support करने से ऐसा impression हो सकता है कि हम उस framework को endorse कर रहे हैं, और हम third-party projects के endorsement से सक्रिय रूप से बचते हैं
    • लगता है SQLite team यह काम पहले से कुछ समय से कर रही है। JS module में @sqlite.org/sqlite-wasm को jsdelivr से import करके sqlite3-bundler-friendly.mjs और sqlite3.wasm load कर लें
      तब SQLite का C API और oo1 object-oriented API इस्तेमाल किया जा सकता है, और यह सामान्य type=module script tag या Deno में भी चलता है
      उदाहरण HTML यहां है: https://github.com/Ciantic/experimenting-sqlite-wasm/blob/main/standalone.html
    • https://github.com/sqlite/sqlite-wasm
      sqlite-wasm Pyodide की तुलना में काफ़ी तेज़ load होता है, इसलिए अगर Python की ज़रूरत नहीं है तो पहला विकल्प बेहतर है
    • DuckDB WASM को Pyodide से independent रूप से इस्तेमाल किया जा सकता है और SQLite extension भी संभव है
      हालांकि यह काफ़ी सीमित लगता है। sqlite_version() नहीं है, इसलिए version भी check नहीं कर पाया, और repository में version 3.38.1 है, जो काफ़ी पुराना है
      मौजूदा DuckDB web shell अभी SQLite extension load नहीं कर सकता, क्योंकि कल आए 1.1.2 के लिए SQLite extension अभी release नहीं हुआ है। पुराने version हाल में update हुए WASM edition के साथ चलते हैं
      spatial extension, GDAL, vector search वगैरह भी जोड़े जा सकते हैं: https://github.com/duckdb/duckdb-wasm/releases/tag/v1.29.0
      अपना “SQL web shell” बनाना भी बहुत मुश्किल नहीं था, लेकिन documentation पूरी तरह पर्याप्त नहीं थी
      https://github.com/duckdb/sqlite_scanner/blob/main/src/sqlite/sqlite3.h
    • उस page का FAQ पढ़ना मददगार हो सकता है

  • Go में इस्तेमाल करते समय ncruces का Wasm SQLite package https://github.com/ncruces/go-sqlite3 मुझे सच में बहुत पसंद है
    cznic का Go package भी शानदार है, लेकिन यह Wasm version OpenBSD जैसे environments में भी अच्छी तरह चलता है

  • WebSQL को बस SQLite ही होना चाहिए था, और अगर ऐसा होता तो offline-first और overall app storage ecosystem कहीं बेहतर होता
    क्या अब भी इसकी संभावना है? SQLite को abstract करने और जरूरत से ज्यादा specify करने के बजाय, क्या browsers द्वारा support किए जाने वाले SQLite API version को specify करके उसे समय-समय पर upgrade नहीं किया जा सकता?

    • browser में “समय-समय पर version upgrade” वाला तरीका काफ़ी समस्याग्रस्त हो सकता है
      web के core सिद्धांतों में से एक यह है कि जहां तक हो सके पुरानी चीज़ें चलती रहनी चाहिए, और ऐसे breaking changes मुश्किल होते हैं
      भले ही spec कुछ versions सूचीबद्ध करे और web pages को चुनने दे, browsers पर उन पुराने SQLite versions को बनाए रखने का कठिन बोझ आ जाएगा जो शायद अब support में न हों। हर version फिर लगभग 1MB जगह भी लेगा
      ऐसे में लगता है कि बेहतर यही है कि अभी की तरह हर website को अपनी पसंद की कीमत खुद चुकाने दी जाए
      अगर common resources को बार-बार download करने की चिंता है, तो यह समस्या दूसरे CDNs ने भी पहले से स्वीकार की हुई है। common dependencies के shared caching का समाधान SQLite तक सीमित रहने की तुलना में कहीं अधिक मूल्यवान होगा
      मौजूदा तरीका browser-provided version से बेहतर लगता है
    • मुझे SQLite पसंद है, लेकिन यह मानना पड़ेगा कि सभी browsers में डालने के लिए इसमें कई अजीब behaviours हैं। इसलिए SQLite जैसी API शायद बेहतर रहेगी
    • मेरे हिसाब से अच्छा ही हुआ कि WebSQL ने जगह नहीं बनाई
      अब जरूरत पड़ने पर 410KB compressed WASM blob के रूप में latest SQLite लाया जा सकता है। अगर हम browser द्वारा impose किए गए SQLite version से बंधे होते, तो शायद आज 10 साल पुराना version इस्तेमाल कर रहे होते

  • पेज को जल्दी-जल्दी देखने पर use case ठीक से समझ नहीं आया
    और साफ़ कहें तो, क्या यह IndexedDB का विकल्प बन सकता है? क्या डेटा persist होता है, या फिर SQLite file को सीधे File System API या IndexedDB/localStorage में रखना होगा?

    • introduction page के अनुसार, इस project के लक्ष्यों में से एक है, जहाँ तक संभव हो usable JS API के साथ client-side persistent storage को support करना
      अभी इसमें Origin-Private FileSystem(OPFS) और, बहुत सीमित रूप में, window.localStorage, window.sessionStorage backends के ज़रिए storage शामिल है

  • हाल में local-first क्षेत्र में काफी रुचि है, लेकिन browser के built-in storage API, खासकर IndexedDB, इस्तेमाल करने की तुलना में SQLite को embed करना काफ़ी भारी लगता है
    मुख्य open source libraries भी आम तौर पर built-in API ही इस्तेमाल करती दिखती हैं
    WebAssembly के ज़रिए एक और executable डालने की कोशिश करने के बजाय, मैं browser native storage के ऊपर SQLite-जैसी API और sync देने वाला open source समाधान देखना चाहूँगा

    • SQL को IndexedDB API से ज़्यादा इस्तेमाल में आसान माना जा सकता है, और उदाहरण के लिए if() filter की जगह WHERE clause इस्तेमाल करने पर memory और CPU भी कम लग सकते हैं
    • TinyBase में आपकी दिलचस्पी हो सकती है। यह मेरी बनाई हुई library है

  • official download page से लेकर mjs files और “bundler-friendly” files सब हटाने के बाद भी, minimum SQLite Wasm dependency लगभग 1.3MB की हो जाती है
    browser app के लिए यह थोड़ा बड़ा लगता है, लेकिन आजकल Wasm दूसरी जगहों पर भी चलता है, इसलिए उन environments में यह ज़्यादा समझ में आ सकता है

    • फिर भी compression अच्छा होता है। sqlite3.js और Wasm मूल रूप से 1.3MB हैं, लेकिन JS को minify करके और दोनों files को Brotli से compress करने पर यह 410KB तक आ जाता है
    • modern web app में 1.3MB मुझे काफ़ी reasonable size लगता है। खासकर site की पहली visit के बाद यह cache हो जाएगा
      अगर बात सिर्फ़ user settings store करने की है तो जाहिर है SQLite download करने की ज़रूरत नहीं, लेकिन अगर काम ऐसा है जहाँ पूरी database से फायदा है, तो 1MB की वजह से ज़्यादा चिंता करके बेवजह wheel फिर से invent करने की ज़रूरत नहीं
      अगर दूसरा comment सही है, तो network पर यह शुरुआत से ही 1.3MB भी नहीं होगा
    • यह बात भी साथ में सोचने लायक है कि browser में पहले से IndexedDB built-in है
      फिर भी Figma या Photoshop जैसी apps, या machine learning apps जैसे browser apps में, जहाँ application code और data पहले से ही बड़े होते हैं, वहाँ 1.3MB शायद बड़ा extra बोझ न हो
      यह भी सोचने लायक है कि Wasm parsing JS से काफी तेज़ होती है। इस दावे का source अभी नहीं ढूँढ पाया, लेकिन इस पर कम से कम एक अच्छी related post ज़रूर थी
      https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API
    • WebAssembly के sandbox model को ध्यान में रखना होगा। theory में program, यहाँ SQLite, जहाँ भी चलना उचित हो वहाँ चल सकता है
      यह local हो सकता है, central server हो सकता है, या पास का edge हो सकता है
    • server side पर concurrency और file locking को अलग तरह से handle करने वाला अलग Wasm SQLite build चाहिए होने की संभावना बहुत ज़्यादा है
      साथ ही WASI अभी answer से काफ़ी दूर है। SQLite amalgamation WASI पर ठीक से build हो जाता है, लेकिन concurrency अब भी अनसुलझी समस्या है
      Wasm-based SQLite driver को usable state में लाने के लिए VFS को scratch से बनाना पड़ा
      https://github.com/ncruces/go-sqlite3/blob/main/vfs/README.md

  • कुछ समय तक Rust ecosystem में इसे चलाने की कोशिश की, लेकिन blessed.rs के SQL wrappers rusqlite, sqlx अभी इसका फायदा नहीं उठा पा रहे थे
    इसे खुद wrap करना भी मुश्किल था, क्योंकि emscripten Wasm code को wasm32-unknown-unknown के साथ ठीक से काम कराने का तरीका नहीं मिला
    आखिरकार किसी न किसी रूप में JS wrapper चाहिए होता है, और फिर उन crates के expected interface को implement करके JS में expose करना पड़ता है। अगर Rust में यह solve हो जाए तो बहुत अच्छा होगा

    • इस पर related work कर रहा हूँ। अगर दिलचस्पी हो या योगदान देना चाहें तो यहाँ जुड़ सकते हैं: https://github.com/rhashimoto/wa-sqlite/discussions/154
      असल में wasm-bindgen में extern C header के रूप में SQLite emscripten build को import करना होगा, और shared array buffer access possible हो सके इसलिए multi-threaded mode में compile करते हुए VFS को Rust में फिर से implement करना होगा
      उसके बाद SQLite rows को raw Wasm bytes के रूप में access किया जा सकेगा, और Rust-SQLite style wrapper या integration बनाया जा सकेगा
      connection pooling जैसी convenience features फिर भी नहीं होंगी, लेकिन Wasm में DB को exclusive mode में इस्तेमाल करना बेहतर हो सकता है
    • इस SQLite build को Rust के Diesel SQLite के साथ चलाने वाला यह है: https://github.com/xmtp/diesel-wasm-sqlite
      इस हफ्ते 0.2 release तैयार कर रहे हैं और कुछ issues polish करेंगे। इसके अलावा Diesel ORM को native की तरह इस्तेमाल किया जा सकता है
    • emscripten Wasm code और wasm32-unknown-unknown को अच्छी तरह match कराने वाली बात पर अच्छी खबर है
      Emscripten और Rust को Wasm में अच्छी तरह साथ काम कराने की योजना है: https://github.com/rustwasm/wasm-bindgen/pull/4014#issuecomment-2356908451
    • मैं भी इसका काफ़ी लंबे समय से इंतज़ार कर रहा हूँ। कुछ PR लगभग 1 साल से pending हैं, और proof of concept तो देखा है, लेकिन वह सच में इस्तेमाल लायक चीज़ से अभी दूर था

  • SQLite के Wasm build और Chicory runtime का उपयोग करके pure JVM पर चलने वाली SQLite library बनाई गई: https://github.com/dylibso/sqlite-zero
    यह production-ready होने के लक्ष्य से ज़्यादा एक experiment जैसा है, लेकिन dependency-free SQLite tool को JVM ecosystem में लाने के लिए उपयोगी हो सकता है

    • file system access किस तरह का है? WASI है?

  • एक सामान्य सवाल: किन परिस्थितियों में पूरी DB भेजकर browser से query process करवाना ज़्यादा फायदेमंद होता है?
    दूसरे शब्दों में, traditional server-hosted DB model की तुलना में user experience बेहतर करने के लिए इसे कब इस्तेमाल किया जाएगा?

    • व्यक्तिगत रूप से मैं इसे static hosting website में इस्तेमाल कर रहा हूँ, इसलिए server-hosted database शुरू से ही विकल्प नहीं था
      सही driver इस्तेमाल करने पर पूरी database भेजने के बजाय ज़रूरी database chunks stream किए जा सकते हैं: https://github.com/mmomtchev/sqlite-wasm-http
      पूरी FTS database download किए बिना भी SQLite full-text search किया जा सकता है। search term काफ़ी छोटा हो तो ज़्यादातर हिस्सा मिल जाता है, लेकिन पूरा नहीं
    • इस लेख का title देखकर intuitively जो चीज़ याद आई, वह offline-first apps में PouchDB और CouchDB के interaction जैसा है
      https://medium.com/offline-camp/couchdb-pouchdb-and-hoodie-as-a-stack-for-progressive-web-apps-a6078a985f18
    • offline use में बड़े volumes of data handle करते समय यह अच्छा हो सकता है
      audio library से लेकर 3D modeling software तक संभव है। changes local पर बनाए और persist किए जा सकते हैं, फिर नियमित रूप से या दोबारा online होने पर server side के साथ sync किए जा सकते हैं
    • मैं ऐसे dashboards बना रहा हूँ जो कई services से सीधे communicate करते हैं। मेरे server पर access control और token management के लिए बहुत थोड़ा data होता है, और actual data मेरे server तक नहीं आता
      ऐसे apps client-side embedded DB के लिए अच्छे candidates हैं