全棧工程師之路-Node.js

1. 全棧工程師之路-Node.js

高可用架構專用

原文[高可用架構]

https://mp.weixin.qq.com/s?_biz=MzAwMDU1MTE1OQ==&mid=405001493&idx=1&sn=f0ecab9b31bad83fb065ac37bb728245&scene=1&srcid=0324iTRH12WbXL5VDxXnEhH8&key=710a5d99946419d938a0ffc16a3c72118eefbe33f3f8312ed218bccbde126b60e818c8eb1068a9b07bdc8116a077b911&ascene=0&uin=NDIzMjM3MDk1&devicetype=iMac+MacBookPro11%2C1+OSX+OSX+10.10.5+build(14F27)&version=11000006&passticket=xdp3crkTJPuOH6ggUMKnwvfDGKEnMUvwC5V%2FdxlW%2FKdNO9R8zI1xsDFSR4ZJECUU

仔細的對比了一遍，感謝tim yang和慶豐校長的整理，很是嚴謹，比我講的要好，另外感謝霍老闆封我是StuQ明星講師[呲牙][呲牙]

1.1. 主要內容

1. Why Node.js ？

• 歷史

• 槽點

• 架構平衡和選擇

• 企業級

2. 我眼中的Node.js核心

3. 快速開發實踐

4. 全棧 or 全爛 ？

• 工具鏈

• 前端開發4階段

• Hybrid開發

• 跨平臺

• 全棧的可能

5. 將來

最近比較火的2016年開發者調查了，Node.js和全棧、以及和js相關的技術都有不錯的戰績，此次給你們分享一下《全棧工程師之路-Node.js》，準備的還不夠充分，水平也有限，你們見諒啊

http://stackoverflow.com/research/developer-survey-2016

1.2. 講師介紹

桑世龍，目前在天津創業，空弦科技 CTO，開源項目Moajs做者，StuQ明星講師 公司目前使用技術主要是Node.js， 技術棧算所謂的MEAN（mongodb + express + angular + node）； 曾在新浪，網秦等工做過； 算全棧程序員吧，帶過前端、後端、數據分析、移動端負責人、作過首席架構師、技術總監，目前主要從事技術架構 + 招人工做

2. Part 1：爲何選用Node.js ？

已經7歲的Node.js，你還熟悉麼？

之前？如今？

2.1. 回顧一下2015年Node.js的發展歷史

http://i5ting.github.io/history-of-node-js/

2.1.1. Q1(1季度)

• IO.js 1.0.0 發佈

• Joyent 推動創建 Node.js 基金會

• Joyent, IBM, Microsoft, PayPal, Fidelity, SAP and The Linux Foundation Join Forces to Support Node.js Community With Neutral and Open Governance

• IO.js 和 Node.js 和解提案

2.1.2. Q2(2季度)

• npm 支持私有模塊

• Node 項目領導人 TJ Fontaine 逐步解除核心身份並離開 Joyent 公司

• A changing of the guard in Nodeland.

• Node.js 和 io.js 在 Node 基金會下合併狀況

2.1.3. Q3(3季度)

• 4.0 版本發佈，即新的 1.0 版本

2.1.4. Q4(4季度)

• Node v4.2.0，首個長期支持版本（LTS）

• Apigee，RisingStack 和 Yahoo 加入 Node.js 基金會

• Node Interactive

• The first annual Node.js conference by the Node.js Foundation

2.2. 版本帝？

去年

• 從v0.10.35 開始

• 2015-01-14發佈了v1.0.0版本（io.js）

• 2.x（io.js）

• 3.x（io.js）

• 2015年09月Node.js基金會已發佈Node.js V4.0版 與io.js合併後的第一個版本

• 2015年10月Node.jsv4.2.0將是首個lts長期支持版本

• 年末發佈到4.2.4 && 5.4.0

目前（2016年3月20日）的2個版本

• v4.4.0 LTS（長期支持版本）

• v5.9.0 Stable（穩定版本）

總體來講趨於穩定

• 成立了nodejs基金會，可以讓nodejs在將來有更好的開源社區支持

• 發佈了LTS版本，意味着api穩定

• 快速發版本，不少人吐槽這個，其實換個角度看，這也是社區活躍的一個體現，但若是你們真的看CHANGELOG，其實都是小改進，並且是邊邊角角的改進，也就是說nodejs的core（核心）已經很是穩定了，能夠大規模使用

2.3. 之前咱們老是喜歡拿異步說事兒

Node.js與生俱來的2個特性

• event-driven

• non-blocking I/O

結果，今天。。。各類【異步】。。。爛大街了

異步已經不是明顯優點了

2.4. 除了性能，其餘都是病？

• 第1、callback hell問題，目前已經很好的解決了，promise/generator/async後面會講

• 第2、npm已是開源世界裏最大的包管理器了，模塊很是豐富（25.6萬+）

官方說

Node.js' package ecosystem, npm, is the largest ecosystem of open source libraries in the world.

之前咱們老是喜歡拿異步說事兒，如今咱們拿Node.js的強大的生態來炫耀

2.5. 大事兒記

下面介紹點Node.js的大事兒記

2.5.1. 企業級

• 2014年 nearform NODE.JS爲何會成爲企業中的首選技術

• 2015年 IBM 收購 StrongLoop，拓展雲服務業務

Node.js基金會的創始成員包括Joyent、IBM、Paypal、微軟、Fidelity和Linux基金會

更多參見 https://nodejs.org/en/foundation/members/

對於企業級開發，Node.js是足夠的，不管從性能、安全、穩定性等都是很是棒的。

空弦科技作的是基於雲倉儲的SaaS服務，給中小賣家提供服務，核心系統是進銷存+訂單池+WMS。目前來看不存在任何問題，稍後會講咱們爲啥選擇Node.js

2.5.2. es && babel

• 2015年 Ecma國際大會宣佈正式批准ECMA-262第6版，亦即ECMAScript 2015（曾用名：ECMAScript 六、ES6）的語言規範

http://babeljs.io/

babel做爲es編譯器，已經大量開始使用了，模塊作的很是棒，還有人用babel寫其餘語言編譯器

Node.js裏在0.12以後才增長es6特性，es7的目前還不支持。

因此在Node.js裏使用es裏比較高級的特性，是須要babel去編譯處理的。

這是node追逐的事實標準

2.5.3. 微軟請求 Node.js 支持 ChakraCore

• 2016年01月22日，微軟請求 Node.js 支持 ChakraCore

將來Node.js不僅是基於chrome v8引擎，它還能夠支持更多其餘js引擎，對生態、效率提高等很是有好處

蔡偉小兄弟的查克拉benchmark的對比

基本結論是 V8 ES5 >> 查克拉 ES6 > 查克拉 ES5 > V8 ES6

2.6. 爲何咱們選擇Node.js ？

先看一下咱們的瓶頸在哪裏 ？

• 1）人（天津很差招人）

Node.js招不到，好多都是從java轉的，前端也很差找，好多也是從java轉的，咱們至關於從0開始組建團隊

• 2）開發速度

創業公司，5分鐘要造火箭。。。你們都懂

因此讓開發快速進入狀態，提升開發速度，對咱們來講相當重要

• 3）穩定

在沒有專業運維人員的狀況下，如何保證系統可用、穩定

因而就引出了我認爲的Node.js的好處

• 1）即一樣不優化，性能比大部分語言好(天生被黑的優越感，沒辦法)

• 2）即便優化，也比其餘語言簡單，好比java

• 3）有足夠多的選擇和架構的平衡

• 4）如實在不夠，java補

2.7. 黑一下go語言吧

go不着

• 沒有好的包管理

• 沒有好的調試工具

• 語法較難

適合高端人羣，但對團隊開發是有門檻的，不適用大部分團隊

2.8. 選擇

Node.js給了咱們足夠的選擇空間

2.8.1. 1）可難可易

• 能夠採用面向過程

• 能夠面向對象

• 能夠函數式

甚至能夠用各類編譯器coffee、typescript、babel（es）等

對於從0開始的團隊來說，能夠先面向過程、而後隨着團隊的成熟度，一點一點增長難度

2.8.2. 2）提供好的基礎和包管理工具

• 測試相關 tdd/bdd/測試覆蓋率

• 規範化 standard、各類lint、hint

• 構建相關 gulp、grunt、webpack，大量插件

• 生成器 yo等

• 包管理工具npm足夠簡單易用

以上這些都作大型軟件的基礎，Node.js在這方面作得很是好

2.8.3. 3）特定場景的快速

不少人把mean組合（好比mean.io）起來，這樣作的好處是若是熟悉，開發速度確實會很是快，但肯定是難度太大，不多有人能搞的定

metetor模糊了服務端和客戶端，是同構的典型應用，對於實時場景是很是高效的。

這種東西都算特定場景的快速，通常不敢輕易上，調優難度很是大，若是有人能cover的住，在初期是很是高效的。

2.8.4. 4）總結

• 能夠簡單，能夠難

• 能夠快、也能夠慢

• 能夠開發大型軟件

還有一個問題就是若是以上不知足咋辦？這時就須要架構平衡了

2.9. 架構平衡

先說技術選型的3個思考點

• 在語言層面能夠作，那語言層面作

• 若是語言層面搞不定，那就架構層面作

• 若是架構層面也搞不定，這東西就不能用了

各自作各自合適的事兒就好，下面分別舉例看看

咱們很坦然的面對Node.js的優勢和缺點

• 1）語言層面能解決的

• 已有大量npm上的模塊(目前在25.6萬個以上)

• 本身造輪子(站在海量包上+簡單語法+npm=快速)

• 使用Node.js裏的nan本身包裝c/c++輪子

絕大部分需求均可以知足了

• 2）架構層面能解決的

• 業務邊界、模塊拆分、面向服務

• mq、rpc、cache

• 運維、監控、自動化

稍微解釋一下

• 首先，架構和是否是Node.js寫的不要緊，是獨立的

• 其次，架構師經常使用的東東有足夠的Node.js模塊支持，好比mq，像rabbitmq有比較好的node模塊支持，像rpc裏thrift、grpc、tchannel支持的都不錯，咱們使用的senecajs，好比redis，咱們使用的ioredis，後面作ha都是同樣的。

• 合適的場景用合適的東西

有不少東西是Node.js不擅長，又不在架構範疇裏的，咋辦？

3）如實在不夠，java補（嚴格點，應該叫其餘語言補） - 好比複雜excel生成 - 好比apns推送（go作其實也很好，不過除了我，沒人能維護。。。）

但凡是java或其餘語言裏比較成熟的庫，能夠做爲獨立服務使用的，均可以作Node.js的支持。避免過多的時間用在早輪子上，影響開發進度

2.10. 效率問題？

執行效率：

• 一樣不優化，性能比大部分語言好

開發效率：

• Node.js自己比較簡單，開發效率仍是比較高的

• 完善的生態，好比測試、工具、npm大量模塊

缺乏rails同樣的大殺器

• scaffold腳手架

• orm太弱

Node.js的web開發框架express、koa等，簡單，小巧，精緻，缺點是集成度不夠，目前已有的mean或yo或sails等總有某種方面的不滿意

因此咱們須要作的

• 固化項目結構

• 限定orm

• 自定義腳手架

恰恰Node.js提供了2點，可讓你30分鐘寫一個腳手架

• cli命令模塊，編寫很是容易

• 基於js的模板引擎（知名的30+）

2.11. 咱們用Node.js作什麼？

• api服務

• 前端（moa-frontend）

• SDK（OAuth Provider）

• 輔助開發cli工具

2.12. 目前進度

• 使用0.10.38，開發moajs框架

• express/mongodb

• pm2部署

• 阿里雲的slb負載

• alinode監控

• 先後端分離

• moa-api

• moa-frontend

• moa-h5(未能用)

• 上redis緩存

• 上rabbitmq

• 上senaca做爲rpc

• 上kong做爲api gateway（todo）

• 上consul作服務發現和配置（todo）

• 上elk做爲日誌分析處理（todo）

• 使用docker compose做爲本地開發環境（todo）

• 線上docker（todo）

技術棧更新

• nodejs 4.x（預計今年6月份）

• koa（generator/co）

• es6/es7(babel)

4.x在內存和性能上都有很是大的提高，新的語言特性上，異步流程和語法上都須要學習，故不急於升級，待人才梯隊完善

目前的作法是小步快走

• 一次只上同樣新技術

• 造成梯隊，便可準備上新東西

• 善用npm，實現3化

• 模塊化

• 最小化

• 服務化

3. Part 2：我眼中的Node.js核心

• 1）小而美的哲學

• 2）從LAMP到MEAN

• 3）異步流程控制

• 4）Node.js Web開發

• 5）Node.js 模塊開發

時間緣由，接下來稍微介紹一下MEAN

3.1. 小而美的哲學

"Small is beautiful"是Unix哲學9條裏的第一條，但對Node.js來講，它實在是再合適不過了

http://blog.izs.me/post/48281998870/unix-philosophy-and-nodejs

• Write modules that do one thing well. Write a new module rather than complicate an old one.

• Write modules that encourage composition rather than extension.

• Write modules that handle data Streams, because that is the universal interface.

• Write modules that are agnostic about the source of their input or the destination of their output.

• Write modules that solve a problem you know, so you can learn about the ones you don’t.

• Write modules that are small. Iterate quickly. Refactor ruthlessly. Rewrite bravely.

• Write modules quickly, to meet your needs, with just a few tests for compliance. Avoid extensive specifications. Add a test for each bug you fix.

• Write modules for publication, even if you only use them privately. You will appreciate documentation in the future.

3.2. 從LAMP到MEAN

MEAN是目前最潮的全棧javascript架構

MEAN是一個Javascript平臺的現代Web開發框架總稱，它是MongoDB + Express +AngularJS + NodeJS 四個框架的第一個字母組合。它與傳統LAMP同樣是一種全套開發工具的簡稱。

從個人角度看

• mysql用mongodb替換，nosql裏最像rdbms的，從開發和性能都是有優點的（老畢已經講過了）

• angular的出現是一個時代，ioc，雙向綁定，指令等都曾讓無數熱血沸騰

• nodejs提供了徹底的生態和工具鏈，你要的它基本都有，感謝npm，早些年nodejs的性能甩php幾條街的

• express做爲nodejs示範項目，它很是精簡，是比較合適的web框架

我爲何選擇MEAN架構？

• 成熟、穩定，簡單，有問題咱們能cover住，因此咱們選了nodejs

• 把握趨勢，之後nodejs的前景很是看好，尤爲前後端統一，全棧方向

• 在架構上能夠屏蔽可能風險，不背注一擲，也不會一葉障目，合理的使用其餘語言，只要每一個功能都以服務出現，至於它是什麼語言寫的，並不重要

• 招人成本的性價比相對較高，技術棧新，容易吸引人才

最重要的一件事兒，是當有問題的時候，有人能cover住，在創業初期這是最最重要的事兒。

個人一篇爆款文章《Node.js最新Web技術棧（2015年5月）》https://cnodejs.org/topic/55651bf07d4c64752effb4b1 講的就是咱們用的技術棧

3.3. 異步流程控制

js流程控制的演進過程，分如下5部分

• 1) 回調函數Callbacks

• 2) 異步JavaScript

• 3) Promise/a+規範

• 4) 生成器Generators/ yield(es6)

• 5) Async/ await(es7)

• 目前全部版本都支持Promise/a+規範

• 目前Node.js 4.0 + 支持Generators/ yield

• 目前不支持ES7裏的Async/await，但能夠經過babel實現

總體來講，對異步流程控制解決的仍是比較好的。

詳見Node.js最新技術棧之Promise篇

3.4. Node.js Web開發

• Node.js Web開發

• express、koa

• restify、hapi

• 其餘框架sails、meteor

各類類型web開發都支持的，通常咱們採用非restful的使用express、koa更簡單

若是是純restful，能夠採用restify、hapi

另外還有快速模擬api的json-server，對rest支持超方便

3.5. Node.js 模塊開發

• Node.js模塊開發

• 普通模塊

• cli

• 腳手架scaffold

• c/c++ addons

普通模塊和cli模塊只是差package.json裏的

  "preferGlobal": "true",  "bin": {    "kp": "kp.js"  },

腳手架scaffold = cli + 模板生成，在Node.js裏這2點都很是容易

在Node.js裏寫c/c++擴展，有nan抽象層，其餘就看你們的c/c++水平了

4. Part 3：快速開發實踐

4.1. 一、業務邊界優化

創業公司有不少可變性，要作的系統也無數，如何保證業務系統的邊界是很是難的，咱們其實走了不少彎路，圖-稍後補

4.2. 二、靜態api理論

當需求和ue定下來以後，就開始編寫靜態api，這樣app、h五、前端就可使用靜態api完成功能，然後端也能夠以靜態api爲標準來實現，總體效率仍是比較高的。

另外還有基於api生成http請求的思考（未完成）

4.3. 三、api約定

api的最佳實踐

• http://developer.github.com/v3/ （嚴格的restful）

• 微博API (可讀性強，相對比較傳統)

咱們採用的微博API相似的，約定結構也是相似的

res.api is an express middleware for render json api , it convention over api format like this :

{  data: {  },  status: {    code : x,    msg  : 'some message'  }}

詳見客戶端 API 開發總結

4.4. 四、約定結構

和java開發裏的目錄結構相似，該分層的分層，適當的按照express/koa增長中間件、路由等目錄，便於開發

4.5. 五、使用npm模塊化

• 使用npmjs的private私有模塊（目前作法）

• 使用npm的本地模塊開發方法（測試和部署都很是快）

• 搭建npm私服（todo）

hz-api-cloud-adminhz-api-cloud-orderhz-api-cloud-stockhz-api-privatehz-api-private-adminhz-dao-cloudhz-dao-privatehz-dao-usercenterhz-doc-apihz-frontendhz-mq hz-smshz-usercenterxbm-sdkhz-api-adminhz-api-crmhz-api-orderhz-api-statisticshz-api-stockhz-confighz-daohz-doc

4.6. 六、編寫生成器

在web開發裏，寫了moajs生成器，相似於rails

moag order name:string password:string

其餘開發，如iOS開發裏模型校驗很是煩,因而寫了一個json2objc命令行工具，讀取json，生成oc代碼，能夠節省很多時間

4.7. 七、Moajs框架和先後端分離

• 前端：moa-frontend

• public下面的採用nginx作反向代理

• 其餘的採用express+jade精簡代碼（ajax與後端交互）

• 後端：moa-api

4.7.1. 1）moa生成器

即上面講的生成器scaffold

4.7.2. 2）moa-frontend

技術棧

• express

• jade

• bootstrap、bootstrap-table

• jquery

• gulp

• nginx

4.7.3. 3）moa-api

技術棧

• base2(mirco kernel)

• mongoose

• bluebird

• res.api

Features

• 自動加載路由

• 支持mongodb配置

• 集成mongoosedao，快速寫crud等dao接口

• 自帶用戶管理

• 使用jsonwebtoken作用戶鑑權

• 支持migrate測試

• 支持mocha測試

• 默認集成res.api，便於寫接口

• 集成supervisor，代碼變更，自動重載

• gulp自動監控文件變更，跑測試

• gulp routes生成路由說明

• 使用log4js記錄日誌

4.7.4. 4）總結

從開發效果上看，仍是很是快的，很是穩定的

更多參見我寫的《Moajs框架演進之路》

4.8. 其餘

• 《從0開始寫Node.js框架》

5. Part 4：全棧 or 全爛 ？

5.1. Node.js相關工具

• grunt/gulp/fis/webpack

• bower/spm/npm

• tdd/bdd cucumber/mocha

• standard

• babel/typescript/coffee

5.2. 前端開發4階段

• html/css/js（基礎）

• jQuery、jQuery-ui，Extjs（曾經流行）

• Backbone（mvc），Angularjs、Vuejs（當前流行）

• React組件化（將來趨勢）、Vuejs

Vuejs綜合Angular和React的優勢，應該是下一個流行趨勢

5.3. Hybrid開發

Hybrid混搭開發是指使用html5技術開發的跨瀏覽器應用，並最終能夠將html5.js.css等打包成apk和ipa包的開發方式。它也能夠上傳到應用商店，提供給移動設備進行安裝。它最大的好處是經過h5開發一次，就能夠在多個平臺上安裝。

將來的2點

• js一統天下（nodejs作後端，傳統web和h5使用javasctipt，更智能的工具如gulp，更簡單的寫法如coffeescript等）

• h5大行其道（網速變快，硬件內存增加）

5.4. 跨平臺

5.4.1. 1）c/s架構到b/s架構

這個大部分都清楚，很少說

5.4.2. 2）移動端：加殼

在瀏覽器上作文章，把頁面生成各個移動端的app文件

5.4.3. 3）PC端：繼續加殼

同樣是延續瀏覽器作文章，不過此次把頁面生成各個PC平臺的可執行文件

• node-webkit is renamed NW.js

• Electron - Build cross platform desktop apps with web technologies

目前比較火的編輯器atom和vscode都是基於Electron打包的。

5.4.4. 4） 組件化：統一用法

React的出現影響最大的是jsx的出現，解決了長久以來組件化的問題，

• 咱們反覆的折騰js，依然沒法搞定

• 咱們嘗試OO，好比extjs

• 咱們最終仍是找個中間格式jsx

單純的React只是view層面的，還不足以應用，因而又有Redux

核心概念：Actions、Reducers 和 Store，簡單點說就是狀態控制

而後再結合打包加殼，變成app或可執行文件

• iOS、Android上用Cordova

• PC上使用Electron

總結

• 組件定義好（React）

• 控制好組件之間的狀態切換（Redux）

• 打包或加殼（Cordova or Electron）

這部分其實組件化了前端，那麼可否用這樣的思想來組件化移動端呢？

再看react-native

A framework for building native apps with React. http://facebook.github.io/react-native/

簡單點說，就是用React的語法來組件化iOS或Android SDK。

它們都在告訴咱們，大家之後就玩這些組件就行了，你不須要知道複雜的SDK是什麼

5.4.5. 5）當下流行玩法

Medis is a beautiful, easy-to-use Redis management application built on the modern web with Electron, React, and Redux. It's powered by many awesome Node.js modules, especially ioredis and ssh2.

技術點

• 使用Node.js模塊

• 使用Webpack構建

• 使用React（視圖） + Redux（控制邏輯）

• 使用Electron加殼打包

親，你看到將來了麼？

5.4.6. 6）總結

講了node工具，前端4階段，hybrid，各類跨平臺，目前就是爲了介紹Node全棧的各類可能，下面講一下如何能作到Node全棧？

5.5. 如何全棧？

全棧核心

• 後端不會的ui（界面相關）

• 前端不會的db（業務相關）

只要打通這2個要點，其餘就比較容易了

5.5.1. 1）從後端轉

作後端的人

• 對數據庫是比較熟悉，不管mongodb，仍是mysql、postgres

• 對前端理解比較弱，會基本的html，css，模板引擎等比較熟悉

4階段按部就班，build與工具齊飛

前端開發4階段，個人感受是按照順序，按部就班

• html/css/js（基礎）

• jQuery、jQuery-ui，Extjs（曾經流行）

• Backbone，Angularjs（當前流行）、Vuejs

• React（將來趨勢）、Vuejs

5.5.2. 2）從前端轉

從前端日後端轉，api接口很是容易學會，像express、koa這類框架大部分人一週就能學會，最難的是對db、er模型的理解，說直白點，仍是業務需求落地的理解

咱們來想一想通常的前端有什麼技能？

• html

• css（兼容瀏覽器）

• js會點（可能更多的是會點jquery）

• ps切圖

• firebug和chrome debuger會的人都不太多

• 用過幾個框架，大部分人是僅僅會用

• 英語通常

• svn/git會一點

那麼他們若是想在前端領域作的更深有哪些難點呢？

• 基礎：oo，dp，命令，shell，構建等

• 編程思想上的理解（mvc、ioc，規約等）

• 區分概念

• 外圍驗收，如h5和hybird等

• 追趕趨勢，如何學習新東西

以上皆是痛點。

因此比較好的辦法

• 玩轉npm、gulp這樣的前端工具類（此時仍是前端）

• 使用node作先後端分離（此時仍是前端）

• express、koa這類框架

• jade、ejs等模板引擎

• nginx

• 玩轉【後端】異步流程處理（promise/es6的(generator|yield)/es7(async|await)）

• 玩轉【後端】mongodb、mysql對應的node模塊

從咱們的經驗看，這樣是比較靠譜的。

https://github.com/moajs/moa-frontend

就是最簡單先後端分離，裏面沒有任何和db相關，

技術棧

• express

• jade

• bootstrap，bootstrap-table

• jquery

• gulp

• nginx

通常的前端都很是容易學會，基本2周就已經很是熟練了，個人計劃是半年後，讓他們接觸【異步流程處理】和【數據庫】相關內容，學習後端代碼，就能夠全棧了

5.5.3. 3）從移動端轉

移動端分

• native原生開發

• hybrid混搭式開發

原生開發就是iOS用oc/swift,Android用java或scala等，就算偶爾嵌入webview，能玩js的機會也很是好少

因此移動端轉全棧的方法，最好是從cordova（之前叫phonegap）開始作hybrid開發。

• 只要關注www目錄裏的h5便可，比較簡單

• 若是h5不足以完成的狀況下，能夠編寫cordova插件，即經過插件讓js調用原生sdk裏功能

• cordova的cli能夠經過npm安裝，學習npm的好方法

• 學習gulp構建工具

只要入了h5的坑，其實就很是好辦了。

• 而後h五、zeptojs、iscroll、fastclick等

• 而後微信經常使用的，如weui、vux（vue+weui）、jmui（react+weui）

• 而後能夠玩點框架，好比jquery mobile，sencha touch

• 而後能夠玩點高級貨，ionicframework（基於angularjs、cordova）

• 而後前端4階段，依次打怪升級

• 而後node

這個基本上是我走的路，從2010年寫iOS、作phonegap（當時是0.9.3）、一路走到如今的總結吧

6. Part 5：將來

多是一場春夢，也可能一個變革機遇，咱們更相信它是變革機遇，拭目以待吧

謝謝你們

• 前端資源教程

• JavaScript 資源大全中文版

7. Q & A

7.1. 問題一：在全棧的語言選擇上，除了node.js，是否還考慮過其餘語言？

有的，將來swift和lua是有可能的。swift的語法和性能上有很大優點，lua在openresty的推進下也有機會，不過沒有swift大

像WebAssembly之類的就不太看好了

7.2. 問題二：請教桑老師：剛纔你說的併發開發流程中靜態api指的是api文檔？

若是是的話誰負責編寫？大家目前已是一我的分模塊從前端寫到後端了嗎？

目前沒作到文檔即靜態api，因此目前是直接提供json和部分json-server

負責是後端開發的leader在寫，他的進度會比正常開發要早一週左右

目前不是一我的寫全部的先後端，團隊成立不久，天津Node.js會的很少，因此仍是先後端分離。可是經過moa-frontend可讓前端了解express等後端知識，適當的時候會給予機會，前端轉後端

7.3. 問題三：第一貴司在開發協做中提到了靜態api，請問是否是有什麼比較好的工具能夠推薦？

nodejs裏json-server 比較好

我其實很想圍繞靜態api，寫各類請求的生成器，只要api出來，文檔和各平臺的http請求代碼就生成出來，同時能夠對正式api進行壓測，惋惜目前還沒精力寫

7.4. 問題四：作hybrid app在移動端會遇到性能問題吧。。有沒有什麼優化經驗能夠分享？

• 足夠輕量級，少選大框架，作好前端該有的優化

• 注意touch和click的區別，好比fastclick或zeptojs的tap手勢

• Chrome profile（css3動畫）

• 使用weinre真機測試

個人h5實踐

7.5. 問題五：若是都全棧了，當前大家團隊是如何分工的？

咱們團隊仍是傾向於分工專業化，各個服務粒度很是小，便於輪崗、還有就是能夠爲之後像google那樣代碼開放作準備

可是有不少狀況下，是須要有機動的突擊隊的（尤爲是創業時期），這樣能夠隨便組合，另外就是全棧爲remote提供了更多便利性。

7.6. 問題六：h5在手機上用iscroll坑比較多啊 尤爲三星打開硬件加速的時候render頁面，桑老師怎麼看？

能夠嘗試一下淘寶系的h5虛擬化，鬼道曾經在as大會上講過的，咱們目前還沒能力作這麼深層次的優化

7.7. 問題七：Node.js作業務金額計算的金額性能和精度夠嗎

1）你問的不是Node.js，而是Node.js要操做的數據庫。 2）耗性能的計算能夠在架構上平衡的 - 若是能夠延時，mq就能夠了 - 若是是非延時狀況，能夠採用其餘語言編寫對應服務，不必非要必定要Node.js 3）咱們目前的場景，尚未在計算遇到瓶頸

7.8. 問題八：關於API返回格式那裏，對於status爲何不打平了把code和message放出來？這麼設定有什麼好處麼？

語義上更加清晰

整個返回的json就只有data和status，若是status.code!=0,我取msg就行了，若是等於0，處理data數據

這種設計不見得多好，不過結構清晰，對於開發者來講，是比較容易接受的