कैसे eBay ने WebAssembly पर एक बारकोड स्कैनर किया

इसकी घोषणा के बाद से, WebAssembly तकनीक ने तुरंत फ्रंट-एंड डेवलपर्स का ध्यान आकर्षित किया है। वेब समुदाय ने उत्साह से जावास्क्रिप्ट के अलावा अन्य भाषाओं में लिखे गए ब्राउज़र में कोड चलाने के विचार को स्वीकार किया। मुख्य बात यह है कि WebAssembly जावास्क्रिप्ट की तुलना में बहुत अधिक गति की गारंटी देता है।

हमारे इंजीनियरों ने मानक के विकास का बारीकी से पालन किया। जैसे ही WebAssembly 1.0 समर्थन सभी प्रमुख ब्राउज़रों में लागू किया गया, डेवलपर्स तुरंत इसे आज़माना चाहते थे।

लेकिन एक समस्या थी। यद्यपि कई अनुप्रयोग WebAssembly से लाभान्वित होते हैं, लेकिन ई-कॉमर्स में प्रौद्योगिकी का दायरा अभी भी आदिम है। हम तुरंत इसके उपयोग का सही संस्करण नहीं खोज सके। कुछ सुझाव थे, लेकिन जावास्क्रिप्ट सभी विविधताओं में बेहतर थी। जब हम ईबे पर नई तकनीकों का मूल्यांकन करते हैं, तो पहला सवाल यह है: "हमारे ग्राहकों के लिए संभावित लाभ क्या हैं?" अगर यहां कोई स्पष्टता नहीं है, तो हम अगले कदम पर आगे नहीं बढ़ेंगे। नई फैशनेबल तकनीक के साथ काम करना बहुत आसान है, भले ही यह ग्राहकों के लिए मायने न रखता हो और केवल मौजूदा वर्कफ़्लो को जटिल करता हो। डेवलपर अनुभव की तुलना में उपयोगकर्ता अनुभव हमेशा अधिक महत्वपूर्ण होता है। लेकिन WebAssembly के साथ अलग तरह से। इस तकनीक में बहुत अधिक संभावनाएं हैं, हम अभी सही उपयोग के मामले को नहीं खोज सके हैं। हालाँकि, अंत में उन्होंने इसे पाया।

बारकोड स्कैनर

आईओएस और एंड्रॉइड पर देशी ईबे ऐप में, स्वचालित रूप से फॉर्म में प्रवेश करने के लिए एक यूपीसी बारकोड स्कैनिंग सुविधा है। यह केवल अनुप्रयोगों में काम करता है और कैमरे से छवि धारा में बारकोड अंकों को पहचानने के लिए डिवाइस पर छवियों के गहन प्रसंस्करण की आवश्यकता होती है। परिणामी कोड को फिर सर्वर सेवा में भेजा जाता है, जो बदले में फॉर्म भरता है। इसका मतलब है कि डिवाइस पर छवि प्रसंस्करण तर्क बहुत कुशल होना चाहिए। मूल अनुप्रयोगों के लिए, हमने अपनी C ++ लाइब्रेरी को iOS और Android के लिए मूल कोड में संकलित किया है। यह बारकोड को असाधारण रूप से अच्छी तरह से पहचानता है। हम धीरे-धीरे आईओएस और एंड्रॉइड में देशी एपीआई पर जा रहे हैं, लेकिन हमारी सी ++ लाइब्रेरी अभी भी विश्वसनीय है।

विक्रेताओं के लिए बारकोड स्कैनर एक सहज ज्ञान युक्त कार्य है, यह फॉर्म को भरने में काफी सरल करता है। दुर्भाग्य से, यह फ़ंक्शन साइट के मोबाइल संस्करण पर काम नहीं करता था, और विक्रेताओं को मैन्युअल रूप से यूपीसी में प्रवेश करना पड़ता था, जो असुविधाजनक है।

वेब बारकोड स्कैनर

हम वेब पर बारकोड को स्कैन करने के लिए एक विकल्प की तलाश करते थे। दो साल पहले, उन्होंने बारकोडरेडर ओपन सोर्स जावास्क्रिप्ट लाइब्रेरी पर आधारित एक प्रोटोटाइप भी जारी किया। समस्या यह थी कि इसने केवल 20% मामलों में अच्छा काम किया। शेष 80% समय स्कैनर ने बहुत धीमी गति से काम किया या बिल्कुल भी काम नहीं किया। ज्यादातर मामलों में, यह एक टाइमआउट था। यह काफी अपेक्षित है: जावास्क्रिप्ट की तुलना केवल देशी कोड के साथ गति से की जा सकती है यदि यह "हॉट पाथ" पर हो, यानी यह JIT कंपाइलरों द्वारा अत्यधिक अनुकूलित है। चाल यह है कि जावास्क्रिप्ट इंजन एक परिणाम की गारंटी के बिना एक रास्ता "गर्म" है यह निर्धारित करने के लिए कई अनुमानों का उपयोग करते हैं। इस विसंगति ने स्पष्ट रूप से उपयोगकर्ता को हताशा में डाल दिया, और हमें इस सुविधा को अक्षम करना पड़ा। लेकिन अब सब कुछ अलग है। वेब प्लेटफ़ॉर्म के तेजी से विकास के साथ, यह सवाल उठा: "क्या वेब पर एक विश्वसनीय बारकोड स्कैनर लागू करना संभव है?"

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

यह वह जगह है जहाँ WebAssembly खेल में आता है। यदि WebAssembly पर एक बारकोड स्कैनर लागू किया जाता है, तो यह काम करने की गारंटी है। WebAssembly की मजबूत टाइपिंग और बाईटेकोड संरचना आपको हमेशा निष्पादन के "गर्म रास्ते" को बनाए रखने की अनुमति देती है। इसके अलावा, हमारे पास पहले से ही देशी अनुप्रयोगों के लिए C ++ पुस्तकालय है। C ++ पुस्तकालयों WebAssembly में संकलन के लिए आदर्श उम्मीदवार हैं। हमें लगा कि समस्या का समाधान हो गया है। यह वास्तव में नहीं निकला।

आर्किटेक्चर

WebAssembly पर बारकोड स्कैनर के लिए काम करने वाला प्रोटोटाइप आर्किटेक्चर बहुत सरल था।

• E ++ cripten के साथ C ++ लाइब्रेरी को संकलित करें। यह मिडलवेयर और .wasm फ़ाइल का उत्पादन करेगा।
  
• मुख्य धागे से एक कार्यकर्ता धागा का चयन करें। कार्यकर्ता के लिए जावास्क्रिप्ट कोड उत्पन्न जावास्क्रिप्ट लिंकिंग कोड को आयात करता है, जो बदले में .wasm फ़ाइल बनाता है।
  
• मुख्य धारा कैमरे से कार्यकर्ता की स्ट्रीम में स्नैपशॉट भेजती है, और यह कनेक्टिंग कोड के माध्यम से संबंधित WASM API को कॉल करेगा। एपीआई प्रतिक्रिया मुख्य धागे को पारित की जाती है। प्रतिक्रिया एक यूपीसी स्ट्रिंग (जो बैकएंड को पास की जाती है) या खाली स्ट्रिंग हो सकती है यदि कोई बारकोड नहीं पाया गया है।
  
• एक रिक्त उत्तर के लिए, उपरोक्त चरण को दोहराया जाता है जब तक कि एक बारकोड का पता नहीं लगाया जाता है। यह चक्र सेकंड में निर्दिष्ट समय अंतराल के लिए चलता है। एक बार सीमा पार हो जाने के बाद, हम एक चेतावनी संदेश प्रदर्शित करेंगे “अमान्य उत्पाद कोड। एक अलग बारकोड या पाठ खोज का प्रयास करें । " या तो उपयोगकर्ता ने कैमरे को वास्तविक बारकोड पर केंद्रित नहीं किया, या स्कैनर पर्याप्त प्रभावी नहीं है। हम स्कैनर की गुणवत्ता के एक संकेतक के रूप में टाइमआउट पर आंकड़े ट्रैक करते हैं।

WebAssembly वर्कफ़्लो

संकलन

किसी भी WebAssembly परियोजना में पहला कदम एक स्पष्ट संकलन पाइपलाइन को परिभाषित करना है। Emscripten WebAssembly को संकलित करने के लिए वास्तविक मानक बन गया है, लेकिन एक सुसंगत वातावरण का होना महत्वपूर्ण है जो एक नियतात्मक परिणाम उत्पन्न करता है। हमारा दृश्य Node.js पर आधारित है, इसलिए हमें npm वर्कफ़्लो के साथ संगत समाधान खोजने की आवश्यकता है। सौभाग्य से, उस समय के आसपास, सूरमा दास ने "एम्सस्क्रिप्टेन और एनपीएम" नामक एक लेख प्रकाशित किया। WebAssembly को संकलित करने के लिए Docker- आधारित दृष्टिकोण समझ में आता है क्योंकि यह एक टन ओवरहेड को समाप्त करता है। जैसा कि लेख में सिफारिश की गई है, हमने ट्रेज़ेकी से एम्सस्क्रिप्टेन की डॉकटर छवि ली । WebAssembly में संकलन सक्षम करने के लिए, देशी C ++ लाइब्रेरी को थोड़ा मोड़ना पड़ा। असल में, हमने यादृच्छिक, परीक्षण और त्रुटि पर काम किया। अंत में, मैं इसे संकलित करने में कामयाब रहा, और मौजूदा विधानसभा पाइपलाइन के भीतर एक साफ WebAssembly कार्यप्रवाह भी स्थापित किया।

यह तेजी से काम करता है, लेकिन ...

स्कैनर प्रदर्शन को वासेम एपीआई प्रति सेकंड द्वारा संसाधित फ्रेम की संख्या से मापा जाता है। वासम एपीआई कैमरे की वीडियो स्ट्रीम से एक फ्रेम लेता है, गणना करता है और एक प्रतिक्रिया देता है। यह एक निरंतर आधार पर किया जाता है जब तक कि एक बारकोड का पता नहीं लगाया जाता है। प्रदर्शन को एफपीएस में मापा जाता है।

WebAssembly के हमारे परीक्षण कार्यान्वयन ने 50 एफपीएस की एक अद्भुत गति दिखाई। हालाँकि, इसने केवल 60% मामलों में काम किया, और बाकी समय में यह दुर्घटनाग्रस्त हो गया। इस तरह के उच्च एफपीएस के साथ, वे शेष 40% स्कैन के लिए बारकोड का जल्दी से पता नहीं लगा सके, अंत में एक चेतावनी संदेश दे रहे हैं। इसकी तुलना में, पिछला जावास्क्रिप्ट कार्यान्वयन आमतौर पर 1 एफपीएस पर चलता था। हां, WebAssembly बहुत तेज (50 गुना) है, लेकिन किसी कारण से यह लगभग आधे मामलों में काम नहीं करता है। यह भी ध्यान दिया जाना चाहिए कि कुछ स्थितियों में जावास्क्रिप्ट ने बहुत अच्छी तरह से काम किया और तुरंत बारकोड पाया। स्पष्ट विकल्पों में से एक टाइमआउट को बढ़ाना था, लेकिन यह केवल उपयोगकर्ताओं की निराशा को बढ़ाएगा, और इसलिए हम वास्तविक समस्या को हल नहीं करते हैं। इसलिए, हमने इस विचार को त्याग दिया।

सबसे पहले, हम यह नहीं समझ सके कि देशी C ++ लाइब्रेरी, जो पूरी तरह से देशी अनुप्रयोगों में काम करती है, वेब पर समान परिणाम नहीं दिखाती है। लंबी परीक्षण और डिबगिंग के बाद, हमने पाया कि मान्यता की गति ऑब्जेक्ट के फोकस कोण और पृष्ठभूमि छाया पर निर्भर करती है। लेकिन फिर देशी अनुप्रयोगों में सब कुछ कैसे काम करता है? तथ्य यह है कि मूल अनुप्रयोगों में हम ऑटोफोकस के लिए अंतर्निहित एपीआई का उपयोग करते हैं और उपयोगकर्ता को बारकोड पर उंगली से मैन्युअल रूप से ध्यान केंद्रित करने का अवसर प्रदान करते हैं। इसलिए, मूल एप्लिकेशन हमेशा उच्च गुणवत्ता वाले स्पष्ट चित्रों के साथ पुस्तकालय प्रदान करते हैं।

जो हो रहा है, उसके सार को महसूस करते हुए, हमने एक और देशी पुस्तकालय की कोशिश करने का फैसला किया: एक काफी लोकप्रिय और स्थिर ओपन-सोर्स ज़बर बारकोड स्कैनर। इससे भी महत्वपूर्ण बात, यह धुंधली और दानेदार छवियों के साथ अच्छी तरह से काम करता है। इसे क्यों न दें? चूंकि हमारे पास पहले से ही WebAssembly वर्कफ़्लो था, इसलिए WebAssembly में ZBar का संकलन और तैनाती सुचारू रूप से हुई। प्रदर्शन लगभग 15 एफपीएस के आसपास सभ्य था, हालांकि हमारे सी ++ लाइब्रेरी के रूप में उतना अच्छा नहीं था। लेकिन उसी समय के लिए सफलता की दर 80% के करीब थी। हमारे C ++ लाइब्रेरी पर एक स्पष्ट सुधार, लेकिन अभी भी 100% नहीं।

परिणाम ने हमें अभी तक संतुष्ट नहीं किया, लेकिन हमने कुछ अप्रत्याशित देखा। जहां ज़बर दुर्घटनाग्रस्त हो गया, हमारे अपने सी ++ लाइब्रेरी ने बहुत जल्दी काम किया। यह एक सुखद आश्चर्य था। ऐसा लगता है कि पुस्तकालयों ने विभिन्न तरीकों की छवियों को विभिन्न तरीकों से संसाधित किया है। यह हमें इस विचार की ओर ले गया।

मल्टीथ्रेडिंग और स्पीड रेसिंग

आप शायद पहले ही समझ गए हैं। दो श्रमिक सूत्र क्यों न बनाएं: एक ज़बर के लिए और दूसरा हमारे सी ++ लाइब्रेरी के लिए, और उन्हें समानांतर में न चलाएं। जो भी जीता (जिसने पहले एक वैध बारकोड भेजा है) परिणाम को मुख्य धारा में भेजता है, और दोनों श्रमिक बंद हो जाते हैं। हमने इस तरह के परिदृश्य को लागू किया और खुद को परखना शुरू किया, जितना संभव हो उतने परिदृश्यों को अनुकरण करने की कोशिश की। इस सेटिंग ने 95% सफल स्कैन दिखाए। पिछले परिणामों की तुलना में बहुत बेहतर है, लेकिन अभी भी 100% नहीं है।

अजीब सुझावों में से एक प्रतियोगिता में मूल JavaScipt पुस्तकालय को जोड़ना था। यह तीन धाराएं होंगी। हमने ईमानदारी से नहीं सोचा था कि इससे कुछ भी बदल जाएगा। लेकिन इस तरह के परीक्षण के लिए किसी भी प्रयास की आवश्यकता नहीं थी, क्योंकि हमने कामकाजी इंटरफ़ेस को मानकीकृत किया था। हमारे आश्चर्य के लिए, तीन धाराओं के साथ, सफलता दर वास्तव में 100% के करीब आई। यह फिर से पूरी तरह से अप्रत्याशित था। जैसा कि पहले उल्लेख किया गया है, जावास्क्रिप्ट ने कुछ स्थितियों में बहुत अच्छा काम किया। जाहिर है, उसने अंतर को बंद कर दिया। तो कानून का लोकप्रिय ज्ञान "जावास्क्रिप्ट हमेशा जीतता है । " यदि चुटकुले के बिना, निम्नलिखित चित्रण अंतिम वास्तुकला का अवलोकन प्रदान करता है जिसे हमने लागू किया है।


वेब आर्किटेक्चर बारकोड स्कैनर

निम्न आंकड़ा एक उच्च-स्तरीय कार्यात्मक आरेख दिखाता है:


एक बारकोड स्कैनर के कार्यात्मक आरेख

संसाधन लोड हो रहा है ध्यान दें

स्कैनर के काम करने के लिए आवश्यक संसाधन मुख्य पृष्ठ को रेंडर करने के बाद प्रीलोडेड होते हैं। इस तरह, लैंडिंग पृष्ठ जल्दी से लोड होता है और बातचीत के लिए तैयार होता है। WebAssembly संसाधन (wasm फाइलें और मिडलवेयर स्क्रिप्ट) और जावास्क्रिप्ट स्कैनर लाइब्रेरी मुख्य पृष्ठ लोड करने के बाद XMLHttpRequest का उपयोग करके लोड और कैश की जाती हैं। यहां यह महत्वपूर्ण है कि पृष्ठ के साथ उपयोगकर्ता इंटरैक्शन के लिए मुख्य थ्रेड को छोड़ने के लिए उन्हें तुरंत निष्पादित नहीं किया जाता है। निष्पादन केवल तब होता है जब उपयोगकर्ता बारकोड आइकन पर क्लिक करता है। यदि उपयोगकर्ता संसाधनों को लोड करने से पहले आइकन पर क्लिक करते हैं, तो उन्हें मांग पर लोड किया जाएगा और तुरंत निष्पादित किया जाएगा। बारकोड स्कैनर ईवेंट हैंडलर और वर्कर कंट्रोलर पेज के साथ लोड होते हैं, लेकिन वे बहुत छोटे होते हैं।

परिणाम

कर्मचारियों द्वारा कठोर परीक्षण और आंतरिक उपयोग के बाद, हमने उपयोगकर्ताओं पर ए / बी परीक्षण शुरू किया। स्कैनर आइकन (नीचे स्क्रीनशॉट) परीक्षण समूह को दिखाया गया था, लेकिन नियंत्रण समूह को नहीं।


अंतिम उत्पाद

सफलता को मापने के लिए, हमने ड्राफ्ट कम्प्लीशन रेट मीट्रिक पेश किया। यह ड्राफ्ट संपादित करने और फॉर्म जमा करने के बीच का समय है। मीट्रिक को यह दिखाना चाहिए कि बारकोड स्कैनर लोगों को फ़ॉर्म भरने में कैसे मदद करता है। परीक्षण कई हफ्तों तक चला, और परिणाम बहुत सुखद थे। वे पूरी तरह से हमारी मूल परिकल्पना के अनुरूप हैं। एक बारकोड स्कैनर के साथ स्ट्रीम के लिए ड्राफ्ट पूरा होने का समय 30% तक कम हो गया।


ए / बी टेस्ट परिणाम

हमने सभी प्रकार के स्कैनर की प्रभावशीलता का मूल्यांकन करने के लिए प्रोफाइलिंग को भी जोड़ा। जैसा कि अपेक्षित था, सबसे बड़ा योगदान ज़बर (53% सफल स्कैन) द्वारा किया गया था, फिर हमारी सी ++ लाइब्रेरी (34%) और अंत में, जावास्क्रिप्ट लाइब्रेरी 13% थी।

निष्कर्ष

WebAssembly को लागू करने का अनुभव हमारे लिए बहुत जानकारीपूर्ण हो गया है। नई तकनीकों के उद्भव को लेकर इंजीनियर बहुत खुश हैं और तुरंत उन्हें आज़माना चाहते हैं। यदि तकनीक ग्राहकों के लिए भी उपयोगी है, तो यह एक दोहरी खुशी है। आइए लेख की शुरुआत में व्यक्त विचार को दोहराएं। प्रौद्योगिकी बहुत तेज गति से विकसित हो रही है। हर दिन कुछ नया दिखाई देता है। लेकिन ग्राहकों के लिए कुछ ही प्रौद्योगिकियां मायने रखती हैं, और WebAssembly उनमें से एक है। इस अभ्यास से हमारा सबसे बड़ा निष्कर्ष यह है कि 99 स्थितियों में "नहीं" और केवल मामले में "हां" कहना जब यह वास्तव में ग्राहकों के लिए महत्वपूर्ण है।

भविष्य में, हम एक बारकोड स्कैनर के उपयोग का विस्तार करने और इसे खरीदारों की ओर से पेश करने की योजना बनाते हैं, ताकि वे ईबे पर खोज और खरीद के लिए उत्पाद कोड ऑफ़लाइन स्कैन कर सकें। हम ब्राउज़र में शेप डिटेक्शन एपीआई और अन्य फ़ंक्शन का उपयोग करके फ़ंक्शन का विस्तार करने पर भी विचार करेंगे। लेकिन हम eBay पर WebAssembly के लिए सही उपयोग के मामले को पाकर खुश हैं और ई-कॉमर्स में तकनीक को सफलतापूर्वक लागू किया है।

WebAssembly पर कई लेखों के लिए सूरमा दास और लिन क्लार्क को विशेष धन्यवाद। उन्होंने वास्तव में कई बार गतिरोध को तोड़ने में हमारी मदद की।