पहले Psono.com Odoo v11 द्वारा संचालित था। Odoo एक महान CMS है, फिर भी जैसा कि हमें सीखना पड़ा, अपडेट करना कठिन है। विशेष रूप से उनके वेबसाइट मॉड्यूल ने हमारे परीक्षण के दौरान बहुत सारी समस्याएं उत्पन्न कीं। Odoo v11 का 2020 के अंत तक अंत होगा इसलिए हम एक समाधान ढूंढने को मजबूर हुए।
हमने विभिन्न विकल्पों के बारे में सोचा, या तो Odoo v13 में अपडेट किया जाए और खुद से सभी सामग्री और कस्टमाइज़ेशन मैन्युअल रूप से माइग्रेट किया जाए, किसी को हमारी तरफ से माइग्रेट करने के लिए हायर करना, या पूरी तरह से एक नए CMS में माइग्रेट किया जाए। हमने निर्णय लिया कि हम Psono.com को पूरी तरह से माइग्रेट करेंगे और v11 को फ़ायरवॉल के पीछे उपयोग करना जारी रखेंगे और बाद में इसे माइग्रेट करेंगे (हमने अभी तक निर्णय नहीं लिया है)।
इस निर्णय के पीछे के कारण:
- हमारे पास बहुत कम मात्रा में सामग्री थी जिसे हमें Psono.com के लिए माइग्रेट करना होगा। मुख्यतः कुछ ब्लॉग पोस्ट।
- Odoo v13 में माइग्रेशन से वही समस्या उत्पन्न होगी जब v13 का अंतकारँत होगा, संभवतः अधिक डेटा के साथ।
- हम Odoo v11 की वेबसाइटों की कस्टमाइज़ेशन क्षमताओं से खुश नहीं थे। उनके टेम्पलेट्स का डेटाबेस में संग्रहीत होना बहुत जटिल है।
- लागत। किसी को माइग्रेशन कराना हमें कम से कम 5000 USD, संभावित रूप से अधिक खर्च पड़ेगा।
- Odoo की समुदाय बहुत सक्रिय थी, फिर भी पिछले वर्षों के लाइसेंस स्विच और पेड सॉल्यूशंस के लिए माइग्रेट करने और सब कुछ के पीछे पेवॉल डालने के विकास ने समुदाय को समाप्त कर दिया है।
- Psono.com मुख्यतः एक स्थिर वेबसाइट है जिसमें स्थिर सामग्री है। अगर हमें गतिशील सामग्री की आवश्यकता होगी तो हम इसे API से प्राप्त कर सकते हैं।
यात्रा
छोड़ने का निर्णय लेने के बाद हमें यह तय करना था कि कौन सा फ्रेमवर्क उपयोग करना है। क्लासिक फ्रेमवर्क हैं जैसे कि e.g. Hugo जिसे हमने इस्तेमाल किया था, फिर भी उनकी कार्यक्षमता सीमित थी। वैकल्पिक समाधान खोजते समय हमें नोड / रिएक्ट दुनिया में कुछ समाधान मिले।
मैं यहाँ "उत्कृष्ट समाधान" लिखना चाहता था, फिर भी मुझे नहीं लगता कि वर्तमान फ्रंटएंड डेवलपमेंट के टूटे हुए हालात में कुछ भी उस खिताब के योग्य है। टूटे हुए? क्या आपको वह समय याद है जब डेवलपर्स एक साधारण index.html और jQuery लोड करने के लिए एक script टैग से एक वेबसाइट बना सकते थे? अब आपको npm या yarn की जरूरत है, आपको package.json, webpack स्क्रिप्ट्स, आधुनिक फ्रेमवर्क्स जैसे Angular या React को समझना होगा जो अपने खुद के क्लाइंट के साथ आते हैं। JSX या TypeScript। जैसे फीचर्स जैसे हॉट रीलोडिंग विश्वसनीय रूप से काम नहीं करते हैं (फ़ाइल मानीटर नहीं, कुछ संशोधनों के लिए एक पूर्ण पुनरारंभ की आवश्यकता होती है, या हॉट रीलोडिंग बहुत जल्दी शुरू होता है तो आपको मैन्युअल रूप से पृष्ठ को रिफ्रेश करना होता है), तो आप डेवलपमेंट सर्वरों को मारते हैं और उनके वापस आने में मिनटों का इंतजार करते हैं (कम से कम बड़े प्रोजेक्ट्स में)। (मुझे F5 दबाकर और फिर बिना किसी मुद्दे के सब कुछ वहाँ हो जाने में मज़ा आता था!)। हर आधे साल में कम से कम एक नया फ्रेमवर्क या टूल ज़रूरी हो गया है जहाँ पुराने टूल्स को नवीनता दी जाती है। मैं आसानी से वर्तमान फ्रंटएंड डेवलपमेंट के हालात के बारे में बहुत कुछ लिख सकता हूँ। फिर भी, असली टॉपिक पर वापस।
संभ्रांत विकल्पों की अनुपस्थिति में, सबसे अच्छे विकल्प (जब मैं इसे लिख रहा हूँ) में से अगला.js और गेट्स्बी होते। कम से कम कुछ लेखों ने उन्हें ऐसा ही प्रमोट किया। दोनों समान रूप से लोकप्रिय हैं यदि आप Github सितारों या कमिट्स की तुलना करते हैं। प्रारंभिक मूल्यांकन के दौरान हमने जो एकमात्र अंतर देखा वह था next.js के लिए एक सर्वर घटक की आवश्यकता है, जबकि Gatsby स्थिर साइट बनाता है (कृपया मुझे अब मत मारिए यदि Next.js का सक्रिय सर्वर के बिना चलाने का कोई विकल्प है! :D)
तो हम Gatsby के साथ थोड़ा खेले और यह ठीक लग रहा था। अगला कदम यह था कि हम एक थीम के लिए देखने लगे। Gatsby एक "नया" यूटिलिटी है, इसलिए हमें जो थीम मिला वह अभी भी एक बहुत ही बुनियादी स्थिति में था। तीस मिनट और तीस बजट के बाद हमारे पास एक दृश्य रूप से आकर्षक थीम थी जो कम से कम कुछ आवश्यक घटकों को कवर करती थी और हमने इसे मॉडिफाई करना शुरू किया।
होस्टिंग विकल्प के रूप में आप आजकल कई प्रदाताओं के बीच चयन कर सकते हैं, जैसे कि Firebase, नेटलिफाई, Cloudflare, Vercel, सरल GCP Cloud स्टोरेज या AWS Cloudfront, अपने स्वयं के सर्वर, Kubernetes पर चल रहे डॉकर कंटेनर (मुझे इसका उल्लेख करना था!), ... (याद रखें वह पुराना समय जब आप एक पीएचपी और एक MySQL डीबी $5 प्रति महीने के लिए एक वेबस्पेस किराए पर लेते! :D ... लेकिन यह एक और लेख के लिए है...)
उन्हें तुलना करने, कुछ समीक्षाओं को पढ़ने, और संभव संयोजनों को चेक करने के बाद (जैसे कि Firebase के सामने Cloudflare) हमने प्रारंभिक रूप से Cloudflare का प्रयास किया। उनके सेवा के बहुत बड़े प्रशंसक होने के नाते यह एक स्वाभाविक पसंद था, फिर भी दुख की बात है कि उनका Wrangler यूटिलिटी समस्याओं में था। सबसे पहले यह हमेशा एक त्रुटि फेंक रहा था और फिर हम प्रमाणीकरण नहीं कर पा रहे थे ... प्रारंभिक त्रुटियां अगले दिन गायब हो गईं (शायद एक नया Bash ने यह कर दिखाया), फिर भी प्रमाणीकरण समस्या बनी रही। मुझे विश्वास है कि मैंने कुछ गलती की और उनके दिशानिर्देश पढ़ने और विभिन्न समाधान प्रयत्न करने के बाद कुछ घंटों के बाद मैंने हार मान ली।
नेटलिफाई एक और उम्मीदवार था, फिर भी या तो आपको इसे गिट प्रदाता से जोड़ना होगा और उनसे इसे बनाना होगा (हम GitLab CI का उपयोग करना चाहते थे) या मैन्युअल रूप से बिल्ड आउटपुट अपलोड करना होगा। हो सकता है कि कहीं उनके पास बिल्ड आउटपुट को एक API के माध्यम से अपलोड करने का विकल्प हो, फिर भी मैं एक का पता नहीं लगा सका। एक विकल्प एक रिपॉजिट्री हो सकता था जहां हम वास्तव में बिल्ड आउटपुट पुश करते, फिर भी वह अनावश्यक रूप से जटिल लग रहा था... उनका प्राइसिंग मॉडल भी एक और समस्या थी। वे प्रति सदस्य (!!!) एक काफी महत्वपूर्ण राशि चार्ज करते थे। ध्यान में रखें कि यह एक स्थिर वेबसाइट के लिए है। "4× बैंडविड्थ" जैसे बयान "उचित उपयोग वेबहोस्टिंग"-समयों की बुरी यादें लाते हैं जब लोग आपको बहुत अधिक उपयोग करने पर निकाल देते थे...
चौथे सेवा के रूप में हमने Firebase का प्रयास किया (जो हमारे लक्षित बैंडविड्थ और अनुरोधों के लिए मुफ्त है) और सब कुछ बॉक्स से बाहर काम किया। उनके रीडायरेक्ट क्षमताएं थोड़ी सीमित हैं, इसलिए पुराने यूआरएल को अधिक सुंदर वालों में मैप करना थोड़ा पेचिदा हो गया, पर कुछ रीडायरेक्ट नियमों के बाद सब कुछ काम कर रहा था। उनकी प्राइसिंग उचित लग रही थी और आपको सर्वर संसाधनों के लिए चार्ज किया जाता है। चाहिए कि उनके अतिरिक्त सेवाओं से दूर रहें ताकि विक्रेता लॉक-इन से बच सकें, फिर भी हमें सिर्फ होस्टिंग की आवश्यकता थी।
हमने संक्षेप में Vercel को भी चेक किया, फिर भी उनके गिटहब खाते के साथ लॉगिन करने और फिर एक परमिशन के साथ "मेरे behalf पर कार्य करें" ने मुझे साइन अप करने से पहले ही बाहर कर दिया।
ब्लॉग को माइग्रेट करना सबसे कठिन वाला था। हमने सभी सामग्री को मैन्युअल रूप से कॉपी किया। यह कुछ नहीं है जो आपको एक बड़े ब्लॉग के साथ करना चाहिए, फिर भी हमारे ब्लॉग में केवल पंद्रह पोस्ट थे। Gatsby कई यांत्रिकी का समर्थन करता है, फिर भी हम कुछ सरल चाहते थे जिसे कोई भी तकनीकी पृष्ठभूमि के बिना ब्लॉग पोस्ट करने में सक्षम हो सके। हमने मार्कडाउन के साथ जाने का निर्णय लिया और इसलिए हमें सीखना पड़ा कि Gatsby को मार्कडाउन पृष्ठों को कैसे पढ़ना सिखायें। वास्तविक मैकेनिज्म को हमें लगभग आधे दिन का समय लगा सारे चित्र प्रबंधन के साथ। एक अच्छी ब्लॉग पोस्ट थीम और चित्र एक और आधे दिन में तैयार हुए।
सभी सामग्री को माइग्रेट करने और थीम को भारी रूप से मॉडिफाई करने के बाद हमने Gitlab CI के साथ अपनी तैनाती को स्वचालित किया, ताकि एक साधारण पुश हमारी निर्माण पाइपलाइन को ट्रिगर कर सके और सब कुछ Firebase पर तैनात हो सके।
क्यों Gitlab और Github नहीं? Github के पास ऐतिहासिक कारणों के लिए बढ़त है। उनके पास वर्तमान में कम से कम 80% सभी डेवलपर्स और प्रोजेक्ट्स हैं। दूसरी ओर, Gitlab फीचर्स प्रदान करता है। इसीलिए हमने अतीत में Gitlab जाने का निर्णय लिया, क्योंकि Github में वर्षों से कोई वास्तविक फीचर विकास नहीं हुआ था। यह अब Microsoft के Github खरीदने के बाद नाटकीय रूप से बदल गया है और Github Actions एक मील का पत्थर है, फिर भी Github को वास्तव में Gitlab के साथ मुकाबला करने के लिए बहुत लंबा रास्ता तय करना है। इसलिए हमारे सभी प्रोजेक्ट्स Gitlab पर हैं, यह प्रोजेक्ट भी इसके लिए एक स्वाभाविक चयन था।
निष्कर्ष
और अब हम यहाँ हैं:
- Gatsby एक CMS के रूप में
- वाणिज्यिक थीम
- मार्कडाउन संचालित ब्लॉग
- स्वचालित तैनाती के लिए Gitlab CI
- Firebase होस्टिंग
हम इस परिणाम से काफी खुश हैं और नई वेबसाइट बहुत बेहतर दिखती है!
