用Nodejs 和 微服務 構建一個數據驅動應用平臺

我能夠想象這是每一個開發員的夢想，只用寫些純粹的邏輯，而後一鍵提交上線。不用關心用什麼框架，部署過程，配置等，僅僅關心你的業務邏輯，就像魔法同樣。

固然，我曾經也夢到過相似的。儘管我喜歡在docker裏搗鼓，檢出新穎的庫和框架（畢竟我主要是寫javascript），有時候遇到一個具體的問題我想快速構建解決方案。大多數這樣的問題自己對它是不敢興趣（或者比較困難）去解決。我須要花時間去解決它。

從這個項目，你將開始考慮腳手架，讓咱們看看如何建立一個新的項目?
爲了簡單起見，在這裏我將所有使用Nodejs，而且我將用最新穩定的Nodejs版本。

再說一次，爲了簡單起見咱們不會涉及到服務端渲染和一些新的東西。它只是個普通的REST API和一個獨立的webUI 而已。

REST API

咱們將從服務端和一個基本的REST API 開始 ，在你建立你的項目以前，讓咱們先回答一些問題？

• 用babel或es5足夠好嗎？或者typescript,flow ？ 用all-in-one的場景

• 或者很小的框架？ 若是我用all-in-one,我會選擇MAIN.js或者Meteor,仍是Nodal？

• Express,Hapi,Koa這些框架我會選擇哪個或者其餘的？ 我會用哪一種數據庫？Mongo,Redis,PostgreSQL？

• 須要認證嗎？我須要用一些庫嗎？Passport.js,仍是其它的？ 你必須回答這些很是基礎的問題。

假設你已經選好了。

1.咱們將用babel.js的es2015和第二階段特性,rest/spread和async/await，若是你不知道如何安裝babel,請看這裏的導讀，它給了至關好的說明和概述，固然，你也能夠用像generator-babel這麼簡單的。

2.咱們正在構建很是簡單的REST API，因此咱們不須要一個成熟的場景像Meteor和Express.js。若是你不知道怎麼安裝Express項目，能夠去看官方文檔，文檔很是好，但那些都不是咱們要作的。

3.從咱們構建REST API，咱們須要去處理POST,PUT,DELETE和其餘，爲了使這些簡單，你將須要插件body-parser和method-override和其餘的，好比logging,CORS,websockets，都是你須要的。

4.對於數據庫咱們使用MongoDB,而且咱們將用mongoose來操做mongoDB，若是你是最新的系統，安裝mongo不會很難，你的APP一樣適用於mongoose,這一部分很簡單（你須要的話你也能夠不定義schema）。

5.最後，咱們須要passport.js認證，幸運的是，這個很是簡單，更多的工做將在你的DB和schema去認證。
最後!咱們完成了一個REST API的項目，如今咱們須要些許多業務邏輯，咱們還須要web UI！

Web UI

讓咱們想象你已經花費了幾天時間去完成你的基礎REST API，很是好，充分的測試（你已經掌握了用單元測試），各類log而且都是這一切都是你想作的。如今是時候去構建一個你想要的webUI 了。

再說一遍，在你建立你的UI項目以前，咱們必須回答下面的問題。

• 以哪一種瀏覽器來適配？我須要支持IE8嗎？ 再說一遍，用babel和es5夠好嗎？或者其餘的type-script 或者 flow?

• 須要模塊打包嗎？WebPack,jspm,rollup?

• 什麼框架或庫適合UI？Angular?React?Polymer?Cycle.js? 若是沒有all-in-one

• 框架，我會選擇什麼樣的庫去設計應用？backbone?flux？Redux?sagas？Relay？RxJS?

• 須要css框架嗎？Bootstrap?Foundation?Material Design Lite?Semantic UI?

再說一遍，你必須回答這些基礎的問題。
假設你已經選好了。

1. 咱們有個客戶用的最新的瀏覽器，因此咱們只用兼容IE11或者最新的。至關酷，flexbox就支持。

2. 再說一遍，咱們將用babel。

3. 打包模塊，自從webpack提供了許多漂亮的（css modules）讓咱們不在花費更多的時間去作這些，若是你不知道怎麼去使用它，這裏有教程，能夠花些時間去熟悉這些。它最有價值的就是它各類加載器！

4. 選擇一個框架，若是你不太熟悉這塊，能夠看看decent overview。咱們將繼續使用React.js，由於我喜歡它。設置一個基礎的React app很是明確。你須要routing。若是你想開發更有效率，你能夠用hot reload。

5. 這一部分比較娛樂，底層庫與架構！若是你有時間的，我明確鼓勵你去嘗試一些新的，去學習不少東西。可是，爲了簡單咱們選擇經典，flux，很容易安裝，使用起來很是明確，還有許多很好的特性。

6. 對於css框架，咱們繼續使用BootStrap。每一個人都喜歡BootStrap，而且用在React中也挺好的。在項目添加一個a.css的文件。

咱們已經完成了在項目中建立咱們的web UI.如今咱們只用寫業務邏輯了。

我很容易理解爲何許多都不喜歡用javascript在生產環境中。有些人稱它爲javascript疲勞。對於開發者來講不停的學習是每一個人都應該作的，這的確是正確的，不幸的事，實際中不可能老是給你足夠的空間去適應屬於你本身的步調。每每你須要把任務在一週裏去分解，這個問題解決的方案是哪些？

極可能，一般最好的辦法是去學習一種用腳手架和bootstrap任務去推進開發進度。一般容許開發者專門深刻學習全部部分和工做速度相對較快。若是開發者熟悉CI/CD，他們能夠設置自動測試和自動部署。問題是，即便利用腳手架仍然須要花費不少時間去作。

另外一種方法，在過去幾年已經獲得了認同，Pass服務。雖然它們沒有消除決定去學習新的東西，一般來講它們對開發者來講比較容易，僅僅看看AWS的這些庫！更多的時間最終在老的系統，構建和開發。

我嘗試作了這些，而且它們運行挺好的，可是明顯的有不一樣的負面問題。從這裏，構建了另外一個平臺對於數據驅動應用demo,我開始考慮會有更好的方法嗎？更快速更容易的方式？是否能夠構建一個通用的平臺幫助咱們解決相似的案例？是否用這個構建一個APP不用花一天時間，只用幾小時就成？

核心點

這些想法咱們着手構建一個平臺,將使構建數據驅動的應用程序。若是你看過不少應用，你能夠很容易的把它們分爲3個部分：

1. 來源 ——這些是獲取或者生成中獲得的數據

2. 一個或多個處理器 ——影響數據發生改變產生的反應

3. 渲染——顯示你的內容

若是你懷疑你能夠看一些APP，這裏有幾個例子。

1. 用微博來分析情緒的產品

   從Twitter Firehose獲取數據，分析這些情緒，渲染一個經常使用表格展現總結情緒

2. slackbot
   從slack獲取數據，處理器是個函數，好比用google搜索，另一個處理將搜索的結果返回到slack，而後在控制檯渲染所有請求和響應。

3. 聊天APP
   從用戶獲取信息，處理器不須要作什麼，UI展現了輸入框和信息。

還有更多，你懂的。若是我不得不正式描述這個邏輯,它看起來就像這樣:

const processors = [processor1]; // or more, or none
// classical FP compose function
// see, e.g. http://ramdajs.com/0.19.1/docs/#compose
const app = compose(
  render,
  ...processors,
  source,
);

很酷的是這些就是所有的東西，source,processors和render,都是些普通的函數。這意味着咱們建立一個平臺容許咱們很容易的重複使用它們。只不過這些函數都是同步的，若是咱們想有些異步的操做呢？這裏提供了RxJS能夠解決，跟寫同步代碼是同樣，下面是用RxJS的邏輯代碼。

const app = Rx.Observable
  .create(source)
  .flatMap(processor)
  .subscribe(render);

我有種上當的感受，由於咱們不能使用徹底相同的函數在前面的代碼片斷上。Source函數必須利用Observer裏的create方法。而且Processor必須返回flatMap替換一個值。但添加了這些細微的改變就能夠容許咱們用異步函數，實在是很是漂亮。

我也對渲染函數施加了額外的約束,而不是返回HTML，它應該返回React組件，這樣很容易UI是一個總體，加上咱們能夠重用了 React組件不須要任何額外的hacks。

方法的好處

這些東西聽起來並無很複雜？在一方面來講，添加其餘的庫和抽象層老是增長了開發者學習成本。可是我認爲這裏的好處大於壞處，主要是由於咱們不在會考慮咱們前面所提到的問題了。讓咱們仔細看看這些好處。

我前兩個在上一節中已經提到過---對UI組件的處理器和易於集成的異步性。讓咱們開始使用異步性。

未完待續。。。。。。

原文：https://medium.com/@yamalight/building-a...小弟英語不行，翻譯的不當麻煩糾正下