यह https://hi.news.hada.io/topic?id=19746 की फ़ॉलो-अप पोस्ट है.
घरेलू कम्युनिटी साइट बनाने के लिए Rhymix को चुनने के कारण और Rhymix के साथ साइट डेवलपमेंट की प्रक्रिया पर चर्चा की गई है.
नीचे ChatGPT का सारांश है.
zod.kr CMS चयन और डेवलपमेंट अनुभव का सारांश (संक्षिप्त सार)
- पृष्ठभूमि: यह निष्कर्ष निकाला गया कि कोरियाई CMS इकोसिस्टम बहुत पुराना हो चुका है, लेकिन व्यावहारिक कारणों से नया बनाने के बजाय मौजूदा CMS का उपयोग करने का निर्णय लिया गया.
- CMS तुलना:
- Gnuboard5: कोड क्वालिटी, सुरक्षा और संरचना संबंधी समस्याओं के कारण बाहर किया गया.
- Rhymix: XE-आधारित होने से परिचित, और बेहतर संरचना, modern syntax support तथा अच्छी extensibility के कारण अंतिम चयन.
- Rhymix के फायदे:
- Composer, modular structure, cache support, async queue जैसे कई आधुनिक फीचर.
- कमियां:
- पुराना admin UI, अधूरे third-party components, documentation की कमी आदि.
- डिज़ाइन: responsive theme का उपयोग + कई bugs को ठीक करना और CSS/JS में सुधार.
- फ़ीचर जोड़ना:
- web push, event management, R2 integration upload, user features आदि कई चीजें खुद implement की गईं.
- मॉड्यूल डेवलपमेंट: manual की कमी के कारण code analysis और खुद structure समझते हुए implementation किया गया.
👉 सार: पुराने CMS माहौल में व्यावहारिक विकल्प के रूप में Rhymix को चुना गया, और बहुत से trial and error तथा customization के जरिए zod.kr को स्थिर रूप से बनाया गया.
2 टिप्पणियां
वास्तविक साइट डेवलपमेंट और ऑपरेशन तक, इतनी मूल्यवान सामग्री के लिए बहुत धन्यवाद। मैं इसे बहुत ध्यान से पढ़ रहा हूँ।
XE1 के शुरुआती दौर से लेकर Rhymix तक, इसे दसियों साल से इस्तेमाल कर रहे एक यूज़र के नज़रिए से देखें तो यह बात काफ़ी relatable लगती है.
मेरे हिसाब से सबसे बड़ी समस्या यह है कि Rhymix जिस बाज़ार को target करता है, उसमें बड़ी संख्या में ऐसे लोग हैं जिनके पास खुद development करने की पर्याप्त क्षमता नहीं है.
और जिन लोगों के पास खुद development करने की क्षमता है, वे अक्सर XE या Rhymix की कमज़ोर documentation, अस्पष्ट structure और legacy चीज़ों को सहने के बजाय Laravel वगैरह अपनाने का चुनाव करते हैं.
मूल पोस्ट के लेखक की तरह, मैं भी
आदि वजहों से कुछ नए projects में Rhymix अपना रहा हूँ, लेकिन हर बार यह सोचने पर मजबूर होना पड़ता है कि क्या यह चुनाव सही है.
Rhymix को framework के विकल्प की तरह इस्तेमाल करते हुए जो कमियाँ महसूस हुईं, उन्हें पूरा करने के लिए मैं निजी तौर पर कई तरह के प्रयोग कर रहा हूँ.
https://github.com/nemorize/rx-make (develop branch / PoC project, production की कोई योजना नहीं)
जैसे Rhymix को पूरी तरह framework/library बना देना, legacy API तक पहुँच को न्यूनतम करना, और थोड़ा अधिक modern API को (legacy के साथ मोटे तौर पर compatible रहते हुए) फिर से बनाना—ऐसे कई तरह के प्रयास कर रहा हूँ, लेकिन... सच में इस पर बहुत ज़्यादा सोच-विचार करना पड़ता है, हाहा..
मैंने इस दुविधा को पहले कभी साफ़ तौर पर व्यवस्थित करके नहीं देखा था, लेकिन इस मौके पर इसे एक बार स्पष्ट रूप से整理 करके देखना चाहिए.