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

Thomas Steiner
Thomas Steiner

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

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

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

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

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

  • इनमें से कुछ विकल्प, इस प्रस्त���व से मेल नहीं खाते. ऐसा इसलिए है, क्योंकि इनमें बहुत कम डेटा सेव करने की अनुमति होती है. जैसे, कुकी या sessionStorage और localStorage मेकेनिज्म वाले वेब स्टोरेज एपीआई.
  • फ़ाइल और डायरेक्ट्री एंट्री एपीआई या WebSQL जैसे अन्य विकल्प, पहले से ही कई वजहों से बंद कर दिए गए हैं.
  • File System Access API का एपीआई, FileSystem 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();

डेमो

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

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

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

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

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

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

मदद के लिए लिंक

धन्यवाद

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

Unsplash पर Markus Spiske की दी गई हीरो इमेज.