इव्हेंट-फोटो ॲप्सच्या डेव्हलपर्सकडे आता गर्दीच्या ठिकाणी ब्राउझर अपलोड्स जिवंत ठेवण्यासाठी एक ठोस चेकलिस्ट आहे. एक वापरकर्ता वाय-फायवरून सेल्युलरवर स्विच करू शकतो, तर डझनभर उपकरणे एकाच हॉटस्पॉटसाठी स्पर्धा करत असतात. पाहुणा फोन लॉक केला किंवा नेटवर्कमध्ये अडथळा आला तरी, “upload complete” toast आल्यानंतर फोटो गायब होऊ नये यासाठी हे मार्गदर्शक कसे कार्य करते ते यात दाखवले आहे.
लग्नसमारंभ आणि उत्सवांमध्ये सामान्य अपलोड्स का अपयशी ठरतात
ऑफिसमध्ये लॅपटॉप एका स्थिर इथरनेट लिंकवर असतो आणि एक वापरकर्ता “send” वर क्लिक करतो. लग्नाच्या रिसेप्शनमध्ये किंवा म्युझिक फेस्टिव्हलमध्ये, हीच कृती समस्यांची मालिका सुरू करू शकते: पाहुणा समारंभ हॉलमधून पार्किंग लॉटमध्ये जातो, शेकडो फोनमुळे राउटरवर ताण येतो, किंवा फोन वाय-फाय सोडून सेल्युलरवर स्विच होतो. ब्राउझरने सर्व डेटा सर्व्हरला स्ट्रीम केला असेल, पण सर्व्हरने अद्याप फाईल स्टोरेजमध्ये सेव्ह केलेली नसू शकते. जर प्रोग्रेस बार १००% होताच UI ने यश घोषित केले, तर पाहुणा फोटो डिलीट करू शकतो, ज्यामुळे आयोजकाकडे फाईल अपूर्ण राहते.
"फक्त अपलोड करा" या दृष्टिकोनाचा छुपा खर्च
एक साधी पद्धत अपलोडला एक सिंगल HTTP POST मानते. जेव्हा कनेक्शन स्थिर असते तेव्हा हे काम करते, परंतु गर्दीच्या नेटवर्कमध्ये प्रत्येक व्यत्ययामुळे संपूर्ण फाईल पुन्हा सुरुवातीपासून पाठवावी लागते. डझनभर फोन एकाच वेळी पुन्हा प्रयत्न (retry) करत असताना वापरकर्ते त्रस्त होतात आणि बँडविड्थमध्ये अचानक वाढ होते. फाईलचे तुकडे (chunks) करणे आणि प्रत्येक तुकड्याचा मागोवा घेणे यामुळे गुंतागुंत वाढते, परंतु त्याचा फायदा असा होतो की नेटवर्क बदलले तरी डेटा ट्रान्सफर वेधण्यायोग्य आणि कमी ओव्हरहेडसह यशस्वी होते.
रिझ्युमेबल, चंक्ड अपलोड सिस्टम तयार करणे
खाली एक व्यावहारिक, स्टेप-बाय-स्टेप रेसिपी दिली आहे.
1. कोणताही डेटा ब्राउझरमधून बाहेर जाण्यापूर्वी अपलोड ID तयार करा
स्थानिक पातळीवर एक युनिव्हर्सली युनिक आयडेंटिफायर (UUID) तयार करा आणि पहिल्या विनंती (request) म्हणून तो सर्व्हरला पाठवा. सर्व्हर त्या ID अंतर्गत एक सेशन रेकॉर्ड करतो. जर नंतर टाइमआउटमुळे ब्राउझरने पुन्हा प्रयत्न केला, तर तो तोच UUID समाविष्ट करतो, ज्यामुळे सर्व्हरला सेशन ओळखता येते आणि डुप्लिकेट एन्ट्री टाळता येते. यामुळे वर्कफ्लो 'idempotent' बनतो—म्हणजेच एकच विनंती पुन्हा केल्याने कोणताही प्रतिकूल परिणाम होत नाही.
2. फाईलचे ५ – १० MB च्या तुकड्यांमध्ये (chunks) विभाजन करा
चंक साईज (Chunk size) हा एक समतोल राखण्याचा विषय आहे. लहान चंक्स (१ MB पेक्षा कमी) मुळे HTTP विनंत्यांची संख्या आणि संबंधित हेडर ओव्हरहेड वाढतो. खूप मोठे चंक्स कोणताही व्यत्यय आल्यास महाग पडतात कारण क्लायंटला मोठा भाग पुन्हा पाठवावा लागतो. सामान्य फोटो आणि लहान व्हिडिओसाठी, ५ – १० MB हा एक चांगला समतोल आहे: प्रत्येक विनंती UI प्रतिसादक्षम ठेवण्यासाठी पुरेशी वेगाने पूर्ण होते आणि विनंत्यांची संख्याही नियंत्रणात राहते.
3. समांतर (parallel) अपलोड्सची संख्या मर्यादित करा
मोबाईल ब्राउझर अनेक कनेक्शन्स उघडू शकतात, परंतु गर्दीच्या वाय-फाय नेटवर्कवर प्रत्येक अतिरिक्त स्ट्रीम मर्यादित बँडविड्थसाठी स्पर्धा करते. आठ स्पर्धात्मक स्ट्रीम्सपेक्षा दोन स्थिर स्ट्रीम्स अधिक चांगल्या ठरतात. कमी बँडविड्थची स्थिती ओळखण्यासाठी आणि कॉनकरन्सी (concurrency) आपोत्ता कमी करण्यासाठी navigator.connection API वापरा.
4. IndexedDB मध्ये अपलोडची स्थिती जतन करा
अपलोड ID, आधीच पाठवलेल्या चंक्सची यादी आणि सर्व्हरने मान्य केलेले ऑफसेट्स (offsets) ब्राउझरच्या IndexedDB मध्ये साठवा. जर पेज रीलोड झाले किंवा वापरकर्त्याने टॅब बंद केला, तर क्लायंट पुढच्या वेळी लोड करताना ही स्थिती पुन्हा मिळवू शकतो. जेव्हा वापरकर्ता पेज पुन्हा उघडतो, तेव्हा त्यांना तीच फाईल निवडण्यास सांगा; साठवलेल्या मेटाडेटामुळे अपलोड पुन्हा सुरुवातीपासून सुरू करण्याऐवजी शेवटच्या कन्फर्म केलेल्या चंकपासून पुढे सुरू करता येते.
5. केवळ navigator.onLine नाही, तर नेटवर्कमधील वास्तविक बदल ओळखा
navigator.onLine फ्लॅग अनेकदा कनेक्शन वापरण्यायोग्य नसतानाही “online” दर्शवतो. त्याऐवजी, प्रत्येक चंकसाठी एक छोटा रिक्वेस्ट टाइमआउट (उदा. ५ सेकंद) सेट करा. जर टाइमआउट झाला, तर नेटवर्क बंद असल्याचे समजा. जेव्हा कनेक्टिव्हिटी परत येईल, तेव्हा सर्व्हरला त्याच्याकडे आधीच असलेल्या चंक्सच्या यादीबद्दल विचारा आणि त्यानंतर फक्त गहाळ असलेले तुकडे अपलोड करणे सुरू करा. यामुळे थोड्या वेळाच्या खंडानंतर डुप्लिकेट डेटा पाठवणे टाळता येते.
6. रिट्रायसाठी (retries) 'jitter' सह 'exponential backoff' वापरा
जेव्हा अनेक पाहुण्यांच्या उपकरणांना नेटवर्क परत आल्याचे समजते, तेव्हा ते सर्व एकाच वेळी रिट्राय करू शकतात, ज्यामुळे सर्व्हरवर ताण येऊ शकतो. 'Exponential backoff' मुळे प्रत्येक रिट्राय मागील रिट्रायपेक्षा जास्त वेळ थांबतो, तर 'jitter' एक यादृच्छिक (random) छोटा फरक जोडतो. या संयोगामुळे रिट्राय ट्रॅफिक काही सेकंदात विभागले जाते, ज्यामुळे अचानक येणारा ताण (spike) टाळता येतो.
7. स्तरित (layered) आणि सुलभ फीडबॅक दाखवा
तीन-स्तरीय स्टेटस बार फाईलची वास्तविक स्थिती दर्शवतो:
- Received – सर्व्हरने प्रत्येक चंक साठवला आहे आणि फाईल पूर्ण म्हणून मार्क केली आहे.
- Preparing – सर्व्हर थंबनेल्स तयार करत आहे किंवा व्हिडिओ ट्रान्सकोड करत आहे.
- Available – आयोजक फाईल पाहू किंवा डाउनलोड करू शकतात.
केवळ रंगावर अवलंबून राहणे टाळा; आयकॉन्ससोबत थोडा मजकूर जोडा जेणेकरून स्क्रीन-रीडर वापरकर्त्यांनाही प्रगती समजेल.
अजून काय चुकीचे होऊ शकते?
उत्तमरीत्या तयार केलेले resumable upload देखील काही edge cases मध्ये अडखळू शकते.
पुढे कशाकडे लक्ष द्यावे
वेब प्लॅटफॉर्म विकसित होत आहे.
मुख्य निष्कर्ष
प्रत्येक भाग ट्रॅक करणारा, स्टेट (state) स्थानिक पातळीवर साठवणारा आणि हुशारीने पुन्हा प्रयत्न (retry) करणारा resumable, chunked upload, अस्थिर नेटवर्कला पाहुण्यांच्या फोटोंसाठी एक विश्वसनीय माध्यम बनवतो. वरील चेकलिस्टची अंमलबजावणी करा.