ఈవెంట్-ఫోటో యాప్ల డెవలపర్లకు ఇప్పుడు రద్దీగా ఉన్న వేదికల వద్ద బ్రౌజర్ అప్లోడ్లను నిరంతరాయంగా కొనసాగించడానికి ఒక స్పష్టమైన చెక్లిస్ట్ అందుబాటులో ఉంది. ఒకే వినియోగదారు Wi-Fi నుండి సెల్యులార్ నెట్వర్క్కు మారవచ్చు, అదే సమయంలో డజన్ల కొద్దీ పరికరాలు ఒకే హాట్స్పాట్ కోసం పోటీ పడవచ్చు. అతిథి ఫోన్ను లాక్ చేసినా లేదా నెట్వర్క్ అంతరాయం కలిగినా, “upload complete” అని మెసేజ్ వచ్చిన తర్వాత కూడా ఫోటో మాయం కాకుండా ఎలా నిరోధించాలో ఈ గైడ్ చూపుతుంది.
పెళ్లిళ్లు మరియు పండుగలలో సాధారణ అప్లోడ్లు ఎందుకు విఫలమవుతాయి
ఆఫీసులో ఒక లాప్టాప్ స్థిరమైన ఈథర్నెట్ (Ethernet) లింక్పై ఉంటుంది మరియు ఒకే వినియోగదారు “send” క్లిక్ చేస్తారు. కానీ పెళ్లి వేడుక లేదా మ్యూజిక్ ఫెస్టివల్లో, అదే చర్య అనేక సమస్యలకు దారితీయవచ్చు: అతిథి సెర్మనీ హాల్ నుండి పార్కింగ్ లాట్ వరకు నడవవచ్చు, వందలాది ఫోన్ల వల్ల రూటర్ భారం పెరగవచ్చు, లేదా ఫోన్ Wi-Fi నుండి సెల్యులార్ నెట్వర్క్కు మారవచ్చు. బ్రౌజర్ ప్రతి బైట్ను సర్వర్కు పంపించి ఉండవచ్చు, కానీ సర్వర్ ఇంకా ఆ ఫైల్ను స్టోరేజ్లో భద్రపరచలేకపోవచ్చు. ప్రోగ్రెస్ బార్ 100% చేరుకోగానే UI విజయవంతమైందని చెబితే, అతిథి ఆ ఫోటోను డిలీట్ చేయవచ్చు, దీనివల్ల ఆర్గనైజర్కు ఫైల్ లభించకుండా పోతుంది.
“కేవలం అప్లోడ్ చేయండి” అనే విధానంలోని దాగి ఉన్న నష్టం
ఒక సాధారణ విధానం అప్లోడ్ను ఒకే HTTP POST గా పరిగణిస్తుంది. కనెక్షన్ స్థిరంగా ఉన్నప్పుడు ఇది పనిచేస్తుంది, కానీ రద్దీగా ఉన్న నెట్వర్క్లో ప్రతి అంతరాయం వల్ల మొత్తం ఫైల్ను మొదటి నుండి మళ్ళీ పంపాల్సి వస్తుంది. డజన్ల కొద్దీ ఫోన్లు ఒకేసారి మళ్ళీ ప్రయత్నించినప్పుడు వినియోగదారులు అసహనానికి గురవుతారు మరియు బ్యాండ్విడ్త్ అకస్మాత్తుగా పెరుగుతుంది. ఫైల్ను చంక్స్గా (chunks) విభజించి, ప్రతి భాగాన్ని ట్రాక్ చేయడం వల్ల సంక్లిష్టత పెరుగుతుంది, కానీ నెట్వర్క్ మార్పులను తట్టుకుని, తక్కువ ఓవర్హెడ్తో అప్లోడ్ పూర్తయ్యేలా చేస్తుంది.
తిరిగి ప్రారంభించగలిగే (resumable), చంక్డ్ (chunked) అప్లోడ్ సిస్టమ్ను నిర్మించడం
క్రింద ఒక ఆచరణాత్మకమైన, దశలవారీ విధానం ఉంది.
1. డేటా బ్రౌజర్ నుండి బయటకు వెళ్లేముందే అప్లోడ్ IDని రూపొందించండి
లోకల్గా ఒక యూనివర్సల్ యూనిక్ ఐడెంటిఫైయర్ (UUID)ని సృష్టించి, మొదటి రిక్వెస్ట్గా దానిని సర్వర్కు పంపండి. సర్వర్ ఆ ID కింద ఒక సెషన్ను రికార్డ్ చేస్తుంది. ఒకవేళ టైమ్ అవుట్ (timeout) కారణంగా బ్రౌజర్ మళ్ళీ ప్రయత్నిస్తే, అది అదే UUIDని ఉపయోగిస్తుంది, తద్వారా సర్వర్ ఆ సెషన్ను గుర్తించి డూప్లికేట్ ఎంట్రీని నివారిస్తుంది. ఇది వర్క్ఫ్లోను ఐడెంపోటెంట్ (idempotent) చేస్తుంది—అంటే ఒకే రిక్వెస్ట్ను మళ్ళీ మళ్ళీ పంపినా ఎటువంటి ప్రతికూల ప్రభావం ఉండదు.
2. ఫైల్ను 5 – 10 MB చంక్స్గా విభజించండి
చంక్ సైజ్ అనేది ఒక సమతుల్యత (trade-off). చిన్న చంక్స్ (1 MB కంటే తక్కువ) ఉపయోగిస్తే HTTP రిక్వెస్ట్ల సంఖ్య మరియు హెడర్ ఓవర్హెడ్ పెరుగుతుంది. చాలా పెద్ద చంక్స్ ఉపయోగిస్తే, ఏదైనా అంతరాయం కలిగినప్పుడు క్లయింట్ పెద్ద భాగాన్ని మళ్ళీ పంపాల్సి రావడం వల్ల నష్టం ఎక్కువ అవుతుంది. సాధారణ ఫోటోలు మరియు చిన్న వీడియోల కోసం, 5 – 10 MB అనేది సరైన సమతుల్యతను అందిస్తుంది: ప్రతి రిక్వెస్ట్ UIని వేగంగా ఉంచేంత త్వరగా పూర్తవుతుంది, అదే సమయంలో రిక్వెస్ట్ల సంఖ్య కూడా నియంత్రణలో ఉంటుంది.
3. సమాంతర (parallel) అప్లోడ్ల సంఖ్యను పరిమితం చేయండి
మొబైల్ బ్రౌజర్లు అనేక కనెక్షన్లను తెరవగలవు, కానీ రద్దీగా ఉన్న Wi-Fi నెట్వర్క్లో ప్రతి అదనపు స్ట్రీమ్ పరిమిత బ్యాండ్విడ్త్ కోసం పోటీ పడుతుంది. ఎనిమిది పోటీ స్ట్రీమ్ల కంటే రెండు స్థిరమైన స్ట్రీమ్లు మెరుగ్గా పనిచేస్తాయి. తక్కువ బ్యాండ్విడ్త్ పరిస్థితులను గుర్తించడానికి మరియు ఆటోమేటిక్గా కన్కరెన్సీని (concurrency) తగ్గించడానికి navigator.connection APIని ఉపయోగించండి.
4. IndexedDBలో అప్లోడ్ స్థితిని భద్రపరచండి
అప్లోడ్ ID, ఇప్పటికే పంపిన చంక్స్ జాబితా మరియు సర్వర్ ధృవీకరించిన ఆఫ్సెట్లను (offsets) బ్రౌజర్ యొక్క IndexedDBలో నిల్వ చేయండి. పేజీ రీలోడ్ అయినా లేదా వినియోగదారు ట్యాబ్ను మూసివేసినా, తదుపరి లోడ్ సమయంలో క్లయింట్ ఆ స్థితిని తిరిగి పొందగలదు. వినియోగదారు పేజీని మళ్ళీ తెరిచినప్పుడు, అదే ఫైల్ను ఎంచుకోమని వారికి సూచించండి; నిల్వ చేయబడిన మెటాడేటా వల్ల అప్లోడ్ మొదటి నుండి ప్రారంభించకుండా, చివరిగా ధృవీకరించబడిన చంక్ నుండి కొనసాగుతుంది.
5. కేవలం navigator.onLine మాత్రమే కాకుండా, నిజమైన నెట్వర్క్ మార్పులను గుర్తించండి
కనెక్షన్ ఉపయోగపడనప్పుడు కూడా navigator.onLine ఫ్లాగ్ తరచుగా “online” అని చూపిస్తుంది. దానికి బదులుగా, ప్రతి చంక్ కోసం తక్కువ సమయం ఉండే రిక్వెస్ట్ టైమ్ అవుట్ (ఉదాహరణకు 5 సెకన్లు) సెట్ చేయండి. టైమ్ అవుట్ జరిగితే, నెట్వర్క్ అందుబాటులో లేదని భావించండి. కనెక్టివిటీ తిరిగి వచ్చినప్పుడు, సర్వర్లో ఇప్పటికే ఉన్న చంక్స్ జాబితాను అడిగి తెలుసుకోండి, ఆపై మిగిలిన భాగాలను మాత్రమే అప్లోడ్ చేయండి. దీనివల్ల నెట్వర్క్ అంతరాయం తర్వాత డూప్లికేట్ డేటాను పంపడం నివారించబడుతుంది.
6. రీట్రైల కోసం జిట్టర్తో (jitter) ఎక్స్పోనెన్షియల్ బ్యాక్ఆఫ్ (exponential backoff)ను ఉపయోగించండి
నెట్వర్క్ తిరిగి వచ్చినప్పుడు చాలా మంది అతిథుల పరికరాలు ఒకే సమయంలో రీట్రైలను ప్రారంభిస్తే, అది సర్వర్పై విపరీతమైన భారాన్ని పెంచుతుంది. ఎక్స్పోనెన్షియల్ బ్యాక్ఆఫ్ ప్రతి రీట్రైని అంతకుముందు కంటే ఎక్కువ సమయం వేచి ఉండేలా చేస్తుంది, జిట్టర్ (jitter) అనేది ఒక చిన్న రాండమ్ సమయాన్ని జోడిస్తుంది. ఈ కలయిక రీట్రై ట్రాఫిక్ను కొన్ని సెకన్ల పాటు విస్తరించి, అకస్మాత్తుగా పెరిగే లోడ్ను నివారిస్తుంది.
7. వివిధ స్థాయిల ఫీడ్బ్యాక్ను చూపండి
మూడు స్థాయిల స్టేటస్ బార్ ఫైల్ యొక్క అసలు స్థితిని తెలియజేస్తుంది:
- Received – సర్వర్ ప్రతి చంక్ను భద్రపరిచింది మరియు ఫైల్ను పూర్తయినట్లుగా గుర్తించింది.
- Preparing – సర్వర్ థంబ్నెయిల్స్ను రూపొందిస్తోంది లేదా వీడియోను ట్రాన్స్కోడింగ్ (transcoding) చేస్తోంది.
- Available – ఆర్గనైజర్ ఫైల్ను చూడవచ్చు లేదా డౌన్లోడ్ చేసుకోవచ్చు.
కేవలం రంగుపై మాత్రమే ఆధారపడకండి; స్క్రీన్-రీడర్ వినియోగదారులు కూడా పురోగతిని అర్థం చేసుకునేలా ఐకాన్లతో పాటు చిన్న వచనాన్ని జోడించండి.
ఇంకా ఏమి తప్పులు జరగవచ్చు?
చక్కగా రూపొందించబడిన రీస్యూమబుల్ అప్లోడ్ కూడా కొన్ని అసాధారణ పరిస్థితులలో (edge cases) ఇబ్బందులను ఎదుర్కోవచ్చు.
తదుపరి ఏమి గమనించాలి?
వెబ్ ప్లాట్ఫారమ్ నిరంతరం అభివృద్ధి చెందుతోంది.
ముఖ్య అంశం
ప్రతి భాగాన్ని ట్రాక్ చేసే, స్టేట్ను స్థానికంగా నిల్వ చేసే మరియు తెలివిగా మళ్ళీ ప్రయత్నించే రీస్యూమబుల్, చంక్డ్ అప్లోడ్, అస్థిరమైన ఈవెంట్ నెట్వర్క్ను అతిథుల ఫోటోల కోసం నమ్మదగిన మార్గంగా మారుస్తుంది. పైన పేర్కొన్న చెక్లిస్ట్ను అమలు చేయండి.