关于前端:如何使用startCMS进行应用开发前端开发后端开发

7次阅读

共计 3243 个字符,预计需要花费 9 分钟才能阅读完成。

简介

StartCMS 是一个基于 ThinkPHP6.0+、ElementUI、MicroApp 的极速微利用开发框架
前端不限技术栈,反对 Vue2、Vue3、Vite、React、Rangular…
后端不限度语言,反对 PHP、Java、Node、Python、Go、C#… 

一、本文接续上一篇文章,介绍如何应用 startCMS 进行利用开发

        如果您对 StartCMS 有纳闷,倡议先浏览下方文章来理解更多。浏览本文前倡议先浏览上面两篇文章,否则可能会看不明确一些操作。

微前端框架 StartCMS,一个基于微前端架构的极速微利用开发框架,开源框架

微前端框架 StartCMS,如何启动框架,startCMS 启动教程

二、框架目录

如果您没有看过官网文档 STARTCMS,请看下方目录介绍,详情可进入官网文档查看。

www  WEB 部署目录
├─app                   利用目录
│  ├─app1               利用 1
│  ├─app2               利用 2
│  ├─app3...            
├─base                  前端基座工程 (可挪动到任意中央进行前后端拆散开发)
├─config                系统配置目录
├─core                  系统核心目录
├─data                  数据存储目录
├─extend                扩大类库目录
├─runtime               利用的运行时目录(可写,可定制)├─vendor                Composer 类库目录
├─web                   前端基座目录 (由基座工程目录编译生成)
├─.env.default          环境示例文件
├─.gitignore            Git 配置文件
├─.htaccess             Apache 配置文件
├─composer.json         Composer 配置文件
├─deploy.sh             自动化部署脚本
├─index.php             零碎入口文件
├─start                 命令行入口 

二、如果基于 PHP 开发

        因为 startCMS 框架自身基于 PHP 开发,如果您也刚好应用 PHP 开发,那您能够应用命令行生成一个 app 利用。生成命令为

php start make:app 利用名 

执行前 app 目录中只有.gitignore 文件,执行 php start make:app test 后,app 目录会生成 test 利用。如下图所示。

如图所示,test 利用中存在 3 个目录以及 app.json,文件 controller,model,service 这里不做阐明,次要解说 app.json, 上面是 app.json 配置信息

{"app": "",               // 利用标识 ( 默认缺省,装置时自动识别)"app_title":"",         // 利用名称 (默认缺省,装置时自动识别)
    "group": "站点配置",      // 配置分组 (可选)
    "title": "站点名称",      // 配置名称
    "type": "input",         // 输出类型
    "field": "title",        // 字段名称 (确保同一利用内惟一)
    "value": "StartCMS",     // 字段值 (可选)
    "options": [],           // 配置选项 ( 可选)
    "validate": [],          // 验证规定 ( 可选)
    "props": {},             // 配置属性 ( 可选)
    "default": "",           // 默认值 (可选)"remark":"",            // 备注 (可选)
    "locking": 0,            // 是否锁定 (禁止编辑更新)
    "protected": 0           // 是否爱护 (前端无奈获取)
}

下图是 test 主动生成的配置信息

启动框架进入零碎,不晓得怎么启动的,倡议先看下方文章

微前端框架 StartCMS,如何启动框架,startCMS 启动教程

 启动零碎后,点击关上右上角利用配置

 如果 app 中没有利用,那么此时利用核心为空。

创立 test 利用后,表格中会呈现 test 利用的信息,app.json 中能够批改 test 利用信息,具体请查看官网文档。

到这一步,后端工作根本筹备实现。点击启用装置利用。装置胜利后刷新页面

刷新后装置的利用就会呈现在左侧侧边栏了

因为短少前端工程,以后的 test 利用点击是没有内容的,以 vue2 示例,来介绍如何构建前端工程。关上终端,进入 test 利用,应用命令 vue create vue2 创立 vue2 模板

创立实现后批改 vue.config.js,因为此时框架启动在 8080 端口,且 test 利用也在框架外部,并没有启动其余的服务器,所以配置代理以及批改动态资源门路如下,如果利用须要申请资源是其余服务器,更改代理即可。

module.exports = defineConfig({
  publicPath: '/app/test/view/',
  transpileDependencies: true,
  devServer: {
    port: port,
    open: false,
    overlay: {
      warnings: false,
      errors: true
    },
    proxy: {[process.env.VUE_APP_BASE_API]: {
        target: 'http://localhost:8080',
        changeOrigin: true,
        pathRewrite: {['^' + process.env.VUE_APP_BASE_API]: '/'
        }
      }
    },
    headers: {'Access-Control-Allow-Origin': '*'}
  }
})

批改实现后应用 npm run build 打包,这时会生成 dist 文件夹,将 dist 文件夹重命名为 view, 挪动至 test 目录下,或者手动创立 view 目录,将 dist 下所有文件复制或挪动到 view 中。

 这时咱们的动态资源,也就是 index.html 曾经筹备实现了,但这个时候,点击 test 利用如下

谬误的起因是因为拜访 http://localhost:8080/web/test 时,服务器并没有做出回应,关上 controller 目录中的 index.php, 退出下方代码来渲染 index.html

 刷新页面,就能够看到 vue 的模板页面了

实际上每一个利用的外围就是 controller,model,service,view,app.json 这些文件

view 即打包后的目录也是前端代码,app.json 是利用配置,controller,model,service 形成服务器响应前端。这些加起来也就形成了一个独立的利用。

三、如果后端应用 java,python 或其余语言

  • 如果后端曾经上线服务器,那么只须要在前端配置代理与动态资源门路,在后端那边渲染前端 html 页面即可,后端的代码也能够不放在框架外部。
  • 如果是本地开发,并未上线,以 java 为例,无论您的后端代码是否在框架利用内,您只须要启动您的 java 后端,开启一个端口,而后将这个端口替换掉前端 vue.config.js 中的 8080 即可,前万不要遗记配置动态资源门路,千万不要遗记渲染 index.html,并且不须要加多余门路,渲染 /index 即可,框架基座会主动找到利用下的 view 目录。

四、总结 

        startCMS 框架的核心思想就是微前端,微利用,开发者能在同一个我的项目中应用不同语言,后端能够同时用 java,python,PHP 写,前端也能同时用 vue,react,angular 写。

        比方一个商城零碎,有商品模块,订单模块。那么咱们能够把这两个模块做成利用,如果商品模块应用 vue 更容易,而订单模块应用 react 更好,按以前失常框架是无奈实现的。而 startCMS 能够实现这一点,并且,如果其中一个模块须要降级某个依赖包,而降级后又会对另一个模块产生影响,这时应用 startCMS 齐全不必放心。

startCMS 次要解决以下问题:
1、随着我的项目迭代前端工程越来越宏大,难以保护 => 我的项目利用化,只须要保护利用。
2、跨团队或跨部门合作开发我的项目导致效率低下且受根底框架技术限度 => 利用化之后,每个利用都能够应用不同语言,不同框架。
3、不同业务模块须要应用不一样的依赖,随着时间推移依赖抵触重大且不反对增量降级 => 利用之间互相独立,互不依赖,降级模块时不必放心影响其余性能。
4、市场现有多模块零碎,后端尽管做到了模块化并前后端拆散,但前端工程实质上仍然属于单体架构。

正文完
 0