हमारी वेबसाइट क्रॉलर का निर्माण: एक झलक Weglot की तकनीक

अनेक Weglot उपयोगकर्ता यह सुनिश्चित करना चाहते हैं कि उनकी वेबसाइट के सभी URL का सटीक अनुवाद किया गया हो ( Weglot द्वारा दिए गए मशीन अनुवाद की पहली परत के बाद )। कई लोगों के लिए, यदि आपकी एक बड़ी वेबसाइट है, जिसका कई भाषाओं में अनुवाद किया गया है, तो यह समय लेने वाला हो सकता है।

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

इसलिए, हमें पता था कि इस क्षेत्र में सुधार की गुंजाइश है। हम अपने उपयोगकर्ताओं को अधिक आसानी से बोर्ड पर लाने में मदद कर सकते थे और उनकी परियोजनाओं को अधिक तेज़ी से और अधिक कुशलता से प्रबंधित कर सकते थे, लेकिन एकमात्र समस्या यह थी कि हमारे पास अभी तक कोई समाधान नहीं था।

जैसा कि आप पहले ही अनुमान लगा चुके होंगे...इससे URL प्रबंधित करने की सुविधा जारी हुई, जिससे उपयोगकर्ता अपनी वेबसाइट के URL को स्कैन कर सकते हैं और वहां से अपनी अनुवादित सामग्री तैयार कर सकते हैं। Weglot डैशबोर्ड, तेज और कुशलतापूर्वक।

हाल ही में, इस सुविधा को अनुवाद सूची से नए URL द्वारा अनुवाद प्रबंधन पृष्ठ पर ले जाया गया है, जहां इसे और भी अधिक लचीला और शक्तिशाली बना दिया गया है, इसलिए हमने सोचा कि आपको यह बताने का यही सही समय है कि यह सुविधा कैसे लाई गई।

गोलांग बचाव के लिए

2020 की शुरुआत में, महामारी के कारण लॉकडाउन ने आखिरकार मुझे प्रोग्रामिंग भाषा गोलांग सीखने का अवसर दिया, जिसे मुझे समय की कमी के कारण स्थगित करना पड़ा था।

गोलांग (या संक्षेप में गो) गूगल द्वारा बनाई गई एक भाषा है जो पिछले कुछ वर्षों में काफी लोकप्रिय हो रही है।

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

मेरी राय में, एक नई प्रोग्रामिंग भाषा (या एक नया फ्रेमवर्क या जो भी हो) सीखने का सबसे अच्छा तरीका है कि आप जो सीखते हैं उसे व्यवहार में लाने के लिए एक अच्छा प्रोजेक्ट खोजें। यह सबसे आसान काम नहीं है: अगर डेवलपर्स इसे पढ़ रहे हैं, तो वे जानते हैं कि यह कितना कठिन हो सकता है । 

एक अच्छे साइड प्रोजेक्ट को कुछ विशिष्टताओं को पूरा करना होगा:

• इसका दायरा इतना बड़ा होना चाहिए कि डेवलपर प्रोग्राम बनाते समय सीखी जा रही तकनीक को पर्याप्त रूप से सीख सके: कंसोल में 'हैलो वर्ल्ड' प्रिंट करना, नई भाषा को समझने के लिए कभी-कभी पर्याप्त नहीं होता।
• इसका दायरा इतना बड़ा नहीं होना चाहिए कि डेवलपर संभवतः परियोजना पूरी करने से पहले ही हार मान ले (हम सभी उस स्थिति से गुजर चुके हैं)।
• अंतिम लेकिन सबसे महत्वपूर्ण बात, यह करना मज़ेदार होना चाहिए! 200वीं बार टू-डू सूची बनाना बहुत मनोरंजक नहीं होगा, संभावना है कि जैसे ही आप इसे काम करने का तरीका समझेंगे, आप हार मान लेंगे। 
• बोनस बिंदु: साइड प्रोजेक्ट आदर्श रूप से वास्तविक दुनिया की समस्या को हल करेगा, इससे कार्य पर ध्यान केंद्रित करने में मदद मिलती है।

तो मैं इसका ज़िक्र क्यों कर रहा हूँ? जब मैं सोच रहा था कि Golang सीखने के लिए एक बेहतरीन साइड प्रोजेक्ट क्या हो सकता है, तो मेरे दिमाग में आया कि एक वेब क्रॉलर ऊपर दिए गए विवरण के लिए बिल्कुल सही हो सकता है और कुछ ऐसी समस्याओं का समाधान भी कर सकता है जिनकी हम तलाश कर रहे थे। Weglot उपयोगकर्ताओं.

आइये इसके बारे में सोचें, एक वेब क्रॉलर (जिसे अक्सर 'बॉट' कहा जाता है), अपने सरलतम रूप में, एक प्रोग्राम है जो किसी वेबसाइट पर जाकर जानकारी निकालने के लिए बनाया गया है।

वेब क्रॉलर का एक सामान्य उपयोग मामला किसी वेबसाइट के हर पेज को खोजना और देखना और फिर साइटमैप बनाना हो सकता है। या इसकी सामग्री को इंडेक्स करना, उदाहरण के लिए गूगल बॉट के बारे में सोचें।

हमारे मामले में, हमें ऐसी चीज़ की आवश्यकता थी जिसका उपयोग हमारे उपयोगकर्ता अपनी वेबसाइट को स्कैन करने और अपनी साइट के सभी URL को वापस आयात करने के लिए कर सकें। 

हम अनुवाद तैयार करने का एक नया तरीका भी खोज रहे थे। उन लोगों के लिए एक अतिरिक्त नोट जो इससे परिचित नहीं हैं Weglot …'अनुवाद उत्पन्न करना' का अर्थ है कि आपके URL (और उनके अंदर की सामग्री) आपके Weglot अनुवाद सूची, जिससे आप अनुवादों में मैन्युअल संपादन कर सकेंगे।

उस समय, उपयोगकर्ताओं को उन्हें उत्पन्न करने के लिए एक अनुवादित भाषा में अपनी वेबसाइट पर जाना पड़ता था। यह वास्तव में तब अच्छा काम करता है जब आपकी वेबसाइट में केवल कुछ पृष्ठ होते हैं और आपके पास कई अनुवादित भाषाएँ नहीं होती हैं, लेकिन अगर आपके पास हज़ारों पृष्ठों वाली एक बहुत बड़ी वेबसाइट है, तो यह जल्दी ही एक भारी काम बन सकता है।

इस कार्य को स्वचालित करने के लिए वेब क्रॉलर का उपयोग करने का विचार तेजी से एक आदर्श समाधान की तरह दिखने लगा और यह गोलांग समवर्ती प्रोग्रामिंग सुविधाओं के लिए एक आदर्श उपयोग मामला होगा!

इसलिए जनवरी 2020 में, मैंने गोलांग की मूल बातें सीखते हुए एक वेब क्रॉलर का प्रोटोटाइप बनाना शुरू किया और जल्द ही मेरे पास कुछ ऐसा था जिसे मैं रेमी को दिखा सकता था, Weglot के सी.टी.ओ. 

यह कोई खास बात नहीं थी, यह एक सरल प्रोग्राम था जो एक यूआरएल को इनपुट के रूप में लेता था और वेबसाइट को क्रॉल करना शुरू कर देता था, तथा प्रत्येक डोमेन लिंक पर जाकर उसे ढूंढता था, लेकिन यह तेज और कुशल था।

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

एक सॉफ्टवेयर इंजीनियर के तौर पर, जब आप खुद किसी चीज़ पर काम करते हैं और फिर आपको अपना उत्पाद पूरी तरह से विकसित करने के लिए समय मिलता है, तो यह वाकई बहुत अच्छा लगता है। यह स्वीकृति की एक शानदार भावना है और यह मुझे तब तक प्रेरित करती रही जब तक कि हमारे पास उत्पादन के लिए तैयार उत्पाद नहीं आ गया ( जो अभी भी एक लंबा रास्ता तय करना था )।

होस्टिंग समस्या

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

मेरा पहला विचार क्लासिक और अच्छी तरह से सिद्ध समाधान का उपयोग करना था: AWS पर एक कंप्यूट इंस्टेंस को स्पिन करना और वेब सर्वर के पीछे बॉट को उजागर करना। यह एक अच्छा विचार लग रहा था लेकिन जितना अधिक मैंने इसके बारे में सोचा, उतना ही मैं कई मुद्दों के बारे में चिंतित था।

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

चूंकि मुझे गो प्रोग्राम की मेजबानी का कोई पूर्व अनुभव नहीं था, इसलिए यह निर्धारित करना कठिन था कि कौन से संसाधन (सीपीयू, रैम ...) एक बेहतरीन उपयोगकर्ता अनुभव प्रदान करने के लिए पर्याप्त होंगे।

इसके अतिरिक्त, मुझे लगा कि क्लासिक 'हमेशा चालू' वेब सर्वर सबसे कुशल समाधान नहीं था। लोग हर समय अपनी वेबसाइट क्रॉल नहीं करेंगे: एक बार जब आप अपने URL आयात कर लेते हैं और अपनी सामग्री तैयार कर लेते हैं, तो आपको दैनिक आधार पर बॉट का उपयोग नहीं करना चाहिए, भले ही आप अक्सर नई/अपडेट की गई सामग्री प्रकाशित करते हों।

इसके बारे में सोचने पर, यह सर्वर रहित होस्टिंग के लिए एक आदर्श उदाहरण प्रतीत हुआ।

जो लोग कुछ वर्ष पहले सर्वर रहित चलन से चूक गए थे, उनके लिए मैं संक्षेप में बता दूँ कि यह कैसे काम करता है:

• इसका नाम सर्वरलेस होने के बावजूद, कोड अभी भी सर्वर पर चलता है
• सर्वर के विपरीत, जो हमेशा चालू रहता है और कनेक्शन के लिए सुनता रहता है, सर्वर रहित कोड मांग पर चलता है, जब सर्वर रहित कोड चालू होता है, तो क्लाउड प्रदाता कोड को चलाने के लिए कुछ संसाधनों का प्रावधान और आवंटन करेगा।

इस होस्टिंग मॉडल के दो मुख्य लाभ हैं:

• डेवलपर्स को बुनियादी ढांचे का प्रबंधन करने की ज़रूरत नहीं है, यह सब प्रदाता द्वारा किया जाता है। इसका मतलब यह है कि आपको सर्वर सुरक्षा या कॉन्फ़िगरेशन के बारे में चिंता करने की ज़रूरत नहीं है।
• सबसे महत्वपूर्ण बात यह है कि यह डिजाइन के हिसाब से स्केलेबल है! 

याद है जब मैंने कहा था कि यह अनुमान लगाना कठिन है कि बॉट को चलाने के लिए सर्वर को किन संसाधनों की आवश्यकता होगी? खैर, अब आपको इसके बारे में चिंता करने की ज़रूरत नहीं है, हर अनुरोध के लिए आपके कोड को चलाने के लिए एक नया स्टेटलेस आइसोलेटेड कंटेनर बनाया जाता है, सर्वर की क्षमता से ज़्यादा होने का कोई जोखिम नहीं है, हर अनुरोध को चलाने के लिए अपना कंटेनर मिलता है।

तो, क्या सभी संभावित दुनियाओं में सब कुछ बेहतर के लिए ही है? जी हाँ, लगभग!

2020 में, सर्वरलेस कंप्यूटिंग 5 मिनट तक सीमित थी, (कम से कम AWS के लिए, मुझे Google क्लाउड प्लेटफ़ॉर्म या Microsoft Azure पर सर्वरलेस होस्टिंग का कोई अनुभव नहीं है)। यह बिल्कुल सही है क्योंकि इस होस्टिंग मॉडल को पीडीएफ बनाने या उदाहरण के लिए छवियों को क्रॉप करने जैसे छोटे कार्यों के लिए डिज़ाइन किया गया था। 

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

मैं सर्वरलेस का उपयोग छोड़ने ही वाला था कि तभी 2020 की शुरुआत में AWS ने घोषणा की - वे 5 मिनट की सीमा को बढ़ाकर 15 मिनट कर देंगे! 

दुर्भाग्य से, जैसा कि अक्सर AWS के मामले में होता है, जब वे नई सुविधाओं की घोषणा करते हैं तो वे उनके बारे में अधिक जानकारी नहीं देते हैं, समय सीमा बढ़ा दी गई थी लेकिन इसे कैसे प्राप्त किया जाए, इस पर कोई स्पष्टीकरण नहीं दिया गया था।

मैं आपको उन अनेकों परीक्षण, त्रुटियों और शोध से बचाऊंगा जो मैंने यह जानने के लिए किए थे कि सीमा को 15 मिनट तक कैसे बढ़ाया जाए, लेकिन मैं आपको आश्वस्त करना चाहता हूं कि यह आसान नहीं था 🙂

5 मिनट की सीमा वास्तव में बुनियादी ढांचे के स्तर पर लागू की गई सीमा थी, AWS अपनी विभिन्न सेवाओं के बीच 5 मिनट से अधिक HTTP कनेक्शन बनाए नहीं रखेगा, समाधान केवल HTTP कॉल के साथ सर्वर रहित कोड को ट्रिगर नहीं करना था, कई अन्य तरीके हैं, हमारे मामले में हमने SQS के साथ ट्रिगरिंग के लिए सेट किया: AWS संदेश कतार सेवा।

परिणामों का संचार

एक बार जब होस्टिंग की समस्या सुलझ गई, तो दिन समाप्त करने से पहले हमें एक और कार्य पूरा करना था। 

अब तक हमारे पास एक कार्यशील बॉट था, जिसे स्केलेबल और लागत-कुशल तरीके से होस्ट किया गया था, आखिरी चीज जो हमें चाहिए थी, वह थी बॉट द्वारा उत्पादित डेटा को उपयोगकर्ताओं तक वापस भेजना।

चूंकि मैं चाहता था कि यह सुविधा यथासंभव अधिक इंटरैक्टिव हो, इसलिए मैंने बॉट और के बीच वास्तविक समय के संचार का विकल्प चुना। Weglot डैशबोर्ड.

इस तरह की सुविधा के लिए वास्तविक समय अनिवार्य नहीं है, आप हमेशा लंबे समय तक मतदान जैसे सरल समाधान के लिए समझौता कर सकते हैं लेकिन मैं यह सुनिश्चित करना चाहता था कि जैसे ही क्रॉलर ने अपना काम शुरू किया, हमारे उपयोगकर्ताओं को प्रतिक्रिया मिल जाए, और ईमानदारी से कहें तो यह बॉट को चमकने और अपनी क्षमता दिखाने का एक तरीका भी था 🙂

चूंकि उस समय हमारे पास वास्तविक समय संचार को संभालने के लिए कुछ भी नहीं था (हमें इसकी कोई आवश्यकता नहीं थी) इसलिए हमने एक सिद्ध समाधान अपनाने का निर्णय लिया, हमने नोडजेएस में एक सरल वेबसोकेट सर्वर लिखा और इसे EC2 AWS इंस्टेंस पर होस्ट किया।

वेबसोकेट सर्वर के साथ संचार को क्रियान्वित करने और परिनियोजन को स्वचालित करने के लिए बॉट पर कुछ काम करने के बाद, हम अंततः उत्पादन में जारी करने से पहले परीक्षण के लिए तैयार थे।

जो एक साइड प्रोजेक्ट के रूप में शुरू हुआ, वह अंततः डैशबोर्ड तक पहुंच गया। 

मुझे क्रॉलर लिखने और मेरे सामने आने वाली कई समस्याओं को हल करने में बहुत मज़ा आया। अंत में, मैंने बहुत कुछ सीखा: एक नई प्रोग्रामिंग भाषा और AWS पारिस्थितिकी तंत्र में नए कौशल।

गो निश्चित रूप से एक ऐसी भाषा है जिसका मैं फिर से उपयोग करूंगा, यह नेटवर्किंग कार्यों और सहकारी प्रोग्रामिंग के लिए वास्तव में शानदार है। यह Js, PHP या Python जैसी भाषाओं की तुलना में कम मेमोरी फ़ुटप्रिंट के कारण सर्वरलेस कंप्यूटिंग के साथ जोड़ी बनाने के लिए भी एक बहुत अच्छी भाषा है।

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

मुझे आशा है कि आपको यह झलक पसंद आई होगी Weglot इस लेख को लिखने में मुझे जितना आनंद आया, उतना ही इस बॉट को स्वयं भी आज़मा कर देखने में भी मुझे आनंद आया!