7 meses desarrollando zod.kr y 5 meses tras su lanzamiento: elección y desarrollo del CMS

Es una publicación de seguimiento de https://es.news.hada.io/topic?id=19746.

Aborda por qué se eligió Rhymix para construir un sitio de comunidad local y el proceso de desarrollo del sitio usando Rhymix.

A continuación, un resumen de ChatGPT.

---

Resumen de la elección del CMS y desarrollo de zod.kr (resumen breve)

• Contexto: Se consideró que el entorno de CMS coreano estaba demasiado obsoleto, pero por razones prácticas se decidió usar un CMS existente en lugar de crear uno nuevo.
• Comparación de CMS:
  • Gnuboard5: Quedó descartado por problemas de calidad de código, seguridad y estructura.
  • Rhymix: Basado en XE, resultaba familiar y ofrecía mejoras estructurales, soporte para sintaxis moderna y buena extensibilidad → fue la elección final.
• Ventajas de Rhymix:
  • Muchas funciones modernas, como Composer, estructura modular, soporte de caché y colas asíncronas.
• Desventajas:
  • UI de administración anticuada, ecosistema de terceros incompleto y falta de documentación.
• Diseño: Uso de un tema responsivo + corrección de numerosos errores y mejoras en CSS/JS.
• Funciones añadidas:
  • Se implementaron internamente varias funciones, como web push, gestión de eventos, subidas integradas con R2 y funciones para usuarios.
• Desarrollo de módulos: Falta de manuales → implementación mediante análisis del código y comprensión directa de la estructura.

👉 Resumen: En un entorno de CMS anticuado, se eligió Rhymix como una opción realista, y tras mucha prueba y error y personalización, se logró construir zod.kr de forma estable.

[jujumilk3]

Muchas gracias por este material tan valioso sobre el desarrollo y la operación real del sitio. Lo estoy leyendo muy bien.

[nemorize]

Como usuario que viene usando esto desde los primeros tiempos de XE1 hasta Rhymix durante más de una década, es un contenido con el que empatizo bastante.

Creo que el mayor problema es que gran parte del mercado al que apunta Rhymix no tiene suficiente capacidad para desarrollar por cuenta propia.

Quienes sí tienen esa capacidad suelen optar por adoptar Laravel y similares, en lugar de tolerar la documentación insuficiente, la estructura ambigua y el legado de XE o Rhymix.

Al igual que el autor del texto original, yo también

1. una página de administración que a mucha gente le resultará familiar
2. funciones como CMS que, aunque tengan detalles mejorables, no se sienten insuficientes
3. un equipo de desarrollo del core que incorpora activamente nuevas propuestas
4. el cariño de haberlo usado durante mucho tiempo
   por razones como esas, sigo adoptando Rhymix en algunos proyectos nuevos, pero cada vez termino preguntándome mucho si esta elección realmente es la correcta.

He estado probando personalmente varios enfoques para complementar las partes que me parecieron limitadas al usar Rhymix como sustituto de un framework.
https://github.com/nemorize/rx-make (rama develop / proyecto PoC, no está previsto llevarlo a producción)

He intentado varias cosas, como convertir Rhymix entero en un framework/librería, minimizar el acceso a las API legacy y reconstruir API más modernas (más o menos compatibles con lo legacy), pero... de verdad me hace pensar muchísimo jaja...

Nunca había puesto en orden estas dudas de forma clara, así que voy a aprovechar esta oportunidad para organizarlas de una vez con más claridad.