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...