如何架构一个中后台项目的前端部分?

更新日期: 2019-08-16阅读: 2.9k标签: 架构

前言

最近我正在公司做一个中后台管理系统的前端框架搭建工作,虽然说公司已经有现成的中后台框架可供选择,但是并不特别适合我们部门的项目,因此在借鉴原有框架的基础上融入了我的一些个人想法和思考在里面。

这篇文章便主要来谈谈在架构一个中后台系统的前端部分上我的实践点。


技术选型

不管是前端抑或后端,从零开始做一个新项目避免不了技术选型这一块,其应该也是最先需要考虑的内容,之后的一切都会建立在这之上。

1. JS 框架

考虑到公司和部门的主流技术栈及组员的技术能力,我们选择的主要前端技术栈是 vue。这一选择其实不难,接下来需要考虑的便是围绕这一技术栈,选出子技术栈。

既然用到 Vue,那么为了快速构建项目,我们必然会选择使用其脚手架工具(最新版本是 Vue CLI 3)来构建基础的工程。

另外不可或缺的还有 Vue 的路由库 Vue Router 和 状态管理工具 Vuex,这在 Vue 项目中基本都会用到。此外,考虑到项目会做国际化功能,我们还加入了 vue-i18n 这一官方库做国际化配置。

2. UI 框架

由于我们所要架构的是一个中后台系统,因此采用一套 UI 框架来负责我们视图层面的开发是必不可少的。把比较小众的排除在外,目前在 PC 端主流的 Vue UI 框架莫过于 Element UI 和 iView 做的比较好。而公司现有框架采用的是 Element UI,为了体现不同之处,我们选择了 iView(毕竟其也有 iView-admin 这样的中后台框架)。

3. Node 框架

考虑到前端后端分离后,前端需要启用自己的服务来跑打包后的资源,因此虽然我们本地可以使用 webpack 的 devServer 来实现,但是发布到 node 服务器上则需要有一个脚本来启动服务,这里我们选择小巧可配置的 Koa2 框架来实现(后期会逐渐拓展,实现 node 中间层)。

4. 其他

JS 框架、UI 框架及服务端框架选型都落实之后,我们还需要考虑除框架本身外的其他技术,比如我们选择了 axios 来实现接口的请求,使用 less 来预处理 css 样式,使用 mockjs 来实现接口的数据模拟等。

最后用一张图例来概括项目技术栈,如下:



目录结构

根据上述技术栈,我们实现了以下目录结构的搭建,下面是整个项目的目录结构大纲:

├── /build/             # vue cli 所需编译配置
│ ├── /lib/             # 编译工具库
| └── pro-server.js     # 跑静态资源包的 node 服务
├── /config/            # webpack 环境配置
├── /dist/              # 打包的资源
├── /public/            # html 模版等公共资源
| └──index.html         # html 模版文件
├── /docs/              # 项目文档资源
├── /src/               # 项目工作区域
│ ├── /assets/          # 项目图片资源文件
│ ├── /common/          # 项目公共方法  脚本文件
| | ├── /libs/          # 依赖js库
| | ├── utils.js        # 项目工具集
| | └── variable.js     # 项目常量管理
│ ├── /components/      # 项目公共组件
│ ├── /config/          # 项目配置文件  全局配置数据
| | ├── global.js       # 全局数据
| | └── apiUriConf.js   # api 接口配置文件
│ ├── /lang/            # 项目国际化配置
│ ├── /mock/            # 接口 mock 配置文件
│ ├── /router/          # 路由配置文件
│ ├── /services/        # 接口封装 地址文件
│ ├── /store/           # vuex 配置文件
│ ├── /views/           # 页面组件
│ ├── App.vue           # 全局父组件
│ ├── index.less        # 全局样式
│ └── main.js           # 项目入口文件
├── .browserslistrc     # 浏览器支持配置
├── babel.config.js     # 用来设置转码的规则(babel)和插件(环境调用)
├── .editorConfig       # 代码编辑工具默认格式
├── .eslintignore       # eslint不处理,忽略路径配置
├── .eslintrc.js        # eslint详细规则配置
├── postcss.config.js   # postcss 配置文件
├── .gitignore          # git忽略上传的文件
├── .npmrc              # npm 源配置文件
├── package-lock.json   # 安装高版本npm才会有
├── .prettierrc.json    # 代码风格配置
├── package.json        # 项目依赖
├── README.md           # 项目安装启动介绍
├── vue.config.js       # vue cli3 入口配置文件
└── yarn.lock           # yarn 依赖


结语

技术选型是项目开发的前提条件,使用优秀稳定的技术才能保障整个系统开发的稳定和易维护。本文的技术选型大家可以用作参考,具体需要结合公司或部门项目的实际情况出发。

原文来自微信公众号:前端呼啦圈(Love-FED) 

 

链接: https://fly63.com/article/detial/5330

微内核架构在大型前端系统中的应用

架构和框架是独立的,本文仅仅是提出一种架构思路,而且这个架构也在百度的某款用户量很大的复杂前端产品中得以应用。基于这一套弹性架构并结合Vue/React的现代化开发理念,可以很好的完成高复杂度的前端系统。

怎么判定web前端架构师的能力高低?

软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。传统软件架构描述的对象是直接构成系统的抽象组件,侧重于系统的抽象、拆分、组织方式等

成为一个顶尖架构师

架构师的一个重要职责是,确保团队有共同的技术愿景,以帮助我们向客户交付他们想要的系统。在某些场景下,架构师只需要和一个团队一起工作,这时他们等同于技术引领者。在其他情况下,他们要对整个项目的技术愿景负责,通常需要协调多个团队之间,甚至是整个组织内的工作。

C/S和B/S两种架构区别与优缺点分析

C/S 架构是一种典型的两层架构,其全程是Client/Server,即客户端服务器端架构,其客户端包含一个或多个在用户的电脑上运行的程序,而服务器端有两种,一种是数据库服务器端,客户端通过数据库连接访问服务器端的数据

架构/构建高可用的网站

目的为保证服务器硬件故障时依然可用,数据依然保持并能够访问,手段:数据和服务的冗余备份以及失效转移机制,有状态 :在服务端保留之前的请求信息,用以处理当前请求(例如:session)无状态 :没有特殊状态的服务

大型web系统架构详解

动态应用,是相对于网站静态内容而言,是指以c/c++、php、Java、perl、.net等服务器端语言开发的网络应用软件,比如论坛、网络相册、交友、BLOG等常见应用。动态应用系统通常与数据库系统、缓存系统、分布式存储系统等密不可分。

讲讲亿级PV的负载均衡架构

本来没想写这个题材的,为了某某童鞋能够更好的茁壮成长,临时写一篇负载均衡的。负载均衡,大家可能听过什么3层负载均衡、4层负载均衡、7层负载均衡什么的?那这是怎么分的呢,ok,是根据osi七层网络模型来分的,例如nginx是工作在应用层

朱晔的互联网架构实践心得:品味Kubernetes的设计理念

Kubernetes(k8s)是一款开源的优秀的容器编排调度系统,其本身也是一款分布式应用程序。虽然本系列文章讨论的是互联网架构,但是k8s的一些设计理念非常值得深思和借鉴,本人并非运维专家,本文尝试从自己看到的一些k8s的架构理念结合自己的理解来分析 k8s在稳定性

大型网站核心架构要素

一般来说,除了当前的系统功能需求外,软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。性能是网站的一个重要指标,任何软件架构设计档案都必须考虑可能会带来的性能问题。

大型网站技术架构 构建高可用的网站 高可用的服务

本章介绍如何去构建高可用的服务,关键词:服务分级,超时设置,异步调用,服务降级,幂等性设计,一些架构设计中的常用方案,但是需要结合实际业务场景进行设计,没有一套方案能解决所有问题

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!