nodejs + react + redux 實踐

最近半個月，筆者負責了公司的一個內部項目的web層。 由於自我感覺這個項目搭建的很不錯，遂記錄下個人的一些心得以便日後回顧。

這個項目從前到後的整體架構是比較典型的網路架構模式。

# 負載均衡 nginx # web前端 node + react[SPA] # SOA層 java # 數據存儲 memcache + mysql

在整個的架構模式中，web層的權重由於nodejs的介入而顯著提高。

nodeJS控制路由、http狀態，銜接前端和java層。

而前端開發由於node的引入， 可以輕鬆mock數據、個性化java層的數據結構，因此開發也很省心省力。

最後，豐富的npm模塊及polyfill語法，大大簡化了我們的開發。

技術選型

經過團隊的討論與對產品業務需求定性後，我們採用了如下的web層技術方案。

前端

1. 前端 (MVVM) 框架: react
2. UI框架: ant-design
3. 數據層: redux + redux-form
4. 工具庫: underscore + babel-polyfill
5. 構建工具: webpack1 + gulp4

node

1. node (MVC) 框架: koa2
2. 本地IO層: fs-extra
3. 網路api層: axios + co-body
4. 轉發層: node-http-proxy
5. 路由層: koa-router
6. 日誌系統: winston
7. 工具庫: lodash babel-polifyll
8. 構建工具: babel-register

我們的技術選型考慮

做出這樣的技術選型，我的主要考慮點如下:

1. 使用框架來指導工程師的代碼編寫，可以使代碼質量和bug處理更加可控。

2. 採用ES6/7的代碼來編寫前後端代碼及async+await語法，避免了回調地獄，代碼十分簡潔。

3. 在工具庫上面，github上聲譽極高的lodash提供了足夠強大的函數庫。

4. 對於圖片上傳等大數據buffer場景，採用proxy的形式直接轉發request包。

5. 錯誤處理上面採用winston及Promise的catch形式來監控所有的異常。

架構模式評價

這樣的技術選型讓框架來驅動開發，對開發者來說足夠簡單和快捷。

由於業務場景不涉及到豐富的IO操作，重網路請求的場景下async+await提供了足夠好的異常及數據處理。

前端開發這塊，由於對SEO要求不高，因此SPA的模式的劣勢並不大。

採用ant-design和redux-form對於我們的工作量有著顯著減少的功效。

總結

由於這個node+前端項目，是筆者第一次從零到一實施完成的，

所以在項目架構上可能存在不少疏漏，讀者有好的建議希望能夠提給我~

本文首發於筆者的github blog