Vue.js与Node.js打造的所见即所得的SAAS引擎设计

写在前面的话

软件研发是个很苦的差事，虽然也颇有挑战，让人兴奋。可是，避开研发过程当中的大坑，从而享受挑战，避开“苦差事”，才是咱们的目的。若是想获得这个结果，每一个从业人员最好都能先了解下面的坑：

• 需求、需求、需求。。。。。
  重要的事情说三遍。咱们以前的资深经理（现任职百度）常说的一句话就是：“研发是不会形成项目失败的，只会形成Delay；但需求错误，就很容易形成项目失败”

• 有效沟通、有效沟通、有效沟通。。。。。
  沟通有多重要呢？1. 沟通少或有效沟通不够的项目，就算不失败，也基本不会成功。 2. 不会有效沟通的项目成员，将来，将会是团队的威胁，不如没有。

• 选择大于努力
  如今的技术发展，特别是开源的兴起，让研发从业人员被大量的优秀的技术框架/代码/产品所包围。也说是说，绝大多数你想写的并非核心业务的功能代码，都会有远比你写的优秀的开源代码存在，或是简单的多的技术解决方案存在。选对了用，远比你努力重要多了。

• 把“必定会变化”当成真理
  研发过程当中最让人感受讨厌的是什么？需求变了。这个状况估计每一个人都会碰到，并且都想尽可能避免出现需求变化的可能。但个人经验是：需求必定会由于什么缘由变化的，让你的代码或设计更容易适应变化，才是根本的解决之道。

• 想要质量可控，最好少写代码，只写必须写的代码，并且，容易懂的才是好代码
  从测试的角度来讲，每个未经验证的代码变化，都是质量的一个风险隐患。因此，少便是多。不过，适度才是最好的，这里只是提个醒。

作引擎的前因

咱们为何会作一个所见即所得的企业级服务产品的SAAS引擎呢？千万不要觉得咱们是由于喜欢啊、追求啊、信仰啊什么的。。。。真正的事实是：被逼的，竞争压力下，为了生存不得不作的。
ToB的经营管理产品虽然是被你们承认的ToC以后的另外一个增加点，但这个增加点之下，实际上是众多的竞争对手，狼多肉未必多的局面；同时，每一个政企事业单位的需求都不同，标准化产品让企业买帐的难度也很高。

定制化要求高，竞争激烈单价低，又很难标准化，这让不少作ToB的软件服务提供商日子很不容易过。

而咱们，更是人员较少、资质较差、资源也不足的人马中的一员。想要杀出一条生路，就只能：更快，更好，更便宜。

咱们要作一个什么样的引擎?

在这样一个状况下，咱们给引擎的需求作了以下的定义

• 足够灵活：
  业务流程可配置，相关页面可配置，术语可定制。最终要求是企业各类定制化的需求，均可以配置出来，而不是写代码写出来。

• 支持模版：
  完成一个企业后，能够经过模版进行经验保存。下一个相似的企业，能够在模版的基础上进行修改就可。

• 移动端支持：
  移动端能够在代码不改变的状况下将拖拽出来的流程和页面展示出来，一次配置，直接使用。

• 支持人工智能：
  咱们并不想说很虚的东西，从一开始咱们讨论引擎的时候，咱们就知道，将来人工智能将会很普及，极可能根本不是一个概念性的东西。因此，为了能生存的久一些，咱们也在设计中增长了人工智能的支持。

• 极简的链接第三方的能力
  一个引擎能拖拽出一些看着复杂的页面，就算真的有用估计也是一个”玩具“式的工具。如今的管理软件要想生存，可以支持便捷的与第三方数据互通是一个基本要求了。同时，对于咱们的引擎来讲，要求会更高一些，毕竟全部的页面和流程都是拖拽出来的，与第三方的链接，也要求 1. 能链接的类型多。2. 链接的方式容易。

技术方案选型

主要技术方案

• 后端：Sails.js, Node.js

• 前端：Vue.js, iView, jsPlumb

• 移动端：ionic

• 数据库：MongoDB, mysql

• 其它：Docker,Forever.js

为何都是JS语言框架？

• JS语言足够灵活，其可将字符串转化为对象的特性对咱们是很重要的一个功能。

• 同一语言能够大大下降开发难度，先后端能够统一使用一批工程师，人员成本，沟通成本都会大大下降。

• JS作服务器虽然有各类问题，但性能很好，稳定性也有必定的保证。对于企业内部管理软件是够用的。

为何是Vue.js?
选择Vue的时候，说实话，咱们并无由于它好用或者比较流行而选择它。由于如今有大量的前端成型的模版可使用，选择他们能够减少咱们的工做量。咱们选择Vue.js的缘由是：

• "NPM run dev":
  在Dev模式下，页面的更新能够直接体现到用户的浏览器中，这种”所见即所得“也正是咱们的引擎所须要的重点功能之一。

• 模块化
  Vue.js的模块化是一个很高内聚的模块化方案，基本上一个组件或模块全部的代码均可以写在一个vue文件中。这对于咱们经过页面拖拽作定制来讲，也是很是重要的一点。

为何是Sails.js?

• 简单
  只要链接上数据库后，若是想建立一个表，只须要增长一个model,重启一下服务器就能够了。省去了不少其它工做。并且，表的结构与不须要事先制定，这对咱们这种靠拖拽来生成数据的要求，很是适用。

• 支持大多数服务器须要的功能
  好比路由，安全，日志。。。并且ORM支持了大多数数据库，切换时只须要改个配置就能够。

选择Sails.js的最核心的缘由是由于ORM的强大，若是想增长一个数据集，只须要写入一个data.js在model文件夹下，重启一下就能够了。这给咱们自定义提交表单提供了极大的遍历。

为何是Docker

• 发布简单
  Docker能够将整个发布过程控制在远程就能够，没必要在运维人员从新调整对方服务器等等整个过程。

• 运维简单
  若是Docker出了问题，有一系列的方式可让Docker自动重启，保证服务一直运行。减小了运维阶段的人工成本。

jsPlumb?
选择jsPlumb没有太多特殊的缘由，目前在浏览器上能够显示相似Visio效果的开源图形插件并很少。虽然jsPlumb并不彻底符合咱们的要求，但对于初版引擎来讲，咱们选择它也是无奈之举。后期根据状况还会进行一系列优化，到到产品级的要求。

ionic?
选择ionic主要是基于如下几个缘由

• 入手简单，开发出的界面友好
  若是想写一个简单的app的话，ionic很相似于用angular写一个html5的页面同样容易。

• 有大量的cordova插件
  包括像文件管理，照片管理，数据库访问，微信共享，极光推送，友盟等等。。。一系列app必备的功能，都有现成稳定的插件可用，大大下降了开发成本。

• 重要界面可替换为原生
  ionic能够相对简单的将部分重要页面替换成原生，达到最高的性能。给将来产品进一步优化提供了可行型。对于想一直发展的产品来讲，这也是很重要的一点。

这样，ionic能够帮咱们：前期快速开发，后期有空间优化。

能链接什么样的第三方？

设计初衷

• 第三方提供了API的，能够连通。

• 可以访问第三方数据库的，能够连通。

• 第三方支持导入导出的，能够连通。

• 能够在web上访问第三方页面数据的，能够将数据接入咱们平台。

• 经过配置连通，不是经过代码链接。

这里面有一系列的技术，由于比较多，我计划在单写一篇博客来讲明吧。

不过，在这个方案设计的过程当中，咱们也有几个很好玩的发现，在这里分享一下

• 数据不是全必须有API才能交互：
  这是在咱们最初设计的时候碰到的一个困难，不少第三方系统都很可贵到API的，若是依赖API，将会让你的成本和周期大大增长。可若是扩展思路来考虑，获得数据的方式其实不少种：导入/导出能够，数据库能够，API能够，从页面直接抓取也能够。咱们就是将这几项全放在一块儿来考虑的。

• 数据不是最重要的，能进入业务流的数据才重要：
  咱们最开始设计咱们引擎的时候，引入了一个叫“术语”设计器的模块，其实没多复杂，就是让使用者能够根据本身的业务特色来定义本身企业内部的术语的表现方式。后期才发现，这个设计在与第三方数据交互的时候起了一个意想不到的做用：经过术语设计器，能够将第三方数据直接引用流程中去。这样，咱们就能够没必要要求第三方造成标准化联盟等等很是难以业务实现的要求。

因此，有时候技术对业务的推进，不仅是支持，有多是“变不可能为可能”

写在本文最后

时间的缘由，虽然还有不少没有写全，甚至包括写的部分也只是草草的完成，但也只能先节一段落了。不全的部分，会在后面的系列文章中逐渐加全。

固然，光有文章没有代码也很难说明问题，咱们团队也在计划将引擎在10月下旬开源出来，目前开源位置已经建立，若是你们有兴趣，也能够关注。
http://git.oschina.net/yanglf...