基于 LeanCloud 云引擎的 Web 全栈方案

[说明]各位好！引用此文目的有几：一，为自己记忆备用；二，广泛结交同志朋友，如果有对此类方案有看法的伙伴，欢迎共同探讨。如今云存储方案风起云涌，可以比较成熟，且发展迅速，因此本人看法这种方案下的WEB开发方案。

很多工程师使用 LeanCloud 之后，发现一个人就可以 hold 住一个完整项目，尤其是一个 Web 项目。原因很简单，本来复杂繁琐的数据库操作，通过使用 LeanCloud 的 JavaScript SDK 变得轻而易举，再结合 LeanCloud 提供服务器端容器 —— 云引擎 LeanEngine（支持 Node.js 和 Python 两种环境），就可以很高效地开发出一个 Web 端项目。

背景

开始尝试 LeanCloud 时项目并不大，也不算复杂，大家都是很简单地去写代码，但是随着使用的深入，开发变得越来越顺手，有些工程师开始尝试设计复杂的项目。只要项目复杂了，就会有很多底层的事情需要考虑，比如协作分工、自动化流程、代码组织结构、框架选择、国际化方案等等。LeanCloud 的很多项目就是基于自身所提供的服务，在开发过程中我们遇到过很多问题，也为此纠结过，所以我们将目前使用的 Web 全栈方案整理成一个新的项目，作为一个 Generator 或者 Seed，供大家交流和使用。

简介

项目名为「LeanEngine-Full-Stack」，就放在 LeanCloud 官方的 GitHub 仓库中，地址为 55https://github.com/leancloud/LeanEngine-Full-Stack55。

LeanEngine-Full-Stack 是基于 LeanEngine Node.js 服务的 Web 全栈开发技术解决方案。它整合了当前 Web 技术的通用方案，并与 LeanEngine 紧密结合，将基础架构、自动化构建、国际化方案等底层技术解决方案组织成一个整体。用户可以通过最简单的方式，直接开始业务开发，不必再纠结那些底层的技术选型了。

主要技术栈：

• 
  

• 语言层面，整套方案 JavaScript 代码全部使用 ECMAScript 6。

• 
  

• Server 端运行环境基于 LeanEngine Node.js 环境，依赖安装通过 npm，服务框架主要基于 Express 4.x。

• 
  

• Web 前端自动化方案主要基于 Gulp，框架基于 Angular 1.4.x，UI 框架主要基于 Angular Material，构建依赖基于 npm，Web 前端依赖通过 bower 安装，样式通过编写 SASS 而非直接写 CSS 文件。

• 
  

整个脚手架 Server 端完全基于 LeanEngine，其底层已经将 API 路由的基础结构做好，并且将一些常规处理也整合在内，已选型的技术方案主要包括：

• 
  

• 服务端基本代码结构、组织结构

• 
  

• 基础的路由分层，默认在 /api/ 路由下

• 
  

• 对 API 的 HTML5 CORS 跨域协议的设置

• 
  

• 对访问域白名单控制，集成的可配置文件

• 
  

• 常规错误处理等

• 
  

Web 前端，从整体技术栈选择上可以看出，是一个稳健并且有一定前瞻性的技术方案。基于已经非常成熟的 Angular 架构体系，UI 设计层面基于 Google 积累多年而发布的设计语言 Material Design，所以前端 UI 框架基于 Angular Material 框架。Angular 1.4 在性能上有很大的提升，并完全面向现代浏览器，可以直接使用 ECMAScript 6 来开发。内部已经写好并整合的方案主要包括：

• 
  

• 代码基本组织结构，趋向于 HTML5 Web Compoment 的组织方式。

• 
  

• 底层配置，包括 HTML5 CORS 协议的底层支持、域名白名单等配置。

• 
  

• 纯前端路由方案，基于 HTML5 History API 和 ui-router 。

• 
  

• 自动构建系统，基础的代码压缩、合并、ECMAScript 和 SASS 编译等过程，也会将构建后的生成代码拷贝到 public 目录中，供发布使用。

• 
  

• SASS 的基本结构，以及一些 Mixin 和基础单元的处理方式。

• 
  

• 纯前端的国际化方案，可以实时切换语言资源。

• 
  

基本结构

<code>.
├── public          // LeanEngine Web 前端发布目录，HTMLCSSJavaScript 构建后将放置于此
├── server-modules  // 服务器端代码模块目录
│    ├── app.js            // LeanEngine 服务端代码主入口
│    ├── api-router.js     // API 接口路由配置
│    ├── tool.js           // 工具方法
│    └── hello.js          // 示例代码
├── web-project     // Web 前端项目目录
│    ├── gulp           // 自动化构建的逻辑模块
│    ├── dist           // 构建之后的源码目录
│    └── src            // 源码目录
└── server.js       // LeanEngine 的环境配置
</code>

LeanEngine-Full-Stack 目录结构

整套架构 Server 端与 Web 前端完全分离，在 Server 端编写 REST API，Web 项目则是完全的 Web App，而不是通过模板来耦合。web-project 目录包含了 Web 项目的全部代码，是完全独立的一套体系，也可以提取出去，作为单独项目维护。

整套技术方案有很多细节，具体的使用方式可以到 GitHub 仓库中直接查看使用说明及源码。我们知道该项目还有很多地方需要改进，所以我们非常欢迎感兴趣的开发者一起参与讨论，积极贡献代码。如果你对 Web 全栈开发有需求，欢迎来试用。

其他问题

前端框架为什么选择 Angular？

业内最新的技术以及解决方案 LeanCloud 也都有持续跟进，并且我们也积极同 Angular、React Native 等团队积极交流，目前构建 Web App 的框架选择主要会在 Angular 1.x、Angular 2.x、React 和 Ploymer 之间有所纠结，而我们最终选择了 Angular 1.4.x 版本。

主要解释下为什么没有选择 React：目前 React 应该是大家最感兴趣的框架，但是并不成熟。React 本身最创新的地方是解决了 View 层的分离，将渲染与编译过程分离，在 Web 端表现为将 JSX 变为 Virtual Dom，再将 Virtual Dom 每次 Diff 后的部分渲染为 HTML。而开发一个应用程序不仅仅需要这些，还需要一套完备的处理各种底层问题的方案，如我们在上面技术栈列出的那些方面。React 数据层 Flux 编程范式并不成熟，UI 层面组件稀缺，即便是前端路由方案也是颇有争议，黑科技不断。

所以，在这种情况下，为了能做出一个长期可维护的产品，我们暂时不选择 React 来做 Web App。当然，LeanCloud 会持续跟进 React Team 的最新动态。另外，推荐一下 React Native，虽然 React 构建 Web App 优势并不明显，但是 React Native 则大大提高了 Native App 的开发体验，其优势远大于目前的劣势，所以欢迎大家尝试一下。LeanCloud 的 JavaScript SDK 也 支持 React Native 中使用8。

为什么全部使用 ECMAScript 6？

一门编程语言会影响一个人的编程思路，ECMAScript 对 JavaScript 这门用了七天设计出来的语言做了很多优化和革新，比如箭头函数、语言层面的模块化、原生的 Promise 等，这些都是让人眼前一亮的特性，其他大大小小的改进也很多。而且在 2015 年 ECMAScript 6 已经定稿，所有浏览器最终都一定会支持这个版本的 JavaScript，那么我们有什么理由不开始尝试呢？而且通过很多的前端构建，可以让我们不用去过多考虑浏览器的兼容性，所以我们选择全部使用 ECMAScript 6。

服务端通过在 LeanEngine 中运行 node --harmony 来实现对 ECMAScript 6 的支持（因为目前 Node.js 4.x 刚刚发布，等我们的 LeanEngine 完全对其支持了，harmony 参数就可以去掉了）。前端通过直接写 ECMAScript 6 的方式来编码，而没有选择如 TypeScript 之类的 ECMAScript 6 超集，这是因为我们还是希望能够编写更纯粹的 JavaScript，前端会通过 babel 自动化编译处理。总体来看，这也算是稳健且有前瞻的选择。

引用地址：https://forum.leancloud.cn/t/leancloud-web/4220