รีวิวหลังพัฒนา zod.kr 7 เดือน เปิดให้ใช้งาน 5 เดือน - ตอนการเลือกและพัฒนา CMS

นี่คือบทความต่อจาก https://th.news.hada.io/topic?id=19746

กล่าวถึงเหตุผลที่เลือก Rhymix เพื่อสร้างเว็บไซต์คอมมูนิตี้ในประเทศ และกระบวนการพัฒนาเว็บไซต์ด้วย Rhymix

ด้านล่างนี้คือสรุปโดย ChatGPT

---

สรุปรีวิวการเลือกและพัฒนา CMS ของ zod.kr (สรุปสั้น)

• พื้นหลัง: มองว่าสภาพแวดล้อม CMS ในเกาหลีล้าสมัยเกินไป แต่ด้วยเหตุผลเชิงปฏิบัติจึงตัดสินใจใช้ CMS ที่มีอยู่แทนการสร้างใหม่
• เปรียบเทียบ CMS:
  • Gnuboard 5: ตัดออกเพราะคุณภาพโค้ด ความปลอดภัย และปัญหาเชิงโครงสร้าง
  • Rhymix: คุ้นเคยเพราะมีพื้นฐานจาก XE และมีการปรับปรุงโครงสร้าง รองรับไวยากรณ์สมัยใหม่ และขยายต่อได้ดี → จึงเป็นตัวเลือกสุดท้าย
• ข้อดีของ Rhymix:
  • มีความสามารถสมัยใหม่หลายอย่าง เช่น Composer, โครงสร้างแบบโมดูล, การรองรับแคช, asynchronous queue
• ข้อเสีย:
  • UI ผู้ดูแลระบบแบบเก่า, ส่วนเสริมจากภายนอกที่ยังไม่สมบูรณ์, เอกสารไม่เพียงพอ เป็นต้น
• ดีไซน์: ใช้ธีม responsive พร้อมแก้บั๊กจำนวนมาก และปรับปรุง CSS/JS
• การเพิ่มฟีเจอร์:
  • พัฒนาเองหลายอย่าง เช่น web push, การจัดการอีเวนต์, การอัปโหลดที่เชื่อมกับ R2, ฟังก์ชันผู้ใช้ ฯลฯ
• การพัฒนาโมดูล: คู่มือมีไม่พอ → จึงวิเคราะห์โค้ดและทำความเข้าใจโครงสร้างด้วยตนเองระหว่างลงมือพัฒนา

👉 สรุป: ท่ามกลางสภาพแวดล้อม CMS ที่ล้าสมัย จึงเลือก Rhymix เป็นทางเลือกที่เหมาะกับความเป็นจริง และผ่านการลองผิดลองถูกกับการปรับแต่งจำนวนมากจนสร้าง zod.kr ได้อย่างมั่นคง

[jujumilk3]

ขอบคุณมากสำหรับข้อมูลที่มีคุณค่าอย่างยิ่งตั้งแต่การพัฒนาเว็บไซต์จริงไปจนถึงการดูแลเว็บไซต์ ผมติดตามอ่านอยู่ด้วยความสนใจมากครับ

[nemorize]

ในมุมของผู้ใช้ที่ใช้งานมาตั้งแต่ช่วงแรก ๆ ของ XE1 จนถึง Rhymix มากว่าสิบปี เนื้อหานี้ชวนให้เห็นด้วยมากเลยครับ

ผมมองว่าปัญหาใหญ่ที่สุดคือ ตลาดส่วนใหญ่ที่ Rhymix ตั้งเป้าไว้ยังขาดความสามารถในการพัฒนาเองโดยตรงอย่างเพียงพอ

ส่วนคนที่มีความสามารถพัฒนาเองได้ ก็มักจะเลือกใช้ Laravel เป็นต้น มากกว่าจะยอมรับเอกสารที่ยังไม่เพียงพอ โครงสร้างที่กำกวม และสิ่งตกค้างแบบเลกาซีของ XE หรือ Rhymix

เช่นเดียวกับผู้เขียนต้นฉบับ ตัวผมเองก็ยัง

1. หน้าแอดมินที่หลายคนน่าจะรู้สึกคุ้นเคย
2. ความสามารถในฐานะ CMS ที่ถึงจะมีจุดน่าเสียดายบ้าง แต่ก็ไม่ถึงกับขาดอะไร
3. ทีมพัฒนาแกนหลักที่พร้อมสะท้อนข้อเสนอใหม่ ๆ อย่างกระตือรือร้น
4. ความผูกพันจากการใช้งานมายาวนาน
   ฯลฯ ด้วยเหตุผลเหล่านี้ ผมจึงยังเลือกใช้ Rhymix กับโปรเจกต์ใหม่บางโปรเจกต์อยู่ แต่ทุกครั้งก็อดคิดหนักไม่ได้ว่าการตัดสินใจนี้เป็นทางเลือกที่ถูกต้องหรือไม่

ผมเองก็ใช้ Rhymix แทนเฟรมเวิร์ก และกำลังลองทำหลายอย่างเป็นการส่วนตัวเพื่อเติมเต็มจุดที่รู้สึกค้างคาอยู่ครับ
https://github.com/nemorize/rx-make (สาขา develop / โปรเจกต์ PoC และไม่มีแผนนำไปใช้โปรดักชัน)

ไม่ว่าจะเป็นการทำให้ Rhymix ทั้งก้อนกลายเป็น framework/library, การลดการเข้าถึง legacy API ให้น้อยที่สุด, หรือการสร้าง API ที่ทันสมัยกว่าขึ้นมาใหม่ให้พอเข้ากันได้กับของเดิม ก็ลองอยู่หลายแนวทางเหมือนกัน แต่...บอกตามตรงว่าหนักใจมากจริง ๆ ครับ ฮ่า ๆ..

ผมไม่เคยลองจัดระเบียบความกังวลนี้ให้ชัดเจนจริง ๆ มาก่อน แต่ถือเป็นโอกาสดีที่จะลองสรุปมันออกมาให้ชัดสักครั้งครับ