基于 Express 应用框架的技术方案选型浅谈

前言

如今的 Node 对于前端而言能够涵盖各个方面，包括命令行接口、插件、依赖库、脚手架以及 Web 服务等。本文是一篇对于 Node 使用的浅谈文章，会简单讲解一些我的使用 Node 的经验，分享的内容主要可分为三个方面：

• 工具篇
• 插件篇
• 服务篇

工具篇会讲解使用 NPM 发布命令行接口的简单教程。插件篇主要讲述如何开发一个有趣的 Webpack 插件（Vue CLI / Babel 插件同理）。服务篇会讲解一些基于 Express 应用框架的技术选型方案，这类技术每每对于作一些前端工具平台很是有用（例如 Mock 平台、多语言平台等，每每可配合命令行接口进行设计）。因为篇幅较长，本文只讲解服务篇内容。

舒适提示：这里的服务篇主要讲解了一些本身搭建 Express 应用的经验，是本身学习 Node 的一个过程。你们若是喜欢折腾或者想作一些前端的工具平台能够按照这种思路去尝试，可是若是要作业务项目，你们仍是要选择一些成熟稳定的技术方案，考虑的方面须要更多。

Web 应用框架

基于 Node.js 的 Web 应用框架不少，包括但不限于

• Express ： 已经成为开发 Node.js WEB 应用的标准框架，大多数工程师都很熟悉他的设计思想（极简的内核，但能让你用各类中间件来扩展他的功能）
• Koa ：设计思想很是相似 Express，区别在于它是使用 ES6 中的 generator 编写，这种写法解决了你们所熟知的回调地狱问题
• Feathers：用来实现面向服务架构的一种灵活的解决方案，很是适合建立 Node.js 微服务
• Sails ：是一个全能的 MVC 框架，主要是受到 Ruby on Rails 启发，已经存在很长时间，支持各类数据库，不论是 SQL 仍是 No-SQL
• Egg ：为企业级框架和应用而生
• Modal：建立基于 PostgreSQL 的无状态的、分布式的服务
• Keystone：快速搭建基于 MongoDB 的管理后台的最佳解决方案，基于数据模型的定义便可自动生成后台界面，支持常见的增删改查操做和灵活的数据过滤
• Loopback：内置了不少特性的成熟框架，支持基于 token 的认证，支持各类数据库。 loopback 的“杀手锏”功能是 API 浏览器，该功能能让开发者用很是直观的方式查看全部的 API 接口，若是你须要建立 API 服务的话，它无疑是个很好的选择

这里盗一张 2019 Node.js Frameworks star 状况（供你们参考）：

本文主要讲解 Express 应用框架，虽然它提供的能力很是简单，但对于一些工具平台的开发彻底能够胜任，而且能够写出各类千奇百怪的 MVC 模式（若是对服务端 MVC 不是很清晰能够阅读 服务端 MVC 之 Model2 的衍生）。这里简单介绍之前设计的几种基于 Express 扩展的技术选型方案，刚好涵盖了 React、Angular 以及 Vue 这三个 Web 前端框架。

舒适提示：接下来使用的示例项目都相对简单，但愿对刚入门 Express 的小白们有所启示。

React 技术方案选型

2016年7月到10月，从零开始学习 React 并使用 React 设计了服务端渲染的 Express 应用（同年10月25日诞生了 Next.js ），大体的技术选型以下：

• Bootstrap
• React
• Mongoose
• Webpack
• Karma/Chai

因为对 React 不是很熟悉，首先实现了单页应用，而后实现了服务端渲染应用。

实现 React 单页应用（SPA）

React 学习和设计过程

在使用 React 以前只会简单的使用 Bootstrap，当时对 React 的学习历程大体以下：

• 学习 React 语法
• 学习 ES6 / ES7 语法
• 学习 Babel / Webpack，打包代码支持 ES6 / ES7 / JSX 语法
• 学习 webpack-dev-server / Hot Module Replacement，启动开发环境的 Express 服务，实现热加载功能
• 学习 flux / react-redux
• 学习 react-router
• 学习 mocha / karma

学习总结文档以下：

• Webpack
• Server
• React-Redux
• React-Router
• Mocha
• Karma

以上学习过程记录在 react-demo 和 react-start-kit （小而全的概念性参考价值）中，此时只是简单的 React 单页应用设计过程。大体结构以下：

舒适提示：在先后端分离的开发模式中，若是 Web 前端实现的是 SPA（单页应用），服务端能够选用不一样的设计语言，例如 Node.js、Java 或者 Golang 等。Web 前端能够经过 Express渲染服务器 进行后端的请求代理转发。若是想要前端先行，可使用 Easy Mock 或者本身设定的 JSON 数据模拟后端提供的接口规范。

Express 服务端设计过程

服务端的设计选用 Node.js 的 Express 框架，大体实现步骤以下：

• 搭建服务端 Express，设计服务端 MVC 目录结构
• 设置 Express 的静态资源目录，将 Web 前端的 Webpack 构建目录设置成 Express 的静态资源目录
• 设置单页应用的路由和路由服务
• 启动服务查看页面是否能够渲染成功

以上实现过程记录在一个简单的示例 rewatch 里，入口文件是 app.js。此时先后端分离，能够同时启动服务端 Express 服务和启动开发态 React 调试页面服务（webpack-dev-server），并使用开发态页面向 Express 服务发送请求获取接口数据（当时使用 JQuery 的$.ajax 发送请求）。设计完成后将开发态页面使用 Webpack 打包构建，构建目录为服务端 Express 的静态资源目录。首屏渲染的工做交给 Ejs 模板引擎（事实上也能够直接使用 HTML 字符串渲染）进行处理。大体结构以下：

实现 React 服务端渲染（SSR）

单页应用在路由跳转时不须要额外的请求静态资源，能够提高用户的体验。可是若是应用较大，首次请求静态资源和进行页面动态渲染的过程当中会产生如下问题：

• 首屏加载慢，产生白屏效果
• 不利于 SEO

为了解决上述客户端的渲染问题，须要实现 React 服务端渲染。因为当时还没出现成熟的服务端渲染应用框架，所以只能本身摸索构建 React 服务端渲染方案：

• 为了实现先后端代码同构，须要对服务端代码进行 Webpack 打包配置
• 使用 script 标签以及全局变量的形式实现先后端 react-redux 数据 store 的统一（这个印象深入，当时思索了好久）

使用了服务端渲染方案后，能够去除以前的 Ejs 模板引擎，当时设计的大体结构以下：

当页面发送路由请求时，Express 服务端使用 react-router 匹配相应路由对应的 React 组件实例并调用 renderToString 方法进行服务端页面渲染（实现页面的局部刷新）。当页面渲染完成后，由 React 打包后的静态资源对页面进行 hydrate 处理。此时的 React 代码是同构的，所以须要注意哪些会运行在服务端，哪些会运行在客户端。同时服务端须要对同构代码进行Webpack 打包处理。

以上实现记录在示例 rewatch 中，入口文件是 server.js ，因为文件比较混乱（把客户端渲染和服务端渲染的示例放在了同一个文件项目中），这里给出另一个很是简单的示例 rewatch-server-render，项目目录结构以下：

.
├── public                      # 静态资源目录
│   └── js
│      ├── bundle.js            # react 目录打包文件
│      ├── common.js            # react 目录打包公共文件
│      ├── react-dom.min.js     # react 库文件
│      └── react.min.js			# react 库文件
├── react                       # react 同构代码目录(没有 react-router，能够查看 rewatch 示例)
│   ├── actions                 
│   ├── components        
│   ├── containers
│   ├── reducers
│   ├── store                
│   └── index.js
├── server                      # 服务端
│   └── routes                  # 服务端路由（没有使用 react-router 同构，能够查看 rewatch 示例）
├── server.js                   # 开发态服务入口文件
├── server.bundle.js            # 生产态服务入口文件
├── webpack.browser.config.js   # 静态资源打包的 webpack 配置(目标文件 bundle.js、common.js)
└── webpack.node.config.js      # 服务端打包的 webpack 配置(目标文件 server.bundle.js)

复制代码

Angular 技术方案选型

2016年10月到2017年3月，使用 Angular 设计了一个 Express 应用，大体的技术选型以下：

• Ejs
• Bootstrap
• Angular-Chart
• Mongoose
• Redis
• Sokect.io

这是一个简单的服务端多页应用示例，使用 Ejs 模板引擎进行页面渲染，渲染完成后交由 Anguar 进行页面的响应操做（发送请求使用 Angular 内置的 $http 服务）。该示例不须要额外的 Webpack 配置，只须要启动 Express 服务自己渲染设计便可。目录结构以下：

.
├── client                      # 静态资源目录
│   ├── css/                    # 样式
│   ├── imgs/                   # 图片
│   ├── js/                     # 脚本
│   │  ├── angular/             # angular应用
│   │  │  ├── controllers/   	# angular控制器
│   │  │  ├── services/	        # angular服务
│   │  │  └── webapp.js/		# angular自动引导应用程序
│   │  └── sockets/			  	# sockets应用
│   └── lib                     # 插件(包括angualr、bootstrap/bootstrap-table、chart等)
├── config                      # 配置（包括Redis、Mongoose配置）
│   ├── config.js               # 参数配置
│   └── index.config.js         # 导出配置
├── server                      # 服务端
│   ├── constants/              # 常量
│   ├── controllers/            # 控制器
│   ├── events/                 # 事件
│   ├── models/                 # 模型
│   ├── routes/                 # 路由
│   ├── sockets/                # socket.io
│   ├── pubs/                   # Redis发布
│   └── subs/                   # Redis订阅
├── views                       # 视图(使用Ejs模板引擎)
└── app.js                      # 服务入口文件
复制代码

舒适提示：这种多页应用框架是自然的 SSR 模型，通常都须要配合模板引擎进行设计。

Vue 技术方案选型

2018年6月，使用 Vue 设计了服务端渲染的 Express 应用，大体技术选型以下：

• Mongoose
• Nuxt
• Vue
• lokka
• Muse-UI
• 客户端和服务端同构代码的 Webpack 配置由 Nuxt 封装
• 服务端 Backpack 配置

该技术选型最主要的特色以下：

• 支持服务端渲染
• 支持 Graphql 查询语言
• 先后端统一 TypeScript 语法

选型详细说明

• 为了支持 Graphql 查询语言，服务端选择使用支持 Express 中间件扩展的 graphql-yoga。
• 客户端的 HTTP 请求须要符合 Graphql 请求格式，一种方式是使用 axios 等模拟 Graphql 的请求格式，另一种方式是选用支持Graphql 请求格式的请求库，这里选用 lokka 做为 Graphql 客户端的请求库。
• 为了快速设计页面，选用了基于 Vue 2.0 的 Material Design UI 组件库 Muse-UI。
• 选用了 Nuxt 做为服务端渲染的中间件（基于 Vue.js 的通用应用框架，预设了服务端渲染应用所须要的各类配置）。
• 为了支持客户端 TypeScript 语法，须要扩展 Nuxt 的默认 Webpack 配置，利用 Nuxt 的模块/注册自定义loaders配置 ts-loader，配合 nuxt-property-decorator 实现客户端 TypeScript 语法。

项目目录结构

在 Nuxt 的目录结构中，服务端引入的同构代码放在.nuxt 目录中，是 Webpack 打包后的代码文件，所以若是服务端不使用特殊的语法，彻底不须要 Backpack 配置。此项目为了支持服务端 TypeScript 语法，使用 Backpack 对服务端代码进行构建（不影响同构部分代码的构建，同构代码在 Nuxt 里是经过读取文件的方式获取）。

.
├── .nuxt                       # Nuxt构建目录（Nuxt预设目录）
├── assets                      # 资源目录（Nuxt预设目录）
│   ├── img               		# 图片
│   ├── icon               		# 图标
│   └── style         			# 样式
├── build                      	# 配置（包括Redis、Mongoose配置）
│   └── main.js                 # 服务端Backpack构建的目标启动入口文件
├── common                      # 先后端通用
│   ├── constants/              # 常量
│   └── types/                  # TypeScript接口
├── components                  # 组件目录（Nuxt预设目录）
├── constants                   # 前端常量目录
├── docs                        # 文档目录（渲染.md文件）
├── graphql                     # 前端Graphql请求接口
├── layouts              		# 布局目录（Nuxt预设目录）
├── middleware					# 中间件目录（Nuxt预设目录）
├── mixins					    # 全局mixins
├── modules					    # Nuxt模块（TypeScrpt的Webpack配置扩展）
├── pages					    # 页面目录（Nuxt预设目录）
├── plugins					    # 插件目录（Nuxt预设目录）
├── server					    # 服务端目录
│   ├── constants/              # 常量
│   ├── database/               # 数据库模型
│   ├── express/                # 服务对外的公共API接口
│   │   ├── controllers/   		# 控制器
│   │   ├── routes/   			# 路由
│   │   └── services/			# 服务
│   ├── graphql/                # 服务内部的Graphql查询接口
│   │   ├── middlewares/   		# Graphql中间件
│   │   ├── resolvers/   		# Graphql Resolver
│   │   ├── schemas/   			# Graphql Schema
│   │   └── index.ts			# graphql接口入口文件
│   ├── types/                  # TypeScript接口
│   ├── utils/                  # 工具方法
│   └── index.ts                # 服务端入口文件（Backpack构建入口地址）
├── static                      # 静态文件目录（Nuxt预设目录）
├── store                       # Vuex目录（Nuxt预设目录）
├── utils                       # 客户端工具方法
├── .cz-config.js               # cz提交配置文件
├── .env               			# 环境变量
├── .gitignore               	# Git忽视文件
├── .huskyrc               		# Git钩子配置文件
├── .vcmrc						# cz校验配置
├── app.html					# html文件
├── backpack.config.js			# Backpack配置文件
├── CHANGELOG.md				# 升级日志
├── ecosystem.config.js			# PM2启动配置文件
├── index.d.ts					# TypeScript声明文件
├── nuxt.config.js				# Nuxt配置文件
├── package.json				# 项目描述文件
├── README.md					# 说明
├── tag.bat						# 项目打Tag脚本
└── tsconfig_node.json          # TypeScript配置文件
复制代码

运行脚本设计

在package.json中的配置脚本以下：

"build": "cross-env NODE_ENV=production nuxt build && backpack build",
"pm2": "pm2 start ecosystem.config.js",
"pm2:stop": "pm2 stop ecosystem.config.js",
"dev:client": "cross-env NODE_ENV=development DEV_TYPE=nuxt ts-node --compiler ntypescript --project tsconfig_node.json ./server",
"dev:server": "cross-env NODE_ENV=development DEV_TYPE=server ts-node-dev --compiler ntypescript --project tsconfig_node.json ./server"
复制代码

• build：使用 Webpack 构建 Nuxt 资源包以及使用 Backpack 构建服务端入口文件（转义 TypeScript）
• pm2：以生产模式启动一个进程守护的 Web 服务器
• pm2:stop：中止运行 Web 服务器
• dev:client：启动开发态热部署前端渲染服务
• dev:server：启动开发态热启动服务端服务

虽然是服务端渲染框架（理论上能够一我的开发项目，启动一个热加载的服务端命令便可），可是在开发的过程当中考虑到多人协做以及开发的便利性仍然将客户端和服务端进行分离。

在服务端配置 Nuxt 的 Builder 会致使服务端热加载过慢，所以将服务端 Nuxt 的 Builder 过滤掉，使用 ts-node-dev 作服务端热启动。在客户端使用 ts-node 启动服务，经过识别 DEV_TYPE 环境变量加载Nuxt的 Builder，实现 Web 前端的热加载功能。须要注意客户端向服务端发送请求是跨域的，所以在服务端的开发态环境须要配置容许跨域。

舒适提示：一个服务端渲染框架楞是让我拆成了先后端开发分离的框架模式。

最后

设计了以上三个方案后，发现从零开始构建一个 Express 应用时至少须要考虑如下几个方面：

• 数据库( MongoDB / MySql 等)选型
• 是否须要模板引擎以及模板引擎( Ejs / Jade 等)选型
• 前端框架（ JQuery / Angular / React/ Vue 等）选型
• HTTP 请求库（axios / request / superagent 等）选型
• 是否须要 UI 组件库以及 UI 组件库选型
• 客户端是否须要 Webpack 构建
• 服务端是否须要 Webpack / Backpack 构建
• 其余（session、redis、socket.io 等）
• 性能、监控等

简单的起手式

• MongoDB
• Ejs 模板引擎
• JQuery
• JQuery 内置的$.ajax
• Bootstrap（可选）
• 客户端和服务端都不须要 Webpack 配置

对于 Express 新手而言，能够先尝试多页应用 + MongoDB + 模板引擎 + JQuery 的选型方案：

• 使用 Ejs 模板引擎须要额外了解 Ejs 语法，可是语法相对简单，学习成本低。
• 使用 JQuery 不须要考虑 HTTP 请求库选型，JQuery 内置了 HTTP 请求的 API。
• 若是对于页面布局以及样式设计不熟悉，能够考虑选用 Bootstrap 前端框架。
• 不须要深刻了解 ES6 / ES7 / JSX 等语法，所以不须要学习和使用 Webpack 配置。
• 使用 Ejs 模板引擎进行渲染的 Express 应用，是自然的服务端渲染应用。

主流框架的应用设计

• MongoDB
• 无需模板引擎
• React / Vue 等
• axios / request / superagent 等
• Ant Design / Ant Design Vue / Element / Muse-UI 等
• 客户端 Webpack 配置
• 服务端是否须要 Webpack / Backpack 配置依据状况而定

若是前端框架选型是 React 或 Vue（一般是单页应用设计），而且须要使用 ES6 / ES7 / JSX 以及 Vue 的 SFC 格式等语法，那么Web前端势必要设计 Webpack 的构建配置，此时可使用相似于 webpack-dev-server 的 Express 开发态渲染服务器设计和调试开发态前端页面。固然目前的 Web 前端开发针对不一样的前端框架都有本身设计的脚手架，所以能够直接使用脚手架进行开发设计和静态资源构建。同时若是框架中没有内置 HTTP 请求库，能够本身封装或者使用一些成熟的 HTTP 库，例如axios、request以及superagent等。若是须要使用 UI 组件库进行页面设计，能够根据使用的框架进行 UI 组件库选型，例如 React 的 Ant Design、Vue 的 Element 等。Express 服务端的设计因为使用了主流框架的动态渲染能力，所以能够去除模板引擎渲染功能。若是想支持 Node.js 不支持的 ES6 / ES7 / TypeScript 语法等，那么须要 Backpack 进行服务端构建。

舒适提示：主流框架的应用设计和简单的起手式不一样，先后端开发能够彻底分离，这样的应用设计大大解放了前端的生产力（前端再也不受限于服务端的模板引擎）。例如目前的主流框架设计的一些脚手架，能够优雅的将 Webpack 配置，开发态渲染服务器以及请求代理结合在一块儿，作到开箱即用，提高用户的开发体验。

招聘小广告（电线杆不孕不育系列）

Hi，你们好，咱们是阿里巴巴新成立的 BU 政务钉钉事业部（杭州同窗在用的健康码是我 BU 联合其余 BU 共同设计的一个项目），目前还有大量的 Web 前端职位空缺。但愿想找我内推或者想了解更多招聘信息的同窗能够加我微信：18768107826