Alleycat: मैंने अपने ब्लॉग के लिए CMS फिर से बनाया

नमस्ते, मैं अक्षम हूँ।
मैंने अपने ब्लॉग के लिए CMS फिर से बनाया है।
GitHub - haturatu/alleycat: cms & frontend · GitHub

आखिरकार, अगर मैंने इसे इस हद तक बनाया है, तो क्या WordPress बेहतर नहीं होता? यह एक ऐसा हिस्सा है जिस पर मैं विचार करता हूँ।

मैंने इसे क्यों बनाया

मेरा ब्लॉग, जो मूल रूप से 2020 के आसपास WordPress से LumeCMS में स्थानांतरित हो गया था, उसके स्थानांतरण का मूल इरादा इस प्रकार था:

• वर्डप्रेस

  • काफी मेमोरी खाता है

  • केवल एक व्यक्तिगत ब्लॉग के लिए MySQL को होस्ट करना अत्यधिक है

  • कार्यक्षमता विस्तार पूरी तरह से प्लगइन्स पर निर्भर करता है

  • CSS आदि अक्सर अव्यवस्थित हो जाते हैं

  • admin के तहत पोर्ट को अलग किए बिना सुरक्षित रूप से प्रबंधित करना मुश्किल है

  • छवियों को कॉपी-पेस्ट करना बहुत आसान था

  • सभी छवियों के लिए थंबनेल और स्केल किए गए संस्करण उत्पन्न होते हैं, जिससे अनावश्यक संसाधन बनते हैं

• लूमसीएमएस

  • काफी मेमोरी खाता है

  • चूंकि यह एक SSG CMS है, इसलिए प्रत्येक लेख अपडेट के लिए सब कुछ बनाना पारिस्थितिक नहीं था

  • छवियों को कॉपी-पेस्ट करके सीधे अपलोड नहीं किया जा सकता

  • सरल होना बहुत अच्छा था

  • वास्तव में, केवलmarkdown में लिखना कोई समस्या नहीं थी, लेकिन स्मार्टफोन से अपडेट करते समय यह काफी मुश्किल था।

यह ऊपर जैसा है।

आवश्यकताएँ

इसलिए, आवश्यक आवश्यकताएँ इस प्रकार हैं:

• CMS को पोर्ट-वार अलग किया जा सकता है

• छवियों को कॉपी-पेस्ट करके अपलोड किया जा सकता है, और लिंक भी उत्पन्न होते हैं

• स्मार्टफोन से भी संपादन के लिए आसान डिज़ाइन

• CSS को न्यूनतम रखा जा सकता है, जब तक कि इसे समझा जा सके

  • आखिरकार, यह अनिवार्य रूप से बढ़ेगा, और यह अपरिहार्य है

  • जैसे-जैसे बाहरी निर्भर CSS बढ़ता है, यह समझना मुश्किल हो जाता है, इसलिए मैं इसे जितना हो सके उतना कम करना चाहता हूँ

• JS के बिना भी फ्रंट-एंड को देखने में सक्षम होना

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

• TOC (विषय-सूची) आवश्यक है

  • यह होने से पठनीयता में बहुत अंतर आता है

  • हालांकि, मुझे आश्चर्य हुआ कि Lume का TOC पहले h2 से क्यों शुरू होता था? लेकिन यह काफी हद तक समझ में आता है कि शीर्षक TOC में शामिल नहीं है।

  • लेकिन किसी कारण से, Lume केवल h3 ? तक ही कवर करता था?

    • शायद इसलिए कि डिज़ाइन आसानी से टूट सकता है?

• एक रिच एडिटर और md होने से संपादक आसान हो जाता है

  • स्मार्टफोन से संपादन के लिए

• अब मुझे DB की उपयोगिता का एहसास हुआ है

कार्यान्वयन पर

व्यक्तिगत रूप से, मुझे Pocketbase काफी उपयोगकर्ता-अनुकूल लगा, इसलिए मैंने इसे अपनाया। डेटा बैकअप के लिए, आपको इसे विशेष रूप से लागू करने की आवश्यकता नहीं है; आप मानक वेब UI से बैकअप zip फ़ाइल सहेज सकते हैं।

गोपनीय जानकारी को संभालना भी बहुत आसान है क्योंकि Pocketbase इसे अच्छी तरह से लागू करता है। DB SQLite जैसा लगता है।

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

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

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

inode संख्या या डिस्क I/O की समस्याएँ

SSG में भी इसी तरह की समस्याएँ हैं, लेकिन बिल्ड के बाद फ़ाइलों की संख्या बढ़ने पर डिस्क I/O को तीव्रता से स्कैन किया जाता है। नहीं, नहीं, मैं अनावश्यक डिस्क rw को बढ़ाना नहीं चाहता, यह टिप्पणी छोड़ दें कि लेख inode समाप्त होने तक नहीं बढ़ेंगे।

इस संबंध में, बिल्ड के बाद सार्वजनिक डेटा के लिए वास्तव में इतनी दृढ़ता की आवश्यकता नहीं है। इसलिए,

$ rg tmp
backend/ssr/config.go
13:     staticExportDir  = getEnv("STATIC_EXPORT_DIR", "/tmp/alleycat-static")

इस तरह, डिफ़ॉल्ट रूप से /tmp के तहत आउटपुट करके, स्टैटिक बिल्ड के बाद की फ़ाइलों को RAM पर रखा और वितरित किया जाता है।

छवि डेटा के लिए भंडारण स्थान

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

यह थोड़ा संदिग्ध हो सकता है... लेकिन मैंने कभी भी उस फ़ोल्डर को नहीं देखा जहाँ छवियाँ संग्रहीत हैं, और यह जटिलता को खत्म करने के लिए है। इसके अलावा, Pocketbase पर पुष्टि करना आसान होने का लाभ भी है, इसलिए मैंने ऐसा किया।

अंतिम संसाधन: 500MiB से कम

मुझे लगता है कि यह काफी अच्छा निकला।

बिल्ड करते समय यह ऊपर की छवि जैसा दिखता है, लेकिन स्टैंडबाय संसाधनों के लिए यह लगभग इतना ही है। यह लगभग 150MiB से कम पर स्थिर होता है।

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

तो, फिर मिलते हैं। कृपया मेरा ख्याल रखें।