CMS 开发框架准备开源，想征求一下大家的意见

大家好，

我们公司（ The Plant ）打算开源一个 CMS 的开发框架 QOR5。在正式开源之前，希望能听取一下大家的意见🙏

QOR5 经过多年迭代，经历了

QOR1 (Ruby on Rails 2010)
QOR2 (Ruby on Rails 2012)
QOR3 (Go 2014 —— 已开源 5.1k stars)
QOR5 (Go 2021)

每个大版本都有很多进步。开源的目的一是回馈社区，二是汲取社区的力量，把项目做的更好。

下面的一些问题希望大家有空讲讲

你 /公司现在用什么 CMS 系统？商用 SaaS/自研 /开源？
你 /公司平时用什么框架来开发 CMS ？有什么优缺点？
在开发 CMS 的时候，有什么经常遇到的问题？
你 /公司是否尝试过使用新的框架来开发？如果有，为什么？

文档地址 文档内多数示例代码可直接运行。 demo 网站稍后更新

目前我们总结的 QOR5 的特色:

在 Admin 界面开发方面

速度

QOR5 Admin 集成了 Vuetify ，大量预置组件可以直接使用，无需重复开发。管理界面可由后端独立完成，基本无需前端参与。

我们以前做项目时，复杂一些的管理页面都是后端工程师提供好前端所需的数据，前端在数据的基础上构建出页面，这需要两个团队的密切配合。在去年冬天开发的一个中型项目中，我们使用了 QOR5 ，3 个后端开发人员就做完了之前需要 3 后端 + 2 前端的工作，而且这个项目的管理界面比一般的 CMS 要更复杂，因为它不是一个支撑管理某些前台业务的后端管理系统，而是一个没有前端，核心是数据筛选和自动匹配的数据处理系统，加上客户之前习惯使用 Excel 来进行工作，为了照顾他们的习惯，做出来的 list 页面比较接近 Excel 。但即便这样，我们的 3 个后端开发人员也足以在 QOR5 的帮助下，高效地完成了项目。

灵活

在使用预置组件快速构建系统的前提下，提供了友好的扩展接口及开放性，程序员完全有自由来实现各种需求

界面可见的位置基本都可以通过相关函数进行配置，无论是处理逻辑还是显示逻辑都可自定义。所有默认的 CRUD 行为都可以自定义. 预置的组件不满足需求的时候，开发一个新的也完全没问题。

健壮

系统完全由 Go 开发(htmlgo)，继承了编译语言的优势，减少了 runtime error 。

与 Go 原生的 tmpl 相比，纯用 Go 写的模板文件大幅度地减少了模板里可能出现的 runtime error. 很多错误都会在写代码的时候被发现，程序健壮性大大提高。且避免了难用的 tmpl 语法，直接用 Go 的语法写模板。

内置了丰富的组件，大多数情况下不需要自己再写 JavaScript ，也减少了 JavaScript 的 runtime error 出现的概率。

方便部署

整个 App 编译成一个可执行文件，不必考虑是否二进制化模板文件，或者需要向服务器上同步模板文件。

部署过用原生 Go 模板的项目的同学应该有经验，模板的处理是个麻烦。要么使用 bindata 之类的工具编译模板，但这导致每次模板的更改都需要重新编译，而且在多人协作的环境中，Git 合并时经常因为编译的二进制文件导致冲突。另一个解决方案是在部署的时候同步上传模板文件，但这要去协调 App 和模板间的路径、缓存问题等等，给 SRE 团队造成了很多不便。使用 QOR5 之后，这些令人头疼的问题就都解决了，因为所有的模板文件都是用 Go 写的，直接一键编译部署就可以。

在资源方面

持续更新的文档

QOR5 文档里的示例代码是可以直接执行的, 这保证了文档必须与最新的代码一致，否则编译无法通过。这会半强制地帮助我们持续更新文档，减少文档过期情况的出现。

新手友好

开源之后我们会推出完整的视频教程，不仅仅是介绍如何使用 QOR5 ，并且还能让初接触编程的同学，完整地学习体验一次，如何从头开发到最终部署上线一个 EC 网站。

我们计划增加 4 个预置模板，CMS, EC Shopping, EC Restaurant 和 Blog. 花一分钟安装就能工作，无论是学习还是作为种子项目都会很方便。

代码通俗易懂

我们有 12 年的框架开发经验，从 rails 时代过来，深刻体会过项目大了之后找一个函数定义都找不到的痛苦。所以在设计 QOR5 时，严格遵循了 less magic code 的原则，尽最大可能去避免使用各种 hook 之类的隐式调用, 绝大多数逻辑都是显式调用，也就是说跟着函数的调用流程，你可以弄清楚绝大部分的功能是如何运行起来的。