zod.kr 開発7か月、公開5か月の振り返り - CMS選定と開発編

https://ja.news.hada.io/topic?id=19746 の続編です。

国内コミュニティサイトを構築するためにRhymixを選んだ理由と、Rhymixによるサイト開発の過程を扱います。

以下はChatGPTによる要約です。

---

zod.kr CMS選定および開発レビュー要約（簡易要約）

• 背景: 韓国のCMS環境はあまりにも古いと判断したが、現実的な理由から新規開発はせず、既存CMSの利用を決定。
• CMS比較:
  • Gnuboard 5: コード品質、セキュリティ、構造上の問題から除外。
  • Rhymix: XEベースで馴染みがあり、構造改善・モダンな文法対応・拡張性に優れる → 最終選定。
• Rhymixの長所:
  • Composer、モジュール化構造、キャッシュ対応、非同期キューなど現代的な機能が多数。
• 短所:
  • 古い管理者UI、不完全なサードパーティー、ドキュメント不足など。
• デザイン: レスポンシブテーマを活用しつつ、多数のバグ修正とCSS/JS改善を実施。
• 機能追加:
  • Web Push、イベント管理、R2連携アップロード、ユーザー機能などを多数独自実装。
• モジュール開発: マニュアル不足のため、コード分析と独自の構造把握を行いながら実装。

👉 要約: 古いCMS環境の中で現実的な選択としてRhymixを採用し、多くの試行錯誤とカスタマイズを通じてzod.krを安定的に構築した。

[jujumilk3]

実際のサイト開発と運営まで、とても貴重な資料をありがとうございます。いつも興味深く拝見しています。

[nemorize]

XE1の初期のころからRhymixに至るまで十数年使ってきたユーザーの立場として、とても共感できる内容ですね。

Rhymixがターゲットにしている市場の大半が、直接開発するための十分な能力を持っていない点が、いちばん大きな問題だと思います。

自分で開発できる人たちは、XEやRhymixの不足したドキュメント、曖昧な構造、レガシーな部分を甘受するよりも、Laravelなどを採用することが多いでしょうし。

元記事の筆者の方と同じく、私もまた

1. 多くの人が馴染みやすいと感じる管理者ページ
2. 多少物足りなさはあっても、不足はないCMSとしての機能
3. 新しい提案を積極的に反映するコア開発チーム
4. 長年使ってきた愛着
   などの理由から、いくつかの新規プロジェクトでRhymixを採用していますが、そのたびにこの選択が本当に正しいのか、かなり悩んでしまいます。

Rhymixをフレームワーク代わりに使いながら、物足りなかった部分を補おうと個人的にいろいろ試しているのですが。
https://github.com/nemorize/rx-make (developブランチ / PoCプロジェクトのため本番投入予定なし)

Rhymixを丸ごとフレームワーク/ライブラリ化してしまうとか、レガシーAPIへのアクセスを最小限にして、もう少しモダンなAPIを（レガシーとおおむね互換性を持たせつつ）再構築するといった、いろいろな試みをしていますが……本当にものすごく悩みますね（笑）

この悩みを明確に整理したことはなかったのですが、これを機に一度はっきり整理してみようと思います。