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

Thomas Steiner

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

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

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

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

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

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

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

Storage Foundation API के इस्तेमाल के सुझाव

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

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

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();

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

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

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

उपयोगकर्ता के कंट्रोल

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

मददगार लिंक

Acknowledgements

Storage Foundation API को Emanuel Krivoy और Richard Stotz ने बनाया और लागू किया था. इस लेख की समीक्षा पीट लेपेज और जो मेडली ने की है.

Unsplash पर Markus Spiske से ली गई हीरो इमेज.