7 meses desenvolvendo o zod.kr, 5 meses no ar — escolha do CMS e desenvolvimento

Este é um texto de continuação de https://pt.news.hada.io/topic?id=19746.

Aborda os motivos para ter escolhido o Rhymix para construir um site de comunidade coreano e o processo de desenvolvimento do site com Rhymix.

Abaixo está um resumo do ChatGPT.

---

Resumo da escolha do CMS e do desenvolvimento do zod.kr (resumo curto)

• Contexto: Foi considerado que o ecossistema de CMS na Coreia estava muito ultrapassado, mas por razões práticas decidiu-se usar um CMS existente em vez de criar um novo do zero.
• Comparação de CMS:
  • Gnuboard5: Foi descartado por problemas de qualidade de código, segurança e estrutura.
  • Rhymix: Familiar por ser baseado em XE, com estrutura melhorada, suporte a sintaxe moderna e boa extensibilidade → escolha final.
• Vantagens do Rhymix:
  • Muitos recursos modernos, como Composer, estrutura modular, suporte a cache e fila assíncrona.
• Desvantagens:
  • UI de administração antiga, ecossistema de terceiros incompleto, falta de documentação etc.
• Design: Uso de tema responsivo + correção de inúmeros bugs e melhorias em CSS/JS.
• Adição de recursos:
  • Vários recursos implementados internamente, como web push, gerenciamento de eventos, upload com integração ao R2 e funcionalidades para usuários.
• Desenvolvimento de módulos: Falta de manual → implementação por meio de análise de código e entendimento direto da estrutura.

👉 Resumo: em um ecossistema de CMS envelhecido, o Rhymix foi escolhido como uma opção prática, e o zod.kr foi construído de forma estável após muitos testes, erros e customizações.

[jujumilk3]

Muito obrigado por este material tão valioso sobre o desenvolvimento e a operação reais do site. Estou acompanhando e gostando bastante.

[nemorize]

Como usuário que vem usando do XE1 dos primórdios até o Rhymix há mais de uma década, é um conteúdo com o qual dá para se identificar bastante.

Acho que o maior problema é que grande parte do mercado que o Rhymix mira não tem capacidade suficiente para desenvolver por conta própria.

Quem tem essa capacidade, em vez de aceitar a documentação insuficiente, a estrutura ambígua e os legados do XE ou do Rhymix, muitas vezes acaba adotando algo como Laravel.

Assim como o autor do texto original, eu também

1. um painel administrativo com o qual muita gente provavelmente se sente familiar
2. funcionalidades de CMS que, mesmo com alguns pontos frustrantes, não deixam a desejar
3. uma equipe de desenvolvimento do core que incorpora ativamente novas propostas
4. o apego de usá-lo há muito tempo
   e assim por diante, por esses motivos também tenho adotado o Rhymix em alguns projetos novos, mas sempre fico pensando bastante se essa escolha é realmente a certa.

Tenho feito pessoalmente várias tentativas para complementar os pontos que senti falta ao usar o Rhymix como substituto de framework.
https://github.com/nemorize/rx-make (branch develop / projeto PoC sem previsão de produção)

Tenho experimentado várias abordagens, como transformar o Rhymix inteiro em framework/biblioteca, minimizar o acesso às APIs legadas e reconstruir APIs mais modernas (mais ou menos compatíveis com as legadas), mas... isso realmente me faz pensar muito haha...

Nunca tinha organizado essas reflexões de forma clara, então vou aproveitar esta oportunidade para tentar colocá-las em ordem de maneira mais objetiva.