आपके ऐप्लिकेशन के लिए बेहतर परफ़ॉर्मेंस वाला स्टोरेज: स्टोरेज फ़ाउंडेशन एपीआई

Thomas Steiner

यह वेब प्लैटफ़ॉर्म, डेवलपर को ऐसे टूल उपलब्ध कराता जा रहा है जिनकी मदद से वे वेब पर बेहतर परफ़ॉर्मेंस वाले ऐप्लिकेशन बना सकें. WebAssembly (Wasm) ने तेज़ी से काम करने वाले और बेहतर वेब ऐप्लिकेशन पाने का रास्ता खोला है. वहीं, Emscripten जैसी टेक्नोलॉजी की मदद से अब डेवलपर, आज़माए गए और जांचे गए कोड को वेब पर फिर से इस्तेमाल कर सकते हैं. इस क्षमता का वाकई में फ़ायदा पाने के लिए, डेवलपर के पास स्टोरेज के मामले में एक जैसी क्षमता और विकल्प होना चाहिए.

ऐसी जगह पर Storage Foundation API की ज़रूरत पड़ती है. Storage Foundation API एक नया स्टोरेज एपीआई है, जो तेज़ी से काम करता है और वेब ब्राउज़र पर इस्तेमाल के लिए सबसे ज़्यादा अनुरोध करता है. इसकी मदद से, बेहतर तरीके से काम करने वाले डेटाबेस लागू किए जा सकते हैं और कम समय तक चलने वाली बड़ी फ़ाइलों को अच्छे से मैनेज किया जा सकता है. इस नए इंटरफ़ेस की मदद से, डेवलपर वेब पर "अपनी खुद की मेमोरी जोड़" सकते हैं. इससे वेब और प्लैटफ़ॉर्म के लिए खास कोड के बीच सुविधा का अंतर कम हो जाएगा.

Storage Foundation API को इस तरह डिज़ाइन किया गया है कि वह एक बहुत ही बुनियादी फ़ाइल सिस्टम से मिलता-जुलता हो. इसलिए, यह डेवलपर को सामान्य, आसान, और परफ़ॉर्मेंस देने वाले प्रिमिटिव उपलब्ध कराता है, ताकि वे बेहतर लेवल के कॉम्पोनेंट बना सकें. ऐप्लिकेशन अपनी ज़रूरत के हिसाब से सबसे अच्छे टूल का इस्तेमाल कर सकते हैं. साथ ही, उनकी उपयोगिता, परफ़ॉर्मेंस, और भरोसे के बीच सही संतुलन बनाया जा सकता है.

वेब को किसी अन्य Storage API की ज़रूरत क्यों है?

यह वेब प्लैटफ़ॉर्म डेवलपर के लिए, स्टोरेज के कई विकल्प देता है. हर विकल्प को इस्तेमाल के खास उदाहरणों को ध्यान में रखकर बनाया गया है.

  • इनमें से कुछ विकल्प इस प्रस्ताव के साथ ओवरलैप नहीं करते. ऐसा इसलिए, क्योंकि वे सिर्फ़ बहुत कम डेटा सेव करने की अनुमति देते हैं. जैसे, कुकी या वेब स्टोरेज एपीआई, जिसमें sessionStorage और localStorage प्रोसेस शामिल हैं.
  • अन्य विकल्पों को पहले ही कई वजहों से बंद कर दिया गया है. जैसे, File and Directory Listings API या WebSQL.
  • File System Access API में एक जैसा एपीआई प्लैटफ़ॉर्म है. हालांकि, इसका इस्तेमाल क्लाइंट के फ़ाइल सिस्टम के साथ इंटरफ़ेस करने और उस डेटा का ऐक्सेस देने के लिए होता है जो ऑरिजिन या ब्राउज़र के मालिकाना हक से बाहर का हो सकता है. इस अलग फ़ोकस के साथ, सुरक्षा से जुड़े सख्त विचार और बेहतर परफ़ॉर्मेंस की लागत आती है.
  • IndexedDB API का इस्तेमाल, Storage Foundation API के कुछ इस्तेमाल के उदाहरणों के लिए, बैकएंड के तौर पर किया जा सकता है. उदाहरण के लिए, Emscripten में IDBFS शामिल होता है. यह IndexedDB-आधारित स्थायी फ़ाइल सिस्टम है. हालांकि, IndexedDB मूल रूप से एक की-वैल्यू स्टोर है, इसलिए इसमें परफ़ॉर्मेंस की बहुत ज़्यादा सीमाएं होती हैं. इसके अलावा, IndexedDB में किसी फ़ाइल के सब-सेक्शन को सीधे ऐक्सेस करना और भी ज़्यादा मुश्किल और धीमा है.
  • आखिर में, कैश मेमोरी इंटरफ़ेस बड़े पैमाने पर काम करता है. इसे वेब ऐप्लिकेशन संसाधनों जैसे बड़े आकार के डेटा को सेव करने के लिए ट्यून किया गया है, लेकिन इन वैल्यू में बदलाव नहीं किया जा सकता.

Storage Foundation API, ऐप्लिकेशन के ऑरिजिन में तय की गई बदली जा सकने वाली बड़ी फ़ाइलों को बेहतर तरीके से सेव करने की अनुमति देकर, स्टोरेज के पिछले विकल्पों की कमियों को दूर करने की कोशिश करता है.

Storage Foundation API के लिए इस्तेमाल के सुझाए गए उदाहरण

उन साइटों के उदाहरण जो इस एपीआई का इस्तेमाल कर सकते हैं:

  • काम को आसान बनाने या क्रिएटिविटी को बढ़ावा देने वाले ऐसे ऐप्लिकेशन जो बहुत ज़्यादा वीडियो, ऑडियो या इमेज डेटा का इस्तेमाल करते हैं. ऐसे ऐप्लिकेशन, सेगमेंट को मेमोरी में रखने के बजाय उन्हें डिस्क पर ऑफ़लोड कर सकते हैं.
  • ऐसे ऐप्लिकेशन जो Wasm से ऐक्सेस किए जा सकने वाले स्थायी फ़ाइल सिस्टम पर भरोसा करते हैं और जिन्हें आईडीबीएफ़एस की गारंटी से ज़्यादा परफ़ॉर्मेंस की ज़रूरत होती है.

Storage Foundation API क्या है?

एपीआई के दो मुख्य हिस्से होते हैं:

  • फ़ाइल सिस्टम कॉल, जो फ़ाइलों और फ़ाइल पाथ से इंटरैक्ट करने के लिए बुनियादी सुविधाएं देते हैं.
  • फ़ाइल हैंडल, जो किसी मौजूदा फ़ाइल को पढ़ने और उसमें बदलाव करने का ऐक्सेस देते हैं.

फ़ाइल सिस्टम कॉल

Storage Foundation API ने एक नया ऑब्जेक्ट storageFoundation लॉन्च किया है, जो window ऑब्जेक्ट में मौजूद होता है. इसमें कई फ़ंक्शन शामिल होते हैं:

  • storageFoundation.open(name): अगर दी गई फ़ाइल मौजूद है, तो उसे दिए गए नाम के साथ खोलता है और अगर ऐसा नहीं है, तो यह एक नई फ़ाइल बना देता है. ऐसी प्रॉमिस रिटर्न करता है जो खुली हुई फ़ाइल के साथ रिज़ॉल्व हो जाता है.
  • storageFoundation.delete(name): दिए गए नाम वाली फ़ाइल हटाता है. ऐसा प्रॉमिस रिटर्न करता है जो फ़ाइल को मिटाए जाने के बाद हल किया जाता है.
  • storageFoundation.rename(oldName, newName): फ़ाइल का नाम पुराने नाम से बदलकर नया नाम कर देता है. फ़ाइल का नाम बदलने के बाद, प्रॉमिस रिज़ॉल्व हो जाता है.
  • storageFoundation.getAll(): ऐसा प्रॉमिस रिटर्न करता है जो सभी मौजूदा फ़ाइल नामों के कलेक्शन के साथ रिज़ॉल्व हो जाता है.
  • storageFoundation.requestCapacity(requestedCapacity): एक्ज़ीक्यूशन के मौजूदा कॉन्टेक्स्ट के हिसाब से, इस्तेमाल के लिए नई कपैसिटी (बाइट में) का अनुरोध करता है. ऐसा प्रॉमिस दिखाता है जिसे बची हुई क्षमता के साथ हल किया जाता है.
  • storageFoundation.releaseCapacity(toBeReleasedCapacity): लागू करने के मौजूदा कॉन्टेक्स्ट से, तय की गई बाइट की संख्या रिलीज़ करता है और ऐसा प्रॉमिस देता है जो बाकी कपैसिटी के साथ रिज़ॉल्व हो जाता है.
  • storageFoundation.getRemainingCapacity(): एक प्रॉमिस प्रॉमिस करता है. यह प्रॉमिस, मौजूदा एक्ज़ीक्यूशन कॉन्टेक्स्ट के लिए उपलब्ध कपैसिटी के साथ रिज़ॉल्व हो जाता है.

फ़ाइल के हैंडल

फ़ाइलों पर ये काम किए जा सकते हैं:

  • NativeIOFile.close(): फ़ाइल को बंद करता है और ऐसा प्रॉमिस देता है जो कार्रवाई पूरी होने पर रिज़ॉल्व हो जाता है.
  • NativeIOFile.flush(): यह किसी फ़ाइल की मेमोरी वाली स्थिति को स्टोरेज डिवाइस के साथ सिंक करता है (यानी फ़्लश करता है) और ऐसा प्रॉमिस देता है जो कार्रवाई पूरी होने पर रिज़ॉल्व हो जाता है.
  • NativeIOFile.getLength(): ऐसा प्रॉमिस देता है जो फ़ाइल की लंबाई के साथ बाइट में रिज़ॉल्व हो जाता है.
  • NativeIOFile.setLength(length): फ़ाइल की लंबाई बाइट में सेट करता है और ऐसा प्रॉमिस लौटाता है जो कार्रवाई पूरी होने पर रिज़ॉल्व हो जाता है. अगर नई लंबाई मौजूदा लंबाई से कम है, तो फ़ाइल के आखिर से शुरू करके बाइट हटा दिए जाते हैं. अगर ऐसा नहीं होता है, तो फ़ाइल की वैल्यू को शून्य बाइट के साथ बढ़ा दिया जाता है.

  • NativeIOFile.read(buffer, offset): दिए गए ऑफ़सेट पर फ़ाइल की सामग्री को बफ़र के ज़रिए पढ़ता है. यह बफ़र, दिए गए बफ़र को ट्रांसफ़र करने का नतीजा होता है, जिसे बाद में अलग कर दिया जाता है. ट्रांसफ़र किए गए बफ़र और पढ़ी गई बाइट की संख्या के साथ NativeIOReadResult दिखाता है.

    NativeIOReadResult एक ऐसा ऑब्जेक्ट होता है जिसमें दो एंट्री होती हैं:

    • buffer: ArrayBufferView, यह read() को भेजे गए बफ़र को ट्रांसफ़र करने का नतीजा होता है. यह उसी टाइप का है और उसकी लंबाई सोर्स बफ़र की तरह है.
    • readBytes: buffer में पढ़ी गई बाइट की संख्या. अगर कोई गड़बड़ी होती है या अगर पढ़ने की सीमा, फ़ाइल के आखिर तक की है, तो यह बफ़र साइज़ से कम हो सकता है. अगर रीड रेंज, फ़ाइल के आखिर में है, तो यह शून्य पर सेट होती है.

  • NativeIOFile.write(buffer, offset): दिए गए बफ़र के कॉन्टेंट को, दिए गए ऑफ़सेट पर फ़ाइल में लिखता है. डेटा के लिखे जाने से पहले ही बफ़र को ट्रांसफ़र कर दिया जाता है. इसलिए, बफ़र को अलग कर दिया जाता है. ट्रांसफ़र किए गए बफ़र और सही तरीके से लिखी गई बाइट की संख्या के साथ NativeIOWriteResult दिखाता है. लिखने की सीमा से ज़्यादा होने पर फ़ाइल बड़ी कर दी जाएगी.

    NativeIOWriteResult एक ऐसा ऑब्जेक्ट होता है जिसमें दो एंट्री होती हैं:

    • buffer: एक ArrayBufferView जो write() को भेजे गए बफ़र को ट्रांसफ़र करने का नतीजा होता है. यह उसी तरह का है और इसकी लंबाई सोर्स बफ़र की तरह है.
    • writtenBytes: buffer में लिखी गई बाइट की संख्या. कोई गड़बड़ी होने पर, यह बफ़र साइज़ से कम हो सकता है.

उदाहरण पूरे करें

ऊपर बताए गए सिद्धांतों को साफ़ तौर पर समझाने के लिए, यहां दो उदाहरण दिए गए हैं. इनसे आपको स्टोरेज फ़ाउंडेशन फ़ाइलों के लाइफ़साइकल के अलग-अलग चरणों के बारे में जानकारी मिलेगी.

खोलना, लिखना, पढ़ना, बंद करना

// Open a file (creating it if needed).
const file = await storageFoundation.open('test_file');
try {
  // Request 100 bytes of capacity for this context.
  await storageFoundation.requestCapacity(100);

  const writeBuffer = new Uint8Array([64, 65, 66]);
  // Write the buffer at offset 0. After this operation, `result.buffer`
  // contains the transferred buffer and `result.writtenBytes` is 3,
  // the number of bytes written. `writeBuffer` is left detached.
  let result = await file.write(writeBuffer, 0);

  const readBuffer = new Uint8Array(3);
  // Read at offset 1. `result.buffer` contains the transferred buffer,
  // `result.readBytes` is 2, the number of bytes read. `readBuffer` is left
  // detached.
  result = await file.read(readBuffer, 1);
  // `Uint8Array(3) [65, 66, 0]`
  console.log(result.buffer);
} finally {
  file.close();
}

खोलना, लिस्टिंग करना, मिटाना

// Open three different files (creating them if needed).
await storageFoundation.open('sunrise');
await storageFoundation.open('noon');
await storageFoundation.open('sunset');
// List all existing files.
// `["sunset", "sunrise", "noon"]`
await storageFoundation.getAll();
// Delete one of the three files.
await storageFoundation.delete('noon');
// List all remaining existing files.
// `["sunrise", "noon"]`
await storageFoundation.getAll();

डेमो

नीचे दिए गए एम्बेड में, Storage Foundation API का डेमो इस्तेमाल किया जा सकता है. फ़ाइलें बनाएं, उनका नाम बदलें, उनमें लिखें, और उनमें मौजूद कॉन्टेंट को पढ़ें. साथ ही, बदलाव करने के दौरान, अपडेट के लिए अनुरोध की गई उपलब्ध जगह की जानकारी देखें. आपको Glitch के डेमो का सोर्स कोड मिल सकता है.

सुरक्षा और अनुमतियां

Chromium की टीम ने Storage Foundation API को डिज़ाइन और लागू किया है. इसके लिए, मज़बूत वेब प्लैटफ़ॉर्म की सुविधाओं का ऐक्सेस कंट्रोल करना में बताए गए मुख्य सिद्धांतों को ध्यान में रखा गया है. इन सिद्धांतों में उपयोगकर्ता के कंट्रोल, पारदर्शिता, और एर्गोनॉमिक्स शामिल हैं.

वेब पर अन्य मॉडर्न स्टोरेज एपीआई के पैटर्न के हिसाब से, Storage Foundation API का ऐक्सेस ऑरिजिन के हिसाब से होता है. इसका मतलब है कि ऑरिजिन, सिर्फ़ अपने बनाए डेटा को ऐक्सेस कर सकता है. यह सुरक्षित कॉन्टेक्स्ट तक भी सीमित होता है.

ऐप्लिकेशन पर उपयोगकर्ताओं के कंट्रोल की जानकारी

स्टोरेज कोटा का इस्तेमाल, डिस्क स्टोरेज का ऐक्सेस देने और गलत इस्तेमाल को रोकने के लिए किया जाएगा. आपको जिस मेमोरी का इस्तेमाल करना है उसका अनुरोध पहले करना होगा. अन्य Storage API की तरह, उपयोगकर्ता अपने ब्राउज़र के ज़रिए Storage Foundation API की मदद से ली गई जगह को खाली कर सकते हैं.

मददगार लिंक

स्वीकार की गई

Storage Foundation API को इमैनुअल क्रिवोय और रिचर्ड स्टोट्ज़ ने तय और लागू किया है. इस लेख की समीक्षा पीट लीपेज और जो मेडली ने की है.

Unस्प्लैश पर मार्कस स्पाइस्क की हीरो इमेज.