सोलो-डेवलपर के रूप में सोशल नेटवर्क बनाने की मेरी 4 साल की यात्रा

यह मेरे एकल-देव प्रोजेक्ट, इमर्सिव कम्युनिटीज़ - कंटेंट क्रिएटर्स के लिए एक सोशल मीडिया प्लेटफ़ॉर्म की एक कहानी है, एक पूर्ण एक्सपोज़, जिसे मैंने 2018 की शुरुआत में लिया और 2022 में पूरा किया।

मुझे उम्मीद है कि यह किसी भी व्यक्ति के लिए एक मार्गदर्शक के रूप में काम करेगा जो एक बड़ी परियोजना शुरू कर रहा है या एक के निर्माण के बीच में है और इसे जारी रखने के लिए प्रेरणा की आवश्यकता है।

विचार

2018 की शुरुआत में, फीकी आवाजें आने लगीं। लोगों ने वेब की स्थिति और सामान्य तौर पर सोशल मीडिया पर अपनी राय व्यक्त करना शुरू कर दिया।

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

लेकिन इन सबका विकल्प कैसा दिखेगा?

सोलो-देव परियोजना - मेकिंग में इतिहास

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

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

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

एक प्रौद्योगिकीविद् के रूप में, मैंने यह भी सोचा कि क्या यह सब एक व्यक्ति द्वारा किया जा सकता है।

क्या वास्तव में एक व्यक्ति के लिए चुनौती के लिए कदम उठाना और एक मजबूत, उद्यम-स्तरीय मंच प्रदान करना संभव होगा जिसका उपयोग लोग करना पसंद करेंगे, और यदि हां, तो ऐसी प्रणाली को वितरित करने में क्या लगेगा?

सच कहूं तो मेरे पास उन सवालों का जवाब नहीं था, लेकिन मैंने चुनौती लेने का फैसला किया।

2018 के उन शुरुआती दिनों में, मेरे पास एक सॉफ्टवेयर डेवलपर के रूप में लगभग 6 साल का कार्य अनुभव था, जो ज्यादातर बैक-एंड .NET और कुछ wpf फ्रंट एंड पर था।

मैं टोक्यो में भी रह रहा हूं, जहां मैं 3 साल से भी कम समय पहले आया था, और ओवरटाइम काम करना आदर्श था; कम से कम कहने के लिए, सभी उद्देश्यों और उद्देश्यों के लिए अतिरिक्त कार्य करने का विचार अनुचित था।

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

तथ्य यह है कि यह असंभव लग रहा था, यही कारण है कि मैंने बाद में जल्द से जल्द शुरू करने का फैसला किया। क्या यह सब समय की एक बड़ी बर्बादी होगी? केवल समय ही बताएगा, लेकिन जितनी जल्दी मैं शुरू करूंगा, उतनी ही जल्दी मुझे इसका जवाब मिल जाएगा।

फिर, 1 फरवरी 2018 को , मैंने योजना बनाना शुरू किया।

2018 - योजना

पहली चीज जो मैंने करने का फैसला किया, वह यह थी कि मैं खुद से कहूं कि यह सोचना कि यह आसान नहीं होगा, सदी की समझ होगी। मैंने पहले कभी ऐसा कुछ नहीं किया था, इसलिए मुझे सचमुच पता नहीं था कि मैं अपने आप में क्या कर रहा था।

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

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

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

निर्माण की तुलना में सोचना और योजना बनाना निश्चित रूप से आसान है और इसमें कम समय लगता है, इसलिए जितना अधिक मैं नियोजन चरण में करता हूं, उतना ही कम मुझे वास्तविक विकास चरण के दौरान खोजना होगा, जिसके लिए समय-समय पर अधिक संसाधनों की आवश्यकता होती है।

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

इस निर्णय के पीछे तर्क काफी सरल था। यह देखते हुए कि यहाँ सीखने के लिए बहुत कुछ होगा, अगर मैं बस जाऊँ और किसी से अपनी सभी समस्याओं का समाधान करने के लिए कहूँ, तो मुझे कोई अनुभव प्राप्त नहीं होगा।

परियोजना जितनी आगे बढ़ेगी, यह उतनी ही कठिन होती जाएगी और मुझे इसे अपने दम पर निपटने का कोई अनुभव प्राप्त नहीं होगा।

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

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

फिर मैंने नोट्स लेना शुरू किया और महसूस किया कि मुझे दो मुख्य बिंदुओं पर ध्यान देना है:

• परियोजना का परिरूप
• टेक स्टैक

चूँकि मुझे पता था कि एक दिन में केवल 24 घंटे होते हैं, और उनमें से अधिकांश मैं काम पर या यात्रा पर बिताऊंगा, मुझे अपना समय सावधानी से अनुकूलित करना था।

परियोजना का परिरूप

प्रोजेक्ट डिज़ाइन भाग के लिए, अपने समय को अधिकतम करने के लिए, मैंने यह देखने का निर्णय लिया कि कौन से उत्पाद पहले से ही अच्छा काम कर रहे हैं और उन्हें प्रेरणा के स्रोत के रूप में उपयोग करें।

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

मैंने फिर डिजाइन की ओर रुख किया। Apple अपनी अच्छी तरह से स्वीकृत डिजाइन प्रथाओं के लिए प्रसिद्ध होने के कारण प्रेरणा का एक तात्कालिक स्रोत था। इसके बाद, मैंने Pinterest की ओर रुख किया और तय किया कि यह सबसे सरल संभव डिज़ाइन है जो अच्छी तरह से काम करता है। मेरे निर्णय के पीछे का विचार पुरानी कहावत थी।

कंटेंट इज किंग। - बिल गेट्स, 1996।

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

इसका फ्रंट एंड को डिजाइन करने के लिए आवश्यक समय को कम करने का प्रभाव था।

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

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

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

इस प्रकार, नियमित लेखों को "रुचि" कहा जाएगा और यह तथ्यात्मक और सूचनात्मक प्रकृति का होगा, जिसमें कोई भी उन्हें संपादित करने में सक्षम होगा।

दूसरी ओर, "समीक्षाएं" प्रत्येक रुचि पर आधारित होंगी, और केवल समीक्षा के लेखक ही इसे संपादित कर पाएंगे।

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

तब प्रत्येक उपयोगकर्ता उस फिल्म की अपनी समीक्षा लिखने में सक्षम होगा। स्वाभाविक रूप से, मूल लेख तब इस फिल्म के लिए लिखी गई सभी समीक्षाओं की एक सूची दिखाएगा।

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

प्रत्येक उपयोगकर्ता को अपने प्रोफाइल में संक्षिप्त अपडेट या "गतिविधियां" पोस्ट करने में सक्षम होना चाहिए, जो फेसबुक पर एक दीवार के रूप में कार्य करेगा। यह मूल रूपरेखा थी जिसे मैंने उन तकनीकों के बारे में सोचने से पहले बनाया था जिनका उपयोग मैं वास्तव में परियोजना को वितरित करने के लिए कर सकता था।

टेक स्टैक

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

इसके अलावा, इस चरण के दौरान जिस विचार ने मेरी सोच को सबसे अधिक प्रेरित किया, वह था ऐसे डिजाइन निर्णय लेना जिससे मुझे जितना संभव हो उतना कम कोड लिखना पड़े, जिससे समय की बचत हो।

व्यापक शोध के बाद मैं निम्नलिखित मुख्य टेक स्टैक पर बस गया:

• नोडजेएस
• पीडब्ल्यूए
• सर्वर रहित
• ऑरेलिया जे एस
• एडब्ल्यूएस कॉग्निटो
• एडब्ल्यूएस ऐपसिंक
• एडब्ल्यूएस डायनेमोडीबी
• एडब्ल्यूएस किनेसिस
• एडब्ल्यूएस क्लाउडफ्रंट + S3
• terraform

इसके अलावा, SaaS सेवाओं को चुनकर मैं और अधिक समय बचाऊंगा क्योंकि मुझे इन सुविधाओं को स्वयं लागू करने की आवश्यकता नहीं होगी। मैंने जिन सेवाओं पर निर्णय लिया, वे इस प्रकार थीं।

• बादल
• एम्बेड
• अल्गोलिया
• रीकॉम्बी
• ठिकाना
• ट्विलियो
• पट्टी

ये मुख्य प्रौद्योगिकियां थीं जिन्हें मुझे परियोजना पर काम करना शुरू करने के लिए जितनी जल्दी हो सके सीखना था। बाकी सब कुछ रास्ते में सीखना होगा।

इस बिंदु पर, मैंने नई तकनीकों को सीखना शुरू कर दिया। मुख्य और सबसे महत्वपूर्ण के लिए, मैंने निम्नलिखित पुस्तकों को पढ़ना शुरू किया।

• कार्रवाई में अमेज़न वेब सेवाएँ
• एडब्ल्यूएस पर सर्वर रहित वास्तुकला
• कार्रवाई में ऑरेलिया
• वेबपैक क्या है
• कॉग्निटो देव गाइड
• क्लाउडफ्रंट देव गाइड
• डायनेमोडीबी देव गाइड
• AppSync के साथ सर्वर रहित ग्राफ़क्यूएल
• टेराफॉर्म अप एंड रनिंग
• प्रगतिशील वेब ऐप्स

मैंने फैसला किया कि मैं दिन में अपनी पूर्णकालिक नौकरी पर काम करूंगा लेकिन शाम का खेल एक अच्छा खेल था। जब मैं घर आता, तब तक पढ़ पाता जब तक मैं सो नहीं जाता। जहां तक नींद की बात है, तो मुझे पढ़ाई के लिए कुछ और समय देने के लिए 6 घंटे का समय दिया जाएगा।

मैंने शुरू में भविष्यवाणी की थी कि इस परियोजना को बनाने के लिए मुझे केवल एक वर्ष की आवश्यकता होगी। फिर, नई तकनीकों को सीखने के लगभग एक वर्ष के बाद, यह 2018 का दिसंबर था और मैंने मुख्य पठन सामग्री को समाप्त कर दिया, जबकि कोड की बिल्कुल 0 पंक्तियाँ लिखी थीं।

विकास शुरू होता है

दिसंबर 2018 में, मैंने आखिरकार विकास करना शुरू कर दिया। मैंने विजुअल स्टूडियो कोड की स्थापना की और अपने विकास के माहौल का निर्माण शुरू किया।

मेरे लिए यह पहले दिन से ही स्पष्ट था कि मैं इतने बड़े प्रोजेक्ट के लिए आवश्यक सभी सर्वरों को बनाए नहीं रख पाऊंगा। न केवल तकनीकी दृष्टिकोण से, बल्कि बजट की ओर से भी। इस प्रकार, मुझे एक समाधान खोजना पड़ा।

सौभाग्य से, मुझे DevOps और बैक-एंड इंफ्रास्ट्रक्चर के लिए सर्वर रहित दृष्टिकोण के रूप में समाधान मिला।

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

DevOps के साथ, मैं फ्रंट-एंड और बैक-एंड डेवलपमेंट दोनों को एकीकृत और स्वचालित कर दूंगा, जबकि सर्वरलेस के साथ, मैं सर्वर रखरखाव की आवश्यकता को हटा दूंगा और ऑपरेशन की लागत को भी कम कर दूंगा।

यह दर्शन स्पष्ट रूप से मेरी सोच की तर्ज पर चला गया और पहली चीज जिसे मैंने स्थापित करने का फैसला किया, वह टेराफॉर्म के साथ एक सीआई/सीडी पाइपलाइन थी।

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

मैं कोडबिल्ड पर निर्माण के लिए, मैकोज़ के लिए, स्थानीय परीक्षण के लिए, और एक लिनक्स-आधारित एक, दोनों के लिए भंडार में एक टेराफॉर्म निष्पादन योग्य रखूंगा।

एक बार निर्माण प्रक्रिया शुरू होने के बाद, टेराफॉर्म निष्पादन योग्य कोडबिल्ड के अंदर लागू किया जाएगा और यह टेराफॉर्म कोड फाइलों को उठाएगा, इस प्रकार एडब्ल्यूएस पर मेरे बुनियादी ढांचे का निर्माण करेगा।

इन सभी भागों को तब कनेक्ट और स्वचालित करना होगा, जो मैंने AWS CodePipeline का उपयोग करके किया था, जो हर बार मेरे द्वारा किए गए कोड को CodeCommit से CodeBuild तक ले जाएगा।

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

2019 — COVID-19 हिट्स

एक बार जब मैं बैक एंड के लिए सीआई/सीडी पाइपलाइन समाप्त कर लेता हूं, तो मैं फ्रंट एंड को विकसित करने के लिए स्थानीय रूप से वास्तविक वेबसाइट स्थापित करने की ओर रुख करूंगा।

फ्रंट एंड को स्थापित करने का प्रारंभिक चरण ऑरेलिया-आधारित प्रोजेक्ट बनाना था। ऑरेलिया और रिएक्ट का उपयोग करने के पीछे का निर्णय, जो कि जावास्क्रिप्ट ढांचे के लिए सबसे लोकप्रिय विकल्प था और अभी भी है, एमवीवीएम पैटर्न के कारण था।

एमवीवीएम पैटर्न का मुख्य रूप से डब्ल्यूपीएफ डेस्कटॉप ऐप्स में उपयोग किया जाता है जिसका मैंने अनुभव किया था। इस प्रकार, रिएक्ट सीखने में मुझे पहले से जो कुछ भी पता था, उस पर निर्माण करने में अधिक समय लगता।

दूसरी ओर, ऑरेलिया का उपयोग करने का निर्णय न कि एंगुलर या वीयू का उपयोग करने का निर्णय ऑरेलिया के पीछे के दर्शन पर आधारित था - जो कि आपके रास्ते से बाहर निकलने के लिए है। दूसरे शब्दों में, ऑरेलिया में ऑरेलिया नहीं है।

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

इसलिए, निर्णय अंतिम था। इसके बाद, सी # दुनिया से आ रहा है जो स्थिर रूप से टाइप किया गया है, मैंने जावास्क्रिप्ट पर टाइपस्क्रिप्ट के साथ जाने का फैसला किया।

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

अन्यथा, उपयोगकर्ता अनुभव अस्वीकार्य होगा।

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

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

• मोबाइल-पहले
• ऑफलाइन-प्रथम

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

साथ ही, यह उपयोगिता-आधारित है, इस प्रकार इसकी उच्च पुन: प्रयोज्यता है, जो वही थी जो मैं ढूंढ रहा था।

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

प्रोग्रेसिव वेब ऐप्स (पीडब्ल्यूए) का उद्देश्य उपयोगकर्ता को देना है, लेकिन एक मैनुअल सेटअप बहुत त्रुटि-प्रवण और समय लेने वाला होगा, इस प्रकार मैंने Google वर्कबॉक्स का उपयोग करने का निर्णय लिया जिसमें सर्विस वर्कर इंस्टॉलेशन, ऑफलाइन और कैशिंग सुविधाएं हैं। अंतर्निर्मित।

एक बार कोर स्थापित हो जाने के बाद, इसे ऑनलाइन सवारी के लिए लेने का समय आ गया था। यह स्पष्ट था कि वेबसाइट हर समय किसी के लिए सुलभ होनी चाहिए, आउटेज आधुनिक प्रणाली में नहीं हैं, इसलिए मैंने सिस्टम को निम्नलिखित तरीके से स्थापित करने का निर्णय लिया।

सबसे पहले, HTML और JS फ़ाइलों को AWS S3 बकेट से परोसा जाएगा। इसे विश्व स्तर पर कम विलंबता के साथ उपलब्ध कराने के लिए, इसे AWS CloudFront CDN नेटवर्क द्वारा आगे बढ़ाया जाएगा।

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

एक बार सेटअप हो जाने के बाद, मैंने AWS रूट 53 में डोमेन खरीदे, जिनका मैंने परीक्षण और उत्पादन डोमेन - https://immersive.community के लिए उपयोग किया।

नाम के पीछे का विचार समान रूप से नामित समुदाय-आधारित नेटवर्क - माइटी नेटवर्क्स से आता है। मैंने बस "इमर्सिव" शब्द पर फैसला किया, क्योंकि उस समय से, यह Google पर अत्यधिक ट्रेंड करने लगा था।

चूंकि "immersive.networks" और "immersive.communities" पहले ही लिए जा चुके थे, इसलिए मैं "immersive.community" पर बस गया।

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

डेटाबेस तक पहुँचने के लिए, मैंने AWS AppSync को चुना, जो एक प्रबंधित GraphQL कार्यान्वयन है और सर्वर रहित भी है।

एक बहु-किरायेदार प्रणाली

इस बिंदु पर, मेरे सामने सबसे बड़ी समस्याओं में से एक को हल करना शुरू करने का समय था, अर्थात्:

उपयोगकर्ताओं को एकाधिक समुदायों में शामिल होने की अनुमति कैसे दें, लेकिन प्रत्येक समुदाय में निजी या प्रतिबंधित डेटा को एक-दूसरे से अलग कैसे रखें?

इस समस्या को हल करने का सबसे आसान तरीका कई डेटाबेस बनाना होगा, लेकिन इसकी स्पष्ट सीमाएँ हैं, क्योंकि किसी बिंदु पर, हमारे द्वारा बनाए जा सकने वाले डेटाबेस से बाहर हो जाएंगे।

यह पता चला है कि प्रत्येक AWS खाते की सीमाएँ हैं कि आप कितने संसाधन बना सकते हैं, इसलिए यह एक व्यवहार्य समाधान नहीं था।

मैं अंततः DynamoDB डेटाबेस में प्रत्येक प्रविष्टि के लिए एक प्रकार का कॉलम निर्दिष्ट करके इस समस्या का समाधान करूंगा। प्रत्येक उपयोगकर्ता का अपना प्रकार "उपयोगकर्ता" पर सेट होगा, जबकि प्रत्येक समुदाय को केवल "वेब" के रूप में सेट किया जाएगा।

मैं तब यह संकेत दूंगा कि एक उपयोगकर्ता एक नई पंक्ति जोड़कर एक समुदाय में शामिल हो गया है, जहां इस पंक्ति की कुंजी को "उपयोगकर्ता # वेब_उपयोगकर्ता # वेब" के रूप में नामित किया गया है। चूंकि उपयोगकर्ता और समुदाय का नाम अद्वितीय होगा, इसलिए यह कुंजी भी अद्वितीय होगी, इसलिए उपयोगकर्ता कई बार समुदाय में शामिल नहीं हो सका।

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

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

इसने बहु-किरायेदारी की समस्या को हल कर दिया, लेकिन हल करने के लिए सबसे बड़ी समस्याओं में से एक बस कोने के आसपास थी।

अत्यधिक उपलब्ध वास्तुकला

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

यदि हम ऐसी प्रणाली को लागू करना चाहते हैं, तो हमें इसे अतिरेक को ध्यान में रखकर करना चाहिए।

मेरे शोध ने मुझे इस मामले में इष्टतम समाधान के लिए प्रेरित किया, जो एक सक्रिय-सक्रिय अत्यधिक उपलब्ध वास्तुकला है। यह पता चला है कि एडब्ल्यूएस पर अधिकांश सेवाएं पहले से ही अत्यधिक उपलब्ध हैं, लेकिन ऐपसिंक स्वयं नहीं है। इस प्रकार, मैंने अपना खुद का कार्यान्वयन बनाने का फैसला किया।

वेब ने इस समस्या का समाधान नहीं दिया, इसलिए मुझे अपना खुद का निर्माण करना पड़ा। मैं विश्व स्तर पर सोचने लगा। मतलब, मेरे आगंतुक अलग-अलग क्षेत्रों से आ रहे होंगे, और अगर मैं अपना ऐपसिंक यूएस में रखूं, तो एशिया में आगंतुकों की विलंबता अधिक होगी।

मैंने विलंबता और उच्च उपलब्धता की समस्या को निम्नलिखित तरीके से हल किया। मैंने उस समय सभी उपलब्ध क्षेत्रों में 10 अलग-अलग AppSync API बनाने का निर्णय लिया है। वर्तमान में, एपीआई यूएस, एशिया और यूरोप में स्थित हैं।

इसके अलावा, प्रत्येक एपीआई को उसी क्षेत्र में स्थित संबंधित डायनेमोडीबी डेटाबेस से जोड़ा जाना चाहिए। इस प्रकार, मैंने आगे 10 अतिरिक्त DynamoDB तालिकाएँ बनाईं।

सौभाग्य से, DynamoDB एक वैश्विक तालिका सुविधा प्रदान करता है जो कनेक्टेड DynamoDB तालिकाओं के बीच डेटा की प्रतिलिपि बनाता है और उन्हें सिंक में रखता है।

अब, इस बात की परवाह किए बिना कि कोई उपयोगकर्ता डेटाबेस को कहाँ लिखता है, एक अलग क्षेत्र में एक उपयोगकर्ता डेटा के समन्वयन के बाद उसी जानकारी को पढ़ने में सक्षम होगा।

अब जो प्रश्न उठा वह निम्नलिखित था।

उपयोगकर्ताओं को निकटतम API पर कैसे भेजा जाएगा? इतना ही नहीं, लेकिन अगर ऐसा होता है कि एक एपीआई विफल हो जाता है, तो हम तुरंत कॉल को अगले उपलब्ध एपीआई में कैसे रूट करेंगे?

समाधान CloudFront और Lambda@Edge फ़ंक्शंस के रूप में आया। यह क्लाउडफ्रंट की एक अद्भुत विशेषता है जो उस क्षेत्र में लैम्ब्डा@एज कार्यों को ट्रिगर कर सकती है जहां कॉलर स्थित है।

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

इसके अलावा, हम लैम्ब्डा @ एज फ़ंक्शन को निष्पादित करने का क्षेत्र भी प्राप्त कर सकते हैं, इस प्रकार, हमें उसी क्षेत्र में ऐपसिंक एपीआई चुनने की इजाजत देता है। इस समाधान को लागू करने के लिए पहला कदम CloudFront के माध्यम से AppSync कॉल को प्रॉक्सी करना था।

इसलिए, अब, कॉल सीधे AppSync के बजाय CloudFront पर की जाएंगी।

फिर मुझे लैम्ब्डा@एज फंक्शन के अंदर CloudFront पैरामीटर्स से HTTP कॉल एक्सट्रैक्ट करनी पड़ी। एक बार जब मेरे पास क्षेत्र और AppSync क्वेरी थी, जिसे CloudFront पैरामीटर से निकाला गया था, तो मैं संबंधित AppSync API को एक नया HTTP कॉल करूंगा।

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

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

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

यदि अंतिम क्षेत्र भी विफल रहता है, तो हम केवल असफल परिणाम लौटाते हैं।

यह केवल सक्रिय-सक्रिय अत्यधिक उपलब्ध आर्किटेक्चर का राउंड रॉबिन कार्यान्वयन है। इस प्रणाली के अब लागू होने के साथ, हमने वास्तव में निम्नलिखित तीन विशेषताओं को लागू किया है:

• वैश्विक कम विलंबता
• क्षेत्र आधारित लोड संतुलन
• सक्रिय-सक्रिय उच्च उपलब्धता

हमारे पास स्पष्ट रूप से कम विलंबता है, औसतन, प्रत्येक वैश्विक उपयोगकर्ता के लिए, क्योंकि प्रत्येक उपयोगकर्ता निकटतम क्षेत्र में रूट हो जाएगा, जिससे वह एपीआई को कॉल कर रहा है। हमारे पास क्षेत्र-आधारित लोड संतुलन भी है, क्योंकि उपयोगकर्ताओं को उनके क्षेत्र में कई एपीआई के लिए रूट किया जाएगा।

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

यह वास्तव में केवल एपीआई के लिए उच्च उपलब्धता को संभालने के लिए पर्याप्त नहीं होगा। मैं इसे सभी संसाधनों के लिए रखना चाहता था, जिसमें HTML और JavaScript फ़ाइलें शामिल हैं जिन्हें CloudFront से परोसा गया था।

इस बार, मैंने उसी दृष्टिकोण का उपयोग किया लेकिन 16 AWS S3 बकेट बनाए। प्रत्येक बकेट समान फाइलों की सेवा करेगा, लेकिन विभिन्न क्षेत्रों में स्थित होगा।

इस मामले में, जब उपयोगकर्ता हमारी वेबसाइट पर जाता है, तो ब्राउज़र HTML, JS, JSON, या छवि फ़ाइलों में से कई HTTP कॉल कर रहा होगा। इस मामले में, लैम्ब्डा@एज को उस यूआरएल को निकालना होगा जिसे वर्तमान में बुलाया जा रहा था।

एक बार मेरे पास यूआरएल होगा, मुझे इस फ़ाइल के फ़ाइल प्रकार को निर्धारित करना होगा और क्षेत्र में संबंधित एस 3 बाल्टी में एक नया HTTP कॉल करना होगा।

कहने की जरूरत नहीं है, अगर कॉल सफल होती है, तो हम फ़ाइल वापस कर देंगे, जबकि अगर यह विफल हो जाता है, तो हम पहले की तरह उसी रूटिंग सिस्टम का उपयोग करेंगे, इस प्रकार एक सक्रिय-सक्रिय अत्यधिक उपलब्ध सिस्टम भी प्रदान करेंगे।

अब इस प्रणाली के साथ, हम एक और मील के पत्थर पर पहुंच गए हैं और हमारे उद्यम-स्तर के बुनियादी ढांचे के लिए आधारशिला का एक और टुकड़ा रखा है। यह विकसित करने के लिए अब तक की सबसे कठिन प्रणाली थी और इसे पूरा करने में 3 महीने का समय लगा।

जैसा कि यह पता चला है, हमें हल करने के लिए और अधिक समस्याएं थीं और यह प्रणाली फिर से उपयोगी साबित होगी।

गतिशील पीडब्ल्यूए मैनिफेस्ट

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

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

जैसा कि यह पता चला है, PWA मेनिफेस्ट फ़ाइल, जो इन सभी विशेषताओं को परिभाषित करती है, उप डोमेन के आधार पर काम नहीं करती है। यह केवल उस डोमेन के आधार पर मानों के एक सेट को परिभाषित कर सकता है जिससे इसे परोसा गया है।

तथ्य यह है कि मैं पहले से ही CloudFront और Lambda@Edge का उपयोग करके HTTP कॉल को प्रॉक्सी कर सकता था, यहाँ भी काम आया।

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

फिर फ़ाइल को ब्राउज़र में परोसा जाएगा और समुदाय को उपयोगकर्ता के डिवाइस पर एक नए PWA ऐप के रूप में स्थापित किया जाएगा।

फ्रंट एंड की ओर बढ़ना

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

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

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

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

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

• अवयव
• नियंत्रण
• पृष्ठों
• समुदाय

सबसे छोटे कस्टम HTML तत्व जैसे <button> और <input> को Components के रूप में परिभाषित किया गया था। फिर हम इन घटकों को नियंत्रण में पुन: उपयोग कर सकते हैं जो इन छोटे तत्वों के सेट हैं, उदाहरण के लिए, प्रोफ़ाइल जानकारी नियंत्रण उपयोगकर्ता की प्रोफ़ाइल छवि, उपयोगकर्ता नाम, अनुयायी इत्यादि प्रदर्शित करेगा।

फिर हम इन तत्वों को उच्च-स्तरीय तत्वों में पुन: उपयोग करने में सक्षम होंगे, जो हमारे मामले में हैं - पेज।

प्रत्येक पृष्ठ मूल रूप से एक मार्ग का प्रतिनिधित्व करेगा, उदाहरण के लिए, रुझान पृष्ठ, जहां हम सभी गतिविधियां या रुचि पृष्ठ देख सकते हैं जहां वास्तविक लेख टेक्स्ट प्रदर्शित किया जाएगा। फिर मैं इन छोटे नियंत्रणों से प्रत्येक पृष्ठ की रचना करूंगा।

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

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

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

• मुख्य
• लेख

"मुख्य" प्रकार केवल वेबसाइट लेआउट का प्रतिनिधित्व करता है जिसे उपयोगकर्ता द्वारा मुख्य https://immersive.community पृष्ठ पर लैंड करने पर लोड किया जाएगा। यहां, हम सभी समुदायों को सभी संगत नियंत्रणों के साथ प्रदर्शित करेंगे।

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

यह उस समुदाय प्रकार के आधार पर कुछ मार्गों को या तो सक्षम या अक्षम कर देगा, जिन पर हम स्थित थे।

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

इस बिंदु पर, एक बार जब हम यह निर्धारित कर लेते हैं कि हम किस उपडोमेन पर स्थित हैं, तो हम इस विशिष्ट समुदाय के लिए समुदाय और उपयोगकर्ता डेटा लोड करेंगे, इस प्रकार समाधान को सफलतापूर्वक कार्यान्वित करेंगे।

चिनाई लेआउट

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

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

• एक कवर फोटो
• लेख का शीर्षक
• लेख श्रेणी
• तिथि जब लेख पोस्ट या संपादित किया गया था
• लेखक की प्रोफाइल

मुख्य तरीके से मैंने सुनिश्चित किया कि लेखों की सूची पुरानी नहीं लगेगी, यह सुनिश्चित करना था कि उपयोगकर्ता अपने लेख के लिए प्रत्येक कवर फोटो का पहलू अनुपात चुन सकता है। Pinterest जिस तरह से अपने पिन प्रदर्शित करता है, उससे प्रेरणा मिली, इसलिए प्रत्येक लेख का एक अलग पहलू अनुपात भी होगा।

इसके लिए मुझे चिनाई लेआउट को लागू करने की आवश्यकता थी, जिसे सीएसएस ग्रिड या फ्लेक्सबॉक्स में आउट-ऑफ-द-बॉक्स नहीं चुना जा सकता है।

सौभाग्य से, कई उपयोगी ओपन-सोर्स कार्यान्वयन हैं जिन्हें मैंने लेआउट के लिए आजमाया और उपयोग किया। मुझे कई सुधार जोड़ने पड़े, जैसे पेजिनेटेड डेटा लोड करना और स्क्रीन आकार के साथ स्केलिंग करना।

और तब…

नवंबर 2019 में, COVID-19 के पहले लक्षण दिखाई देने लगे। दुनिया जल्द ही उथल-पुथल में आ गई थी और किसी को पता नहीं था कि क्या हो रहा था, लेकिन यह दुनिया को बदल देगा और हम एक-दूसरे के साथ कैसे बातचीत करेंगे, जिसकी कोई कल्पना भी नहीं कर सकता था।

इसके तुरंत बाद, हम घर से काम करना शुरू कर देंगे। इससे मेरी विकास प्रक्रिया पर बहुत प्रभाव पड़ेगा क्योंकि मुझे अब काम पर जाने के लिए यात्रा नहीं करनी पड़ेगी। विडंबना यह है कि दुनिया दुर्घटनाग्रस्त हो गई, जबकि मुझे वह ब्रेक मिला जिसकी मुझे जरूरत थी!

रुचियां और समीक्षाएं

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

साथ ही, अमीनो ऐप्स और Fandom.com जैसी सामुदायिक वेबसाइटों और ब्लॉगिंग वेबसाइट HubPages.com ने भी अपनी भूमिका निभाई।

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

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

मैंने दो प्रकार के लेखों को परिभाषित करने का निर्णय लिया है, अर्थात्,

• रूचियाँ
• समीक्षा

रुचियां लघु लेख होंगी, लगभग। 5000 चरित्र-लंबे लेख जो वास्तव में किसी विशेष रुचि का वर्णन करेंगे जो किसी व्यक्ति की हो सकती है। फिर, प्रत्येक व्यक्ति इस विशेष रुचि की रेटिंग के साथ समीक्षा लिख सकता है।

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

यहाँ, CloudFront के साथ प्रॉक्सी AppSync कॉल पर जाने का हमारा पहला निर्णय हमें काटने के लिए वापस आया। यह पता चला है कि CloudFront केवल 8,192 बाइट्स तक की क्वेरी स्ट्रिंग लंबाई का समर्थन करता है , इस प्रकार, हम इससे अधिक लंबे डेटा को सहेज नहीं सकते हैं।

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

एक बार जब ये सभी सुविधाएँ लागू हो गईं, तो साल का अंत आ गया। स्थिति अच्छी दिख रही थी और मुझे यकीन था कि यह परियोजना अगले साल पूरी हो जाएगी। कम से कम कहने के लिए यह धारणा सही नहीं निकली।

2020 — आगे पूरी गति

साल कमोबेश अच्छी शुरुआत हुई। अर्थव्यवस्था अभी भी कुछ हद तक रुकी हुई थी लेकिन थोड़ी देर बाद नीचे जाने लगी। बाजारों ने महामारी का जवाब देना शुरू कर दिया और इसी तरह कीमतें बढ़ने लगीं।

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

मेरे दिन के काम पर, काम के घंटे भी बढ़ा दिए गए थे और हमें सामान्य से अधिक तेजी से अपनी समय सीमा तक पहुंचना था। यह बिना कहे चला जाता है कि मुझे अपने कार्यक्रम को पुनर्व्यवस्थित करना था और कुछ और समय बचाने का एकमात्र तरीका हर रात केवल 4 घंटे सोना होगा।

विचार 6 या 7 बजे तक घर आने और फिर सीधे प्रोजेक्ट पर काम करने का था। मैं तब 3 या 4 बजे तक काम कर सकता था और फिर सो जाता था। फिर मुझे सुबह 7 बजे के आसपास उठना पड़ता और जल्दी से अपने दिन के काम पर लग जाता।

यह निश्चित रूप से, हर रात पर्याप्त नींद नहीं होगी, लेकिन मैंने सोचा कि सप्ताहांत के दौरान 12 घंटे सोने से मैं उस समय के लिए तैयार हो जाऊंगा। मैंने काम के लिए सभी छुट्टियों के दिन और सार्वजनिक अवकाश भी निर्धारित किए हैं।

नई प्रणाली स्थापित की गई थी, और मैं योजना के अनुसार आगे बढ़ा।

मार्कडाउन संपादक

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

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

• मूलपाठ
• छवि
• वीडियो
• एम्बेड

इसके अलावा, छवियों और वीडियो को एक स्लाइडर के रूप में प्रदर्शित किया जाना चाहिए जहां उपयोगकर्ता Instagram पर छवियों को स्वाइप कर सकते हैं। इसके लिए मार्कडाउन और अन्य HTML तत्वों के मिश्रण की आवश्यकता होगी।

संपादक को कई भागों में विभाजित किया जाएगा जहां दो प्रकार के इनपुट थे, टेक्स्ट फ़ील्ड और मीडिया फ़ील्ड। संपादक में प्रत्येक फ़ील्ड को ऊपर या नीचे ले जाया जा सकता है जिसे Sortable.js का उपयोग करके कार्यान्वित करना काफी आसान था।

जब इनपुट फ़ील्ड की बात आती है, तो मार्कडाउन फ़ील्ड एक <textarea> तत्व के साथ बनाने के लिए काफी आसान था। संपादक Inconsolata Google Font भी लोड करता है जो टेक्स्ट देता है, जिसे टाइप किया जा रहा है, टाइपराइटर दिखता है।

इसके अलावा, वास्तव में टेक्स्ट को स्टाइल करने के लिए, एक बार लागू किया गया था जो टेक्स्ट में मार्कडाउन को जोड़ देगा। माउसट्रैप.जेएस का उपयोग करके कीबोर्ड शॉर्टकट का उपयोग करके भी ऐसा ही किया गया था। अब, हम कंट्रोल+बी आदि का उपयोग करके ** मार्कडाउन टैग्स के रूप में आसानी से बोल्ड टेक्स्ट जोड़ सकते हैं।

टाइप करते समय, टेक्स्ट की मात्रा बढ़ने पर <textarea> तत्व का विस्तार होना स्वाभाविक है, इसलिए मैंने इस सुविधा को लागू करने के लिए Autosize.js लाइब्रेरी का उपयोग किया।

मीडिया फ़ील्ड छवियों, वीडियो या iframes को प्रदर्शित करने में सक्षम होगा जिसमें एम्बेडेड वेबसाइटें होंगी। मीडिया फ़ील्ड का प्रकार स्वयं मीडिया के प्रकार के आधार पर स्विच होगा। मैंने छवियों के बीच स्वाइपिंग को लागू करने के लिए Swiper.js का उपयोग किया।

वीडियो घटक को Video.js लाइब्रेरी का उपयोग करके कार्यान्वित किया गया था।

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

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

एक अन्य समस्या तब आई जब मुझे सही छवि पहलू अनुपात चुनना था और अपलोड करने से पहले इसे क्रॉप करना था। इसे Cropper.JS का उपयोग करके लागू किया गया था लेकिन दुर्भाग्य से, सफारी ब्राउज़र पर बॉक्स से बाहर काम नहीं किया।

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

एक बार सब कुछ पूरा हो जाने के बाद, मीडिया को क्लाउडिनरी पर अपलोड कर दिया जाएगा, जो मीडिया फ़ाइलों के प्रबंधन के लिए एक सेवा है।

यह सब एक साथ रखने और लेख के रूप में उपयोगकर्ता को प्रदर्शित करने का समय था। मैं काफी भाग्यशाली था कि ऑरेलिया में एक <compose> तत्व है जो HTML को गतिशील रूप से लोड कर सकता है।

इसलिए, इनपुट प्रकार के आधार पर, मैं या तो मीडिया तत्वों या मार्कडाउन तत्वों को लोड करूंगा, जिन्हें HTML में बदल दिया जाएगा।

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

इसके लिए एक घटना-संचालित दृष्टिकोण की आवश्यकता होगी जो हमें बताएगा कि स्क्रीन का आकार कब और कैसे बदल रहा है। इस मामले में उपयोग करने के लिए सबसे अच्छा पुस्तकालय RxJs था, जो "आकार बदलें" घटनाओं को संभालता था, और मैं तदनुसार तालिका को प्रारूपित करने में सक्षम था।

डेटा इनपुट में सुधार

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

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

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

जहां तक वास्तविक डेटा इनपुट की बात है, मैंने इसे एक पॉप-अप के रूप में लागू करने का निर्णय लिया। पॉप-अप स्वयं केवल स्क्रीन पर नहीं दिखाई देंगे बल्कि नीचे से ऊपर की ओर स्लाइड करेंगे। इसके अलावा, पॉप-अप के अंदर स्वाइप करना संभव होगा।

इस उद्देश्य के लिए, मैंने Swiper.Js लाइब्रेरी का पुन: उपयोग किया, जबकि अन्य सभी एनिमेशन Animate.CSS लाइब्रेरी का उपयोग करके किए गए थे।

पॉप-अप को लागू करना आसान नहीं था क्योंकि इसके लिए स्क्रीन के आकार के साथ स्केलिंग की आवश्यकता होती थी। इस प्रकार, बड़ी स्क्रीन पर, यह स्क्रीन की चौड़ाई का 50% लेगी जबकि छोटी स्क्रीन पर यह चौड़ाई का 100% लेगी।

इसके अलावा, कुछ मामलों में, जैसे अनुयायियों की सूची के साथ, मैंने पॉप-अप में शामिल होने के लिए स्क्रॉल को लागू किया। इसका मतलब यह हुआ कि जिस लिस्ट को हम स्क्रॉल कर रहे थे, वह सबसे ऊपर नहीं रुकी बल्कि स्क्रॉल करते समय गायब हो जाएगी।

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

यह ऐप्पल के शॉर्टकट ऐप से प्रेरित था और इसके पॉप-अप कैसे दिखाई देते हैं, जो तत्वों के ऊपर पिल बटन और टाइटल के लिए भी जाता है।

नेविगेशन बार

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

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

जब उपयोगकर्ता नीचे स्क्रॉल कर रहा होता है, तो हम मानते हैं कि वह सामग्री में रुचि रखता है और वर्तमान पृष्ठ से दूर नहीं जा रहा है, इस प्रकार हम बार को छिपा सकते हैं।

दूसरी ओर, यदि उपयोगकर्ता ऊपर स्क्रॉल कर रहा है, तो हो सकता है कि वह पृष्ठ छोड़ने का कोई रास्ता खोज रहा हो, इसलिए हम बार को फिर से दिखा सकते हैं।

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

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

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

रीयल-टाइम बैच प्रोसेसिंग

एक बार सामने के छोर पर सबसे महत्वपूर्ण काम हो जाने के बाद, यह एक बार फिर से पीछे के छोर पर जाने का समय था। सिस्टम का यह हिस्सा लागू करने के लिए सबसे जटिल में से एक साबित होगा, लेकिन अंततः, बहुत महत्वपूर्ण होगा और अन्य सुविधाओं के साथ आगे बढ़ना भी आसान बना देगा।

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में, सेपरेशन ऑफ़ कंसर्न की एक अवधारणा मौजूद है, जहाँ हम अपने कार्यों को सरल रखते हैं और उनसे केवल एक ही काम करते हैं, जो वे करने के लिए होते हैं।

इसके अलावा, पहलू उन्मुख प्रोग्रामिंग का विचार विशेष रूप से चिंताओं को अलग करने के बारे में है, जहां हमें व्यावसायिक तर्क को अन्य क्रॉस-कटिंग चिंताओं से अलग करने की आवश्यकता है।

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

मैंने इस तर्क को पूरे बोर्ड में लागू करने और UI से अधिक से अधिक सुविधाओं को निकालने का फैसला किया है, जो उपयोगकर्ता के लिए महत्वपूर्ण नहीं हैं और उन्हें पीछे के छोर पर ले जाते हैं।

हमारे मामले में, हम ज्यादातर डेटा को डेटाबेस में सहेजने से संबंधित हैं, जो समुदायों, लेखों, टिप्पणियों, पसंद आदि से संबंधित है।

यदि हम इस बात पर नज़र रखना चाहते हैं कि किसी लेख को कितने लाइक मिलते हैं, तो हमारे पास एक ऐसी प्रक्रिया हो सकती है जो प्रत्येक लेख के लिए सभी पसंदों की गणना करे और उन्हें समय-समय पर अपडेट करे।

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

मैंने इस कार्य के लिए AWS Kinesis को चुना है। Kinesis रीयल-टाइम डेटा की बड़ी मात्रा में अंतर्ग्रहण करने में सक्षम है और हम इस डेटा को क्वेरी करने और बैच करने के लिए लगभग रीयल-टाइम में भी SQL क्वेरी लिख सकते हैं। डिफ़ॉल्ट रूप से, Kinesis या तो 60 सेकंड के लिए डेटा बैच करेगा या बैच 5 एमबी तक पहुंच जाएगा, जो भी पहले हो।

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

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

ऐसा ही होता है, कि हमारे पहले के निर्णयों में से एक इस प्रक्रिया को लागू करने के लिए थोड़ा कठिन बना देगा क्योंकि हम 1 डेटाबेस से निपट नहीं रहे हैं, लेकिन वास्तव में 10 डेटाबेस से निपट रहे हैं।

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

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

"aws:rep:updateregion" कॉलम हमें यह जानकारी देता है और हम यह निर्धारित कर सकते हैं कि क्या हम उस क्षेत्र में डेटा से निपट रहे हैं जहां इसे डाला गया था या यदि यह कॉपी किए गए डेटा का प्रतिनिधित्व करता है।

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

फिर हम इस डेटा को एकत्र करते हैं, इसे "INSERT" या "DELETE" के रूप में चिह्नित करते हैं और इसे किनेसिस को देते हैं। डोमेन-संचालित डिज़ाइन दृष्टिकोण से इन विचारों को डोमेन ईवेंट कहा जाता है और हमें यह निर्धारित करने की अनुमति देता है कि कौन सी कार्रवाई हुई और तदनुसार हमारे डेटाबेस को अपडेट करें।

फिर हम अपना ध्यान किनेसिस की ओर मोड़ते हैं। यहां हमें सिस्टम के तीन मुख्य भागों को परिभाषित करना था

• एडब्ल्यूएस किनेसिस डेटा स्ट्रीम
• एडब्ल्यूएस किनेसिस फायरहोज
• एडब्ल्यूएस किनेसिस डेटा एनालिटिक्स

Kinesis Streams हमें वास्तविक समय में बड़ी मात्रा में डेटा अंतर्ग्रहण करने की अनुमति देती है। काइनेसिस एनालिटिक्स एक ऐसी प्रणाली है जो हमें वास्तव में इस डेटा को बैचों में क्वेरी करने और रोलिंग टाइम विंडो के आधार पर एकत्र करने की अनुमति देती है।

एक बार डेटा एकत्र हो जाने के बाद, हम प्रत्येक परिणाम को किनेसिस फायरहोज में आगे बढ़ाएंगे, जो बड़ी मात्रा में डेटा को संभाल सकता है और इसे एक गंतव्य सेवा में संग्रहीत कर सकता है, जो हमारे मामले में, JSON प्रारूप में एक S3 बाल्टी है।

एक बार जब डेटा S3 बकेट तक पहुंच जाता है, तो हम एक और लैम्ब्डा फ़ंक्शन को ट्रिगर करते हैं और डायनेमोडीबी डेटाबेस को अपडेट करने के लिए इस डेटा को संभालते हैं।

उदाहरण के लिए, यदि अंतिम मिनट में 5 लोगों ने रुचि पसंद की, तो हमें यह डेटा हमारी JSON फ़ाइल में मिलेगा। फिर हम इस ब्याज के लिए समान संख्या को अपडेट करेंगे और समान संख्या में वृद्धि या कमी करेंगे। इस मामले में, हम इसे केवल 5 लाइक्स के लिए बढ़ा देंगे।

इस प्रणाली का उपयोग करते हुए, प्रत्येक समुदाय के आंकड़े एक मिनट के भीतर अद्यतित रहेंगे।

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

यह सुधार डेटा इलाके के विचार पर आधारित है

बादल

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

मैंने निम्नलिखित उत्तरदायी स्क्रीन ब्रेकप्वाइंट के लिए छवियों को उत्सुकता से बदलने के लिए क्लाउडिनरी पर सभी प्रीसेट सेट किए हैं।

• 576 पिक्सल
• 768 पिक्सल
• 992 पिक्सल
• 1200 पिक्सेल

ये टेलविंड सीएसएस में सेट किए गए ब्रेकप्वाइंट भी होंगे जहां हमारी वेबसाइट मोबाइल फोन, छोटे टैबलेट, बड़े टैबलेट और कंप्यूटर मॉनिटर के लिए विभिन्न स्क्रीन आकारों के अनुरूप होगी।

फिर वर्तमान स्क्रीन आकार के आधार पर, हम उचित रूप से क्लाउडिनरी से उत्सुकता से बनाई गई छवियों को <छवि> तत्व पर स्क्रूसेट विशेषता का उपयोग करके आमंत्रित करेंगे।

इससे हमें बैंडविड्थ की बचत करने और मोबाइल उपकरणों पर छवियों को लोड करने में लगने वाले समय को कम करने में मदद मिलेगी।

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

इसके लिए मुझे भविष्य में AWS पर एक कस्टम सिस्टम बनाने की आवश्यकता होगी।

एम्बेड.ly

मैंने ट्विटर, यूट्यूब आदि जैसी लोकप्रिय वेबसाइटों से सामग्री एम्बेड करने के लिए Embed.ly का उपयोग करने का निर्णय लिया।

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

अल्गोलिया

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

मैंने बस एक खोज बार बनाया है, जिस पर क्लिक करने पर, शेष एप्लिकेशन को छिपा दिया जाएगा और जब हम टाइप कर रहे होंगे, तो उस विशिष्ट सबडोमेन के लिए परिणाम प्रदर्शित करेगा जिसे हम वर्तमान में ब्राउज़ कर रहे हैं।

एक बार जब हम "एंटर" दबाते हैं, तो होम पेज पर चिनाई उन लेखों को प्रदर्शित करती है जो क्वेरी में फिट होते हैं। यह बिना कहे चला जाता है कि मुझे उस पेजिनेशन को भी लागू करना पड़ा जो Pinterest के रंगरूप की नकल करने के लिए परिणामों को क्रमिक रूप से लोड करेगा।

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

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

इसके बजाय हम उन्हें रीयल-टाइम और बैचों में संभालना चाहेंगे, इसलिए हम एक समाधान के रूप में फिर से किनेसिस का उपयोग करेंगे।

इस मामले में, डेटाबेस में एक नया आइटम जोड़ने से एक लैम्ब्डा फ़ंक्शन ट्रिगर होगा जो उस डेटा को किनेसिस डेटा स्ट्रीम्स को भेजेगा, जो बदले में डेटा को किनेसिस फ़ायरहोज़ (इस बार एनालिटिक्स की कोई आवश्यकता नहीं) को भेज देगा और उन्हें आगे स्टोर करेगा एक S3 बाल्टी में।

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

विशेष रूप से, हमें गतिविधियों को संसाधित करने की आवश्यकता होगी, जिससे हम मार्कडाउन-रिमूवर लाइब्रेरी का उपयोग करके मार्कडाउन टेक्स्ट को हटा देंगे। फिर हमें प्लेनटेक्स्ट के साथ छोड़ दिया जाएगा। एक बार हमारे पास वास्तविक टेक्स्ट होने के बाद, हम प्रासंगिक टैग निकालने के साथ आगे बढ़ सकते हैं जिनका उपयोग खोज के लिए किया जाएगा।

यह AWS कॉम्प्रिहेंड सेवा का उपयोग करके आसानी से किया जा सकता है, लेकिन समस्या यह है कि यह केवल कुछ भाषाओं का समर्थन करता है। इस प्रकार, यदि कोई उपयोगकर्ता ऐसी भाषा में लिख रहा है जो समर्थित नहीं है, तो हम टैग निकालने में सक्षम नहीं होंगे।

इस मामले में, हम केवल AWS अनुवाद का उपयोग करते हैं और पाठ का अंग्रेजी में अनुवाद करते हैं। फिर हम टैग निकालने के लिए आगे बढ़ते हैं और फिर हम उनका मूल भाषा में अनुवाद करते हैं।

अब, हम लक्ष्य के अनुसार केवल अल्गोलिया में टैग स्टोर करते हैं।

रीकॉम्बी

Pinterest की सबसे महत्वपूर्ण विशेषताओं में से एक इसका अनुशंसा इंजन है। एक बार जब उपयोगकर्ता किसी पिन पर क्लिक करता है, तो उसे तुरंत पिन की पूर्ण-आकार की छवि दिखाई जाती है, जबकि छवि के नीचे, हम वर्तमान पिन के आधार पर उपयोगकर्ता द्वारा पसंद की जाने वाली अनुशंसाओं को देख सकते हैं।

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

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

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

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

यदि कोई उपयोगकर्ता किसी समुदाय में शामिल होता है, तो इसे इस समुदाय के बुकमार्क में मैप किया जाएगा।

इस डेटा के आधार पर, रीकॉम्बी उपयोगकर्ताओं के लिए सिफारिशें तैयार करेगा।

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

यह उपयोगकर्ता को उन संभावित लेखों की एक सूची देगा जिनकी उन्हें पढ़ने में रुचि हो सकती है।

ठिकाना

यह देखते हुए कि कैसे वेबसाइट शुरू से ही वैश्विक दर्शकों के लिए लक्षित होगी, मुझे स्थानीयकरण को भी लागू करना पड़ा। प्रारंभिक रिलीज के लिए, मैंने 10 भाषाओं के साथ जाने का फैसला किया और एक SaaS सेवा के लिए समझौता किया - Locize, जिसे i18next स्थानीयकरण ढांचे के आधार पर लागू किया गया है।

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

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

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

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

इसके अलावा, मुझे संख्याओं को भी प्रारूपित करना था, इस प्रकार संख्या 1000 दिखाने के बजाय, मैं 1K प्रदर्शित करूंगा। इन सभी सुविधाओं को नम्ब्रो और टाइमएगो जैसे पुस्तकालयों द्वारा नियंत्रित किया गया था।

ट्विलियो

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

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

एसपीए को प्री-रेंडरिंग

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

इसके लिए, मुझे Puppeteer नाम की एक लाइब्रेरी मिली, जो एक हेडलेस क्रोम एपीआई है।

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

मैं लैम्ब्डा @ एज का उपयोग यह पता लगाने के लिए करूंगा कि मेरा उपयोगकर्ता वास्तव में क्रॉलर था, और फिर इसे प्री-रेंडरिंग लैम्ब्डा को पास कर दें। CloudFront मापदंडों में "उपयोगकर्ता-एजेंट" विशेषता का पता लगाकर ऐसा करना काफी आसान था। यह वास्तव में पता चला कि लैम्ब्डा कठपुतली पुस्तकालय लोड नहीं कर सका क्योंकि यह बहुत बड़ा था।

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

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

पट्टी

इमर्सिव कम्युनिटीज की मुख्य विशेषताओं में से एक इसकी रेवेन्यू शेयरिंग स्कीम है, जहां उपयोगकर्ता 50% सदस्य सदस्यता और विज्ञापन राजस्व साझा करते हैं।

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

मैंने प्रत्येक समुदाय के आधार पर राजस्व साझाकरण प्रणाली तैयार करने का निर्णय लिया है। इस तरह, एक उपयोगकर्ता कई समुदाय बना सकता है और प्रत्येक समुदाय के आधार पर कमा सकता है। प्रत्येक समुदाय के लिए राजस्व दो स्रोतों से आएगा।

• सदस्य सदस्यता
• स्वयं सेवा विज्ञापन

सदस्य सदस्यता को लागू करना सबसे आसान था। मैं सदस्य सदस्यता के लिए तीन मूल्य बिंदु बनाऊंगा, $ 5, $ 10, और $ 15 मासिक। तब प्रत्येक समुदाय के सदस्य मासिक आधार पर समुदाय के स्वामी का समर्थन कर सकते हैं, और बदले में, उन्हें कोई विज्ञापन नहीं दिखाया जाएगा।

विज्ञापन प्रणाली समान मासिक सदस्यता पर आधारित थी, लेकिन यह $100 और $1000 मासिक के बीच होगी। जो कंपनी किसी विशेष समुदाय में विज्ञापन देना चाहती है, वह केवल मासिक भुगतान राशि चुन सकती है और विज्ञापन बैनर सेट कर सकती है।

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

हमें विज्ञापनदाता को यह भी दिखाना होगा कि उनके विज्ञापन कैसा प्रदर्शन कर रहे हैं, इसलिए मैंने दृश्य और क्लिक दोनों को मापने के लिए फिर से एक Kinesis सेटअप नियोजित किया। यह प्रणाली तब हमेशा की तरह आँकड़ों को अपडेट करेगी और फिर मैंने आँकड़ों को प्रदर्शित करने के लिए ब्राइट चार्ट्स लाइब्रेरी का उपयोग किया।

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

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

एडब्ल्यूएस कॉग्निटो

अंतिम सेवा जिसे लागू किया जाना था, वह थी Auth0 , जो उपयोगकर्ता प्रमाणीकरण में मदद करेगी। कुछ शोध के बाद, मैंने एसएमएस संदेशों के आधार पर पासवर्ड रहित सेटअप का निर्णय लिया है।

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

यह पता चला कि पासवर्ड रहित प्रमाणीकरण का Auth0 कार्यान्वयन उप-इष्टतम था क्योंकि यह हर बार उनकी वेबसाइट पर पुनर्निर्देशित होगा और URL मापदंडों पर आधारित होगा, जिससे मैं बचना चाहता था।

सामाजिक नेटवर्क जैसी किसी चीज़ के लिए मूल्य निर्धारण भी पैमाना नहीं होगा, इसलिए मैंने AWS कॉग्निटो का उपयोग करके अपना स्वयं का कार्यान्वयन बनाने का निर्णय लिया।

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

इस बिंदु पर, उपयोगकर्ता को पंजीकरण करने के लिए केवल अपना फ़ोन नंबर और अपना उपयोगकर्ता नाम प्रदान करना होगा।

लॉगिन प्रक्रिया के दौरान, लैम्ब्डा फ़ंक्शन उपयोगकर्ता का फ़ोन नंबर एकत्र करेगा और एडब्ल्यूएस एसएनएस का उपयोग करके उपयोगकर्ता को एक सत्यापन कोड युक्त एक एसएमएस संदेश भेजेगा।

उपयोगकर्ता तब कॉग्निटो के माध्यम से सत्यापित होने के लिए बस इस कोड में टाइप करेगा और उसके प्रोफाइल पेज पर रीडायरेक्ट किया जाएगा।

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

साथ ही, प्रत्येक साइनअप और लॉगिन के दौरान, हम उपयोगकर्ता के आईपी को स्टोर करते हैं।

बाद में पता चला कि उपयोगकर्ताओं को वास्तव में अपने मोबाइल फोन नंबर देने में समस्या होगी, इसलिए मैंने एसएमएस को ईमेल संदेशों से बदलने का फैसला किया।

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

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

2021 — नो एंड इन साइट

यहां वह समय है जब सब कुछ ठीक हो गया था, लेकिन इतने लंबे समय तक बिना किसी प्रतिक्रिया के एकल डेवलपर के रूप में काम करने से आपको यह सवाल उठता है कि परियोजना किस दिशा में जा रही है।

सवाल यह है कि कोई भी डेवलपर जो अभी उसी स्थान पर है, वह खुद से निम्नलिखित प्रश्न पूछ सकता है।

मैं खुद को कैसे प्रेरित रख सकता हूं और आगे बढ़ने में सक्षम हूं, भले ही मुझे कोई अंत दिखाई नहीं दे रहा है?

जवाब बहुत सरल है।

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

हो सकता है कि आपको अभी जारी रखने का मन न हो, लेकिन आपको बाद में ऐसा महसूस हो सकता है और आपको यकीन है कि अगर आप वास्तव में छोड़ देते हैं तो नरक के रूप में बुरा लगेगा।

इसलिए यदि आप नौकरी छोड़ देते हैं, तो आपके पास अब कोई प्रोजेक्ट नहीं होगा और सारा काम बेकार हो जाएगा। तो बस इतना ही करना है कि आगे बढ़ते रहना है, चाहे कुछ भी हो जाए।

इस समय केवल ध्यान रखने वाली बात यह है कि हर डिलीवर फीचर, हर एक कीबोर्ड प्रेस आपको लक्ष्य के करीब ले जा रहा है।

इस परियोजना के दौरान मैंने वास्तव में 3 बार अपनी नौकरी बदली, हर बार काफी शामिल होने के बावजूद, लेकिन भले ही मुझे नौकरी के लिए साक्षात्कार के लिए जाना पड़ा, फिर भी मैं घर वापस जाऊंगा, अपनी मेज के पीछे बैठूंगा, और अपने प्रोजेक्ट पर काम करना जारी रखूंगा।

अगर आपको प्रेरणा की कमी है तो आपको खुद से क्या पूछना है, यह निम्नलिखित है।

अब छोड़ दोगे तो कहां जाओगे? छोड़ने के बाद आप केवल उसी रास्ते पर जा सकते हैं, जहां से आप आए थे। लेकिन आप पहले से ही जानते हैं कि वहां क्या है। आप पहले से ही जानते हैं कि यह कैसा है, और आपको यह पसंद नहीं आया, यही कारण है कि आप इस यात्रा पर सबसे पहले निकल पड़े। तो, अब आप एक तथ्य के लिए जानते हैं, कि वापस जाने के लिए कहीं नहीं है। आप आगे बढ़ सकते हैं, एकमात्र रास्ता है। और आगे बढ़ने का एक ही तरीका है, बस काम करते रहना।

इस परियोजना के दौरान मेरे पास यही प्रेरणा थी, जैसा कि मैंने पहले ही कहा था, यह या तो वह था, या वापस जा रहा था जहां मैं पहले से था, इसलिए मैंने आगे बढ़ने का फैसला किया।

व्यवस्थापक प्रणाली

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

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

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

इसके अलावा, ये व्यवस्थापक सभी समुदायों के अन्य उपयोगकर्ताओं को पूरी तरह से अक्षम करने और यहां तक कि पूरे समुदाय को अक्षम करने में सक्षम होंगे।

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

प्रत्येक उपयोगकर्ता के लिए अनुमतियों का वास्तविक सत्यापन बैक एंड पर तय किया जाएगा। मैं बस एक लैम्ब्डा फ़ंक्शन बनाउंगा जिसे प्रत्येक ऐपसिंक कॉल के अंदर बुलाया जाएगा जो प्रत्येक अनुरोध को मान्य करेगा।

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

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

एनालिटिक्स डैशबोर्ड

एक अन्य विशेषता जो उपयोगकर्ताओं के लिए उपयोगी होगी, वह होगी विश्लेषिकी डैशबोर्ड पृष्ठ। प्रत्येक समुदाय स्वामी ऐसे चार्ट देख सकता है जो यह प्रदर्शित करते हैं कि उसके समुदाय में कितनी सहभागिता हो रही है।

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

इसके अलावा, मैं स्ट्राइप डेटा भी लूंगा, और इस समुदाय के ग्राहकों, विज्ञापनदाताओं और कुल कमाई की संख्या प्रदर्शित करूंगा।

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

सुरक्षा

रोडमैप पर एक अतिरिक्त स्तर की सुरक्षा भी थी और मैंने अपने CloudFront वितरण के सामने WAF को लागू करने का निर्णय लिया।

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

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

द लास्ट मिनट रिडिजाइन

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

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

पहले, मैं अलग-अलग रिकॉर्ड बना रहा था और प्रत्येक संबंधित रिकॉर्ड का पता लगाने के लिए AppSync पाइपलाइन का उपयोग कर रहा था, जो स्पष्ट रूप से अस्थिर था। इसका काइनिस और अल्गोलिया और रीकॉम्बी जैसे तृतीय पक्ष सेवाओं की स्थापना पर भी प्रभाव पड़ा।

बदले में, सिस्टम को ठीक से काम करने के लिए पूरी तरह से नया स्वरूप देने में 3 महीने लग गए। एक बार यह हो जाने के बाद, मैं फिर से नई सुविधाओं के साथ जारी रख सकता था।

रिकॉर्ड पर सबसे गर्म गर्मी

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

उस दौरान टोक्यो में ओलंपिक हो रहे थे और 7 अगस्त को यह बताया गया कि ओलंपिक के इतिहास में सबसे गर्म तापमान दर्ज किया गया था ।

कहने की जरूरत नहीं है, ट्रेन से काम पर जाने का कोई मतलब नहीं होगा क्योंकि मौसम बहुत थका देने वाला होगा, जिससे मुझे थकान होगी और शाम को काम करने में असमर्थ हो जाएगा। मुझे एहसास हुआ कि काम करने के लिए टैक्सी लेकर मुझे कुछ और समय बचाना होगा।

इसने मुझे सोने के लिए कुछ और समय दिया और घर वापस आने के बाद मुझे काम करने के लिए बहुत अधिक थकान होने से बचाएगी।

रीयल-टाइम सूचनाएं

PWA एक बेहतरीन तकनीक है और यह हमें पुश नोटिफिकेशन का उपयोग करके उपयोगकर्ताओं को सूचनाएं भेजने का एक तरीका प्रदान करती है। मैंने तय किया कि यह एक ऐसी प्रणाली होगी जिसकी भी आवश्यकता होगी और कार्यान्वयन के साथ आगे बढ़े।

अधिसूचना प्रणाली उस उपयोगकर्ता के आधार पर लागू की जाएगी जिसका अनुसरण किया जा रहा है। यदि आप किसी उपयोगकर्ता का अनुसरण कर रहे हैं, तो जब वह कोई नई गतिविधि या लेख बनाता है, तो आपको सूचित करने की आवश्यकता होगी।

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

पिछले छोर पर, मैं एडब्ल्यूएस एपीआई गेटवे का एक नया उदाहरण बनाउंगा और इसे रीयल-टाइम डेटा के साथ काम करने के लिए सेट अप करूंगा।

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

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

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

मैंने एक अपठित संकेतक भी लागू किया जो दिखाएगा कि किस टिप्पणी अनुभाग में नई टिप्पणियां हैं जिन्हें उपयोगकर्ता ने अभी तक नहीं पढ़ा है।

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

एक बार कॉल वापस आने के बाद, हम केवल UI को अपडेट करेंगे और उपयोगकर्ता को सूचना दिखाएंगे।

जब कोई कार्रवाई सफलतापूर्वक पूरी हुई या नहीं, तो मैं उपयोगकर्ता को संकेत देने के लिए पॉप-अप के रूप में सूचनाओं का भी उपयोग करूंगा।

उदाहरण के लिए, मैं एक पॉप-अप संदेश बनाउंगा जो उपयोगकर्ता को बताएगा कि आलेख अद्यतन विफल हो गया है या नहीं।

फ्रंट एंड वैलिडेशन

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

शुक्र है, ऑरेलिया में एक सत्यापन प्लग-इन है और इसे एक तरल इंटरफ़ेस के साथ उचित रूप से लागू किया गया है। इसने व्यावसायिक नियम बनाना काफी आसान बना दिया, जो सीमित कर देगा, उदाहरण के लिए, एक लेख के नाम के लिए उपयोगकर्ता <इनपुट> फ़ील्ड में वर्णों की संख्या टाइप कर सकता है।

मैं सत्यापन संदेशों को एकत्र करने और फिर उन्हें UI पर प्रदर्शित करने के लिए ऑरेलिया प्रॉपर्टी बाइंडिंग सिस्टम का उपयोग करूंगा। मुझे इसे स्थानीयकरण प्रणाली के साथ शामिल करना होगा और यह सुनिश्चित करना होगा कि संदेश सही भाषा में प्रदर्शित हों।

कार्य को अंतिम रूप देना

शेष वर्ष में छोटे विवरणों पर काम करना शामिल था। मुझे प्लेसहोल्डर लोड करने जैसी चीजें बनाने की आवश्यकता थी। मैंने विशेष रूप से निर्णय लिया कि मैं लोडिंग प्लेसहोल्डर्स को अलग स्क्रीन तत्वों के रूप में प्रदर्शित नहीं करना चाहता।

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

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

आखिरकार साल खत्म हो गया और जो काम हुआ उससे मैं संतुष्ट था। हालांकि परियोजना अभी तक पूरी नहीं हुई थी, मुझे पता था कि सफलता मेरी पहुंच के भीतर है।

2022 - द लास्ट माइल

इस साल फाइनल ईयर होना था। मुझे नहीं पता था कि मैं वास्तव में वह सब कुछ लागू करूंगा जो मैं चाहता था, लेकिन मुझे पता था कि जो कुछ भी हुआ, मुझे उसे करना ही होगा।

मैं पिछले साल की तरह गर्मियों के दौरान काम को दोहराना नहीं चाहता था क्योंकि यह अधिक संभावना थी कि यह पिछले साल की तुलना में अधिक गर्म होगा।

मेरी भविष्यवाणी सच हुई और यह वास्तव में पता चला कि टोक्यो में 2022 में सबसे गर्म गर्मी का तापमान था, जिसे पिछले 147 वर्षों में मापा गया था!

लैंडिंग पृष्ठ डिजाइन

मैंने लैंडिंग पेज डिजाइन करके शुरुआत की। प्रश्न निम्नलिखित था।

जब मेरे उपयोगकर्ता मेरे लैंडिंग पृष्ठ पर आते हैं तो मैं उन्हें कैसा महसूस कराना चाहता/चाहती हूं?

मैं नहीं चाहता था कि उपयोगकर्ताओं को ऐसा लगे कि यह एक वेबसाइट के लिए बहुत गंभीर होगा, बल्कि एक मित्रवत और सहयोगी समुदाय होगा।

मैंने देखा कि हाल ही में, लैंडिंग पृष्ठों में वास्तविक लोगों की तस्वीरों के विपरीत चित्र थे, इसलिए इस रास्ते पर जाने का कोई मतलब नहीं होगा। इसलिए मैंने चित्रों के एक सेट पर निर्णय लिया जो मैंने Adobe Stock पर खरीदा था।

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

एकमात्र तकनीकी समस्या जिसे दूर किया जाना था, वह थी कि पाठ के अंदर रंग कैसे पेश किया जाए। सौभाग्य से, मैं अनुवाद परिभाषाओं के अंदर स्टाइलिंग सुविधा का उपयोग करने में सक्षम था और फिर, HTML को गतिशील रूप से उत्पन्न करने के लिए मार्कडाउन का उपयोग करता था जो लैंडिंग पृष्ठ पर प्रदर्शित होगा।

आवश्यक डेटा, जैसे "गोपनीयता नीति" और "उपयोग की शर्तें" को ऑनलाइन खरीदा गया और Google अनुवाद का उपयोग करके कई भाषाओं में अनुवाद किया गया।

अप्रत्याशित की उम्मीद

अब सभी ढीले सिरों को बांधने का समय आ गया था, इसलिए मैंने बाकी समय यह सुनिश्चित करने में बिताया कि बैक एंड पर सभी लैम्डा कार्यों में लॉगिंग मौजूद थी। इससे मुझे यह सुनिश्चित करने में मदद मिलेगी कि अगर कोई समस्या होती है, तो मुझे पता चल जाएगा कि क्या हो रहा था।

जब तक मैं समाप्त कर रहा था, तब तक यूक्रेन में युद्ध शुरू हो चुका था। इसने फिर से वैश्विक अर्थव्यवस्था की अनिश्चितता को बढ़ा दिया लेकिन मैंने काम करना जारी रखा और अपने आप को अंतिम लक्ष्य पर केंद्रित रखा।

PWA के कार्यान्वयन को अद्यतित न रखने के कारण, मुझे यह सुनिश्चित करना था कि सभी सुविधाएँ काम कर रही हैं, और इसलिए, जावास्क्रिप्ट और छवि कैशिंग को बेहतर बनाने के लिए कुछ और विकास की आवश्यकता है।

ऑफ़लाइन सुविधा को अंततः चालू कर दिया गया था और एप्लिकेशन अब ऑफ़लाइन ऐप के रूप में ठीक से व्यवहार कर रहा था।

मुझे उन परिवर्तनों को भी स्थानांतरित करना पड़ा जो मैंने पिछले छोर पर किए थे और वास्तव में मेरे द्वारा AppSync पर किए गए परिवर्तनों को अन्य क्षेत्रों में फैलाया था। चूंकि यह करना बहुत बोझिल होगा कि विकास के दौरान मैंने अन्य क्षेत्रों में कोई बदलाव नहीं किया जब से मैंने विकास करना शुरू किया।

वही वातावरण के लिए जाता है। तीनों वातावरणों को लगातार बनाने में बहुत अधिक समय बर्बाद होता, इसलिए मुझे अंततः सभी वातावरणों को सिंक करने और कोड को UAT और प्रोडक्शन में स्थानांतरित करने में कुछ समय लगा।

अंत में, मुझे https://immersive.community डोमेन को लागू करना पड़ा, जिसे "www" सबडोमेन के बिना काम करना होगा और होमपेज पर सही तरीके से रीडायरेक्ट करना होगा।

इस समय, हम 25 अप्रैल, 2022 की सुबह के समय में थे। मेरा 4 साल का प्रोजेक्ट आखिरकार खत्म हो गया। मैंने वेबसाइट पर पहली पोस्ट बनाई और सो गया। मुझे पता था कि मैं आखिरकार सफल हो गया। मैंने न केवल वह पूरा किया जो मैंने करने के लिए निर्धारित किया था, बल्कि मैंने इसे गर्मियों के आने से पहले भी किया था।

अंतिम शब्द

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

लेकिन, मैंने वास्तव में इस अभ्यास से क्या सीखा है?

खैर, काफी। सबसे पहले, मैं विश्वास के साथ कह सकता हूं कि मैं इसे फिर कभी नहीं करूंगा।

ऐसा नहीं है कि मैं परिणाम से खुश नहीं हूं, इसके विपरीत, मैं बहुत संतुष्ट हूं, लेकिन इस तरह का काम आप जीवन में एक बार करते हैं और खुद को आगे बढ़ाने की कोशिश करने का कोई मतलब नहीं होगा, बस साबित करने के लिए कि आप इसे और भी बेहतर कर सकते हैं।

मैं जानना चाहता था कि क्या एक एकल डेवलपर के रूप में एक उद्यम-स्तरीय प्रणाली का निर्माण करना संभव था और मैंने दिखाया है कि यह हमारे पास उपलब्ध तकनीकी स्टैक के साथ किया जा सकता है।

किसी भी चीज़ से अधिक, यह उनके साइड-प्रोजेक्ट पर काम कर रहे प्रत्येक डेवलपर के लिए एक बयान है या एक शुरू करने की सोच रहा है।

क्या मैं अन्य डेवलपर्स के लिए इस दृष्टिकोण की सिफारिश करूंगा? बिल्कुल। इसलिए नहीं कि यह चीजों को करने का सबसे अच्छा तरीका है, यह निश्चित रूप से नहीं है।

जब आप फंस जाते हैं तो मदद मांगना निश्चित रूप से किसी समस्या को हल करने का सबसे तेज़ तरीका नहीं है, लेकिन यह आपकी सीमाओं को खोजने में आपकी सहायता करेगा।

एक बार जब आप ऐसा कुछ करने का फैसला कर लेते हैं, और आप सफल हो जाते हैं, तो आपको पता चल जाएगा कि उसके बाद आपने जो कुछ भी करने का फैसला किया है, उसे हासिल करना आसान हो जाएगा।

मेरा मानना है कि मेरी कहानी आपको जो कुछ भी शुरू किया है उसे पूरा करने के लिए प्रेरित करेगी, भले ही आप जिस रास्ते पर चल रहे हों, उसका अंत न दिखे, बस याद रखें कि "वापस वहाँ" वह नहीं है जहाँ आप होना चाहते हैं .

अगर आपको यह कहानी प्रेरक लगी, तो मेरे YouTube चैनल को सब्सक्राइब करें क्योंकि मैं एक उन्नत "फुल स्टैक देव" प्रोग्रामिंग कोर्स करना शुरू कर दूंगा, जहां मैं उन सभी तकनीकों के बारे में विस्तार से बताऊंगा जिनका उपयोग मैंने इमर्सिव कम्युनिटी बनाने के लिए किया था।

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

यह केवल तकनीकों को जानने और उनका उपयोग करने के तरीके से भी अधिक महत्वपूर्ण घटक था। आप किसी समस्या से कैसे संपर्क करते हैं और आपकी विचार प्रक्रिया, जो आपको समाधान तक ले जाती है, मैं अपने YouTube वीडियो में गहराई से जाऊंगा।

यह डेवलपर्स के लिए किसी ऐसे व्यक्ति से प्रोग्रामिंग सीखने का एक शानदार तरीका होगा जिसने वास्तविक दुनिया प्रणाली बनाई है और अपने ज्ञान को साझा करने के लिए तैयार है। YouTube पर मिलते हैं!

यहाँ भी प्रकाशित