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

थॉमस स्टेनर
थॉमस स्टेनर
Twitter GitHub Glitch Mastodon होम पेज

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

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

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

वेब को किसी अन्य स्टोरेज एपीआई की ज़रूरत क्यों होती है?

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

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

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 में लिखे गए बाइट की संख्या. कोई गड़बड़ी होने पर, इसका साइज़ बफ़र साइज़ से कम हो सकता है.

सभी उदाहरण

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

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

// 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 Foundation API को इमैनुअल क्रिवोय और रिचर्ड स्टॉट्ज़ ने तय और लागू किया. इस लेख की समीक्षा पीट लेपेज और जो मेडली ने की है.

Unsplash पर मार्कस स्पिन की मदद से खींची गई हीरो इमेज.