डेटाबेस बनाना बंद करें

डेटा प्रबंधन की जटिलता

• फ्रंटएंड इंजीनियरों को API डेटा को cache करने की ज़रूरत का एहसास होता है.
• शुरुआत में यह साधारण data storage से शुरू होता है, लेकिन जैसे-जैसे feature requests बढ़ती हैं, वे data cache, manual indexes, optimistic mutations, recursive cache invalidation आदि लागू करने लगते हैं.
• ये सुविधाएँ डेटाबेस के आंतरिक कामकाज जैसी होती हैं, और जटिल फ्रंटएंड applications में अंततः एक domain-specific database बन जाता है.

cache की बुनियाद

• शुरुआत API request के परिणामों को local variables में store करने से होती है.
• declarative framework का उपयोग करने वाले web applications में अनावश्यक API requests से बचने के लिए डेटा को variables में रखा जाता है.
• cache को higher layer पर ले जाना या UI tree के बाहर ले जाना अगला कदम होता है.

indexes के ज़रिए गति बढ़ाना

• डेटा को किसी खास तरीके से व्यवस्थित करके application का काम कम किया जा सकता है और user experience बेहतर बनाया जा सकता है.
• यह पता चलता है कि फ्रंटएंड data optimization, database storage के आंतरिक कामकाज जैसी है.
• ID के आधार पर डेटा store करना और तारीख़ के हिसाब से items को तेज़ी से query करने के लिए indexes बनाकर data structure को बेहतर किया जाता है.

optimistic mutations

• server response का इंतज़ार किए बिना local स्तर पर किसी खास operation के प्रभाव का simulation करना.
• इससे user interface तुरंत प्रतिक्रिया करता हुआ दिखता है, लेकिन अगर server से अलग परिणाम आता है तो UI को changes rollback करने पड़ते हैं.
• client और server के बीच logic को duplicate करना, asynchronous errors को handle करना, और application restart के बाद भी changes को reconcile करना जैसी चुनौतियाँ होती हैं.

recursive cache invalidation

• डेटा cache के कई हिस्सों में मौजूद होता है, और update के बाद server के साथ मेल बनाए रखने के लिए cache को सही तरीके से invalidate करना ज़रूरी होता है.
• UI को पता होना चाहिए कि cache के कौन-से हिस्से हर mutation से जुड़े हैं, और scale बढ़ने पर यह नाज़ुक हो सकता है.
• जब यह optimistic mutations के साथ जुड़ता है, तो client side पर server changes का अनुमान लगाने के लिए server logic को duplicate करना और भी मुश्किल हो जाता है.

क्या आप डेटाबेस बना रहे हैं?

• पर्याप्त जटिलता वाले फ्रंटएंड applications में अंततः कई data management features खुद बनाने पड़ते हैं, और इससे users को खुश करने तथा business problems हल करने में लगने वाला समय छिन जाता है.
• इसके विकल्प के रूप में एक frontend-optimized database stack पेश किया गया है.

SQLSync का परिचय

• SQLite पर आधारित frontend-optimized database stack, SQLSync विकसित किया गया है.
• SQLSync को data management समस्याएँ हल करने और developers को application की अनोखी features पर ध्यान केंद्रित करने में मदद करने के लिए डिज़ाइन किया गया है.
• SQLSync durable cache, SQLite की पूरी क्षमता, optimistic mutations, smart cache invalidation, और reactive queries प्रदान करता है.

GN⁺ की राय

इस लेख की सबसे महत्वपूर्ण बात यह है कि जैसे-जैसे फ्रंटएंड applications की जटिलता बढ़ती है, developers स्वयं डेटाबेस जैसी क्षमताएँ लागू करने लगते हैं. यह काम developers का समय लेता है और उन्हें उन features के निर्माण से दूर करता है जो वास्तव में users को value देते हैं. SQLSync जैसे frontend-optimized database stack इस समस्या को हल करने के लिए एक नवोन्मेषी दृष्टिकोण पेश करते हैं. यह लेख इसलिए दिलचस्प है क्योंकि यह मौजूदा data management तरीकों की बुनियादी समस्या को रेखांकित करता है और developers के लिए अधिक कुशलता से काम करने के नए समाधान तलाशता है.

[GN⁺]

Hacker News राय

• प्रोजेक्ट बनाने वाले दोस्त के प्रति समझ

  • SQLsync एक ऐसा टूल है जो frontend developers को browser के भीतर remote database को query और update करने देता है.
  • यह WASM की ताकत का उपयोग करके SQLite database को browser तक भेजने के तरीके से काम करता है.
  • कई clients के बीच synchronization के लिए यह reactive algorithm का उपयोग करता है.
  • यह developers की data synchronization समस्या को हल करने का एक क्रांतिकारी तरीका है.

• पिछली कंपनी के project management software का अनुभव

  • data को synchronize करने के लिए check-in/out mechanism का इस्तेमाल किया गया था, लेकिन real-time update apps के आने के बाद इसे पुराना माना जाने लगा.
  • 10 साल तक SPA web apps बनाने के अनुभव से, ऐसा लगा कि इस तरह के data synchronization mechanism अपने समय से आगे थे.

• SPA छोड़ देने पर गायब हो जाने वाली समस्याएं

  • Hotwire या htmx जैसे solutions का उपयोग करने पर server queries सरल हो जाती हैं, और उन्हें तेज़ बनाने की समस्या बेहतर समझ में आती है.

• SQLSync के निर्माता की राय

  • वे कई सवालों के जवाब दे रहे हैं, और छूटे हुए सवालों को भी समय-समय पर देखते रहेंगे.
  • SQLSync बनाने की प्रेरणा पर केंद्रित पहली पोस्ट पर चर्चा देखकर खुशी है.
  • अगली पोस्ट में वे SQLSync के काम करने के तरीके के बारे में बताएंगे.

• उपयोगकर्ताओं को वास्तविकता से अलग मानसिक मॉडल न दें

  • database synchronization, client-server model की तुलना में अधिक जटिल हो सकता है.
  • जब तेज़ UI की ज़रूरत हो, तब CRDT primitives का उपयोग करना अधिक सुरक्षित लगता है.

• "जो मापा जा सकता है वही प्रबंधित होता है" सिद्धांत और sunk cost fallacy

  • database की जटिलता ही समस्या है.
  • SQL का syntax समस्या है, और अगर बुनियादी relational database का उपयोग करना सुखद अनुभव होता, तो अपना database बनाने के बजाय DB का उपयोग करने का प्रलोभन और बढ़ जाता.
  • अच्छा database SQL का उपयोग करता है, और efficiency के लिए database language का उपयोग करना चाहिए.

• client और server के बीच state synchronization की समस्या

  • PHP/SSR model पर लौटने से UX में समझौता करके इस समस्या को टाला जा सकता है.
  • SPA अच्छे हैं, लेकिन multipart form posts अब भी काम करते हैं.
  • सारी state को server पर रखकर client को एक साधारण terminal की तरह मानना development experience को बेहतर बनाता है.

• ORM library के साथ तुलना

  • browser में supported TypeORM और SQL.js को सीधे उपयोग करने की तुलना में SQLsync कैसा है, इस पर सवाल.

• frontend और backend database का अंतर

  • frontend database, backend से अलग हो सकता है, और client पर real-time state को बेहतर तरीके से manage करने की ज़रूरत हो सकती है.
  • react query और WebSocket का उपयोग करके cache invalidation पर विचार किया जा रहा है.
  • SQLsync का विचार भी विचार करने योग्य है.

• SignalDB के जरिए समान प्रयास

  • SignalDB signals का उपयोग करने वाली reactivity और framework-agnostic mongodb-जैसे query syntax का उपयोग करता है.