基于 LeanCloud 云引擎的 Web 全栈方案： LeanEngine-Full-Stack

[LeanCloudRRY]

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

背景

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

简介

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

LeanEngine-Full-Stack 是基于 LeanEngine Nodejs 服务的 Web 全栈开发技术解决方案。整合当前 Web 技术中通用的技术方案，与 LeanEngine 紧密结合，将基础架构、自动化构建、国际化方案等底层技术问题的解决方案都已经组织在一起。用户可以通过最简单的方式，直接开始业务开发，不用再次纠结那些底层技术选型。

主要技术栈：

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

* Server 端运行环境基于 LeanEngine Nodejs 环境，依赖安装通过 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 和基础单元的处理方式

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

基本结构

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

整套技术方案有很多细节，具体的使用方式可以到 GitHub 仓库中直接查看使用说明及源码。

非常欢迎感兴趣的开发者一起讨论，当然限于自身能力不足，也有很多可以改进的地方，恳请各位高手积极贡献代码。如果你对 Web 全栈开发有需求，欢迎尝试看看。

其他问题

业内最新的技术以及解决方案 LeanCloud 也都有持续跟进，并且我们也积极同 Angular 、 React Native 等团队积极交流，目前构建 Web App 的框架选择主要会在 Angular1.x 、 Angular2.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 中使用。

为什么全部使用 ECMAScript 6 ？

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

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