我为什么冒险写QuarkAdmin!
写在前面
我知道这个东西是好的,但是我却快坚持不下去了!程序发放出去了,反应却是寥寥无几!
介绍
QuarkAdmin 是一个可以帮你快速搭建管理后台的工具;它提供的丰富组件,能帮助您使用很少的代码就能搭建出功能完善的管理后台。
我为什么写QuarkAdmin
2015年,萌芽
应该是在2015年的时候就有了用后端代码来渲染前端这个想法,那会还是jquery横行的年代,第一个项目是用thinkphp做的叫做minishop,当时的想法很纯粹就是将表单的渲染用类去封装,后台调用类的属性前台组合表单。但碍于当时水平有限,最终流产(其实还有一个原因,后面会讲到)。
2017年,思考
时间来到2017年,由于当时维护的项目越来越庞杂,各种奇葩需求纷至沓来,导致了程序代码越来越乱、质量越来越差;再加上团队里开发人员个各种奇淫技巧任意发挥,致使开发效率极度降低、代码维护成本陡升!这段时间我开始思考如何解决这个问题,首先想到的是要强制规范,这里的强制规范最好是在最底层就给限制上!然后开始了前后端完全分离的计划,在前端框架选型上当时有react、vue两个选项,最好是有一个现成的UI,如果没记错的话那时ElementUI应该是起步比较早的,那会儿还用ElementUI做了个WEB OS,如果你有兴趣可以看看我当时的代码,这是一个仿MAC OS的WEB OS系统,类似当年的WEBQQ,应该说做的还算OK,不过后来很久没有在维护了。
2018年,另一个系统
在2018年的时候,接触到了Ant Design,对比ElementUI,从美观度上来说,个人更喜欢Ant Design;就是因为UI美观的原因,开始了前端用React的旅程,后端的架构还是没有开窍,还用传统FormBuilder类似的思路,当时并没有做出composer的扩展包,你如果感兴趣,可以看看我当时开发的FullStack系统。
2019年,扩展包
当时FullStack也只是简单的做了推广,在团队内部小批量试用;后来有人提出为何不做出扩展包,好吧我承认是一个好主意,于是就着手开发扩展包,在开发扩展包的过程中,逛论坛看到了Laravel-Admin相关介绍,原来早就有人在做了,然后看了一下文档,哇偶!原来Table、Form都可以绑定Model的,一语惊醒梦中人!以前的思路是UI的渲染与数据的操作分开(有一点点类似Laravel-Nova),后来评估绑定了Model对与代码的构架就简单多了!然后就开始了新思路的准备工作。
2020年,诞生
由于疫情的原因,在家有了一定思考新架构的时间,于是整理了一下架构:CMS、UI、Admin。
CMS:基于Admin后台开发的内容管理系统;
UI:通过接口动态生成页面的前端引擎;
Admin:通过代码给UI引擎提供Json数据,UI生成页面。
于是就有了:QuarkAdmin
一些感悟
Vue 与 React
Vue入门简单、React入门难度高一点;对于大项目我更倾向于React,对于项目维护更友好。
为什么选择QuarkAdmin
现在QuarkAdmin的竞品有很多,例如:Laravel-Admin、Dcat-Admin等;QuarkAdmin选择的解决方案是前后端完全分离,前端引擎规范接口数据,并不会排斥任何后端语言(也没准将来出java版)。拥抱React丰富的组件生态,React、Vue必然是王道!选用Ant Design Pro作为前端解决方案,各种组件套餐应有尽有!对比Laravel-Admin,QuarkAdmin彻底摒弃Jquery的开发模式,摆脱JS库东拼西凑的尴尬局面!前后端完全分离开发体验真的是超爽的,无论是后端还是前端都清晰明了!
希望得到支持
希望您能多多关注我的项目,您的关注是我前进的最大动力
github CMS仓储:quark-cms
github 后端仓储:quark-admin
github 前端仓储:quark-ui
如果可以您可以捐助我

本作品采用《CC 协议》,转载必须注明作者和本文链接
推荐文章: