全棧工程師之路-Node.js

時間 2019-11-07

原文原文鏈接

全棧工程師之路-Node.js

高可用架構專用javascript

原文[高可用架構]php

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&pass_ticket=xdp3crkTJPuOH6ggUMKnwvfDGKEnMUvwC5V%2FdxlW%2FKdNO9R8zI1xsDFSR4ZJECUUcss

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

持續更新版本前端

倉庫地址 https://github.com/i5ting/nodejs-fullstack
在線閱讀 http://i5ting.github.io/nodejs-fullstack/
keynote版本
pdf版本

已參加分享vue

高可用架構羣
3月26日北京NodeParty

若是想邀請分享，請郵寄給我shiren1118@126.com,若是時間ok，我會盡可能分享html5

主要內容

Why Node.js ？

歷史
槽點
架構平衡和選擇
企業級

我眼中的Node.js核心
快速開發實踐
全棧 or 全爛？

工具鏈
前端開發4階段
Hybrid開發
跨平臺
全棧的可能

將來

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

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

講師介紹

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

Part 1：爲何選用Node.js ？

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

之前？如今？

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

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

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 和解提案

Q2(2季度)

npm 支持私有模塊
Node 項目領導人 TJ Fontaine 逐步解除核心身份並離開 Joyent 公司
- A changing of the guard in Nodeland.
Node.js 和 io.js 在 Node 基金會下合併狀況

Q3(3季度)

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

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

版本帝？

去年

從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（核心）已經很是穩定了，能夠大規模使用

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

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

event-driven
non-blocking I/O

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

異步已經不是明顯優點了

除了性能，其餘都是病？

第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的強大的生態來炫耀

大事兒記

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

企業級

2014年 nearform NODE.JS爲何會成爲企業中的首選技術
2015年 IBM 收購 StrongLoop，拓展雲服務業務

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

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

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

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追逐的事實標準

微軟請求 Node.js 支持 ChakraCore

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

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

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

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

爲何咱們選擇Node.js ？

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

1）人（天津很差招人）

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

2）開發速度

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

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

3）穩定

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

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

1）即一樣不優化，性能比大部分語言好(天生被黑的優越感，沒辦法)
2）即便優化，也比其餘語言簡單，好比java
3）有足夠多的選擇和架構的平衡
4）如實在不夠，java補

黑一下go語言吧

go不着

沒有好的包管理
沒有好的調試工具
語法較難

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

選擇

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

1）可難可易

能夠採用面向過程
能夠面向對象
能夠函數式

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

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

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

測試相關 tdd/bdd/測試覆蓋率
規範化 standard、各類lint、hint
構建相關 gulp、grunt、webpack，大量插件
生成器 yo等
包管理工具npm足夠簡單易用

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

3）特定場景的快速

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

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

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

4）總結

能夠簡單，能夠難
能夠快、也能夠慢
能夠開發大型軟件

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

架構平衡

先說技術選型的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的支持。避免過多的時間用在早輪子上，影響開發進度

效率問題？

執行效率：

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

開發效率：

Node.js自己比較簡單，開發效率仍是比較高的
完善的生態，好比測試、工具、npm大量模塊

缺乏rails同樣的大殺器

scaffold腳手架
orm太弱

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

因此咱們須要作的

固化項目結構
限定orm
自定義腳手架

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

cli命令模塊，編寫很是容易
基於js的模板引擎（知名的30+）

咱們用Node.js作什麼？

api服務
前端（moa-frontend）
SDK（OAuth Provider）
輔助開發cli工具

目前進度

使用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化
- 模塊化
- 最小化
- 服務化

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

1）小而美的哲學
2）從LAMP到MEAN
3）異步流程控制
4）Node.js Web開發
5）Node.js 模塊開發

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

小而美的哲學

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

從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 講的就是咱們用的技術棧

異步流程控制

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

1. 回調函數Callbacks
1. 異步JavaScript
1. Promise/a+規範
1. 生成器Generators/ yield(es6)
1. Async/ await(es7)

目前全部版本都支持Promise/a+規範
目前Node.js 4.0 + 支持Generators/ yield
目前不支持ES7裏的Async/await，但能夠經過babel實現

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

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

Node.js Web開發

Node.js Web開發
- express、koa
- restify、hapi
- 其餘框架sails、meteor

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

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

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

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++水平了

Part 3：快速開發實踐

一、業務邊界優化

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

二、靜態api理論

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

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

三、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 開發總結

四、約定結構

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

五、使用npm模塊化

使用npmjs的private私有模塊（目前作法）
使用npm的本地模塊開發方法（測試和部署都很是快）
搭建npm私服（todo）

hz-api-cloud-admin
hz-api-cloud-order
hz-api-cloud-stock
hz-api-private
hz-api-private-admin
hz-dao-cloud
hz-dao-private
hz-dao-usercenter
hz-doc-api
hz-frontend
hz-mq 
hz-sms
hz-usercenter
xbm-sdk
hz-api-admin
hz-api-crm
hz-api-order
hz-api-statistics
hz-api-stock
hz-config
hz-dao
hz-doc

六、編寫生成器

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

moag order name:string password:string

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

七、Moajs框架和先後端分離

前端：moa-frontend
- public下面的採用nginx作反向代理
- 其餘的採用express+jade精簡代碼（ajax與後端交互）
後端：moa-api

1）moa生成器

即上面講的生成器scaffold

2）moa-frontend

技術棧

express
jade
bootstrap、bootstrap-table
jquery
gulp
nginx

3）moa-api

技術棧

Features

自動加載路由
支持mongodb配置
集成mongoosedao，快速寫crud等dao接口
自帶用戶管理
使用jsonwebtoken作用戶鑑權
支持migrate測試
支持mocha測試
默認集成res.api，便於寫接口
集成supervisor，代碼變更，自動重載
gulp自動監控文件變更，跑測試
gulp routes生成路由說明
使用log4js記錄日誌

4）總結

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

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

其餘

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

Part 4：全棧 or 全爛？

Node.js相關工具

grunt/gulp/fis/webpack
bower/spm/npm
tdd/bdd cucumber/mocha
standard
babel/typescript/coffee

前端開發4階段

html/css/js（基礎）
jQuery、jQuery-ui，Extjs（曾經流行）
Backbone（mvc），Angularjs、Vuejs（當前流行）
React組件化（將來趨勢）、Vuejs

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

Hybrid開發

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

將來的2點

js一統天下（nodejs作後端，傳統web和h5使用javasctipt，更智能的工具如gulp，更簡單的寫法如coffeescript等）
h5大行其道（網速變快，硬件內存增加）

跨平臺

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

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

2）移動端：加殼

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

3）PC端：繼續加殼

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

node-webkit is renamed NW.js
Electron - Build cross platform desktop apps with web technologies

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

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）當下流行玩法

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加殼打包

親，你看到將來了麼？

6）總結

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

如何全棧？

全棧核心

後端不會的ui（界面相關）
前端不會的db（業務相關）

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

1）從後端轉

作後端的人

對數據庫是比較熟悉，不管mongodb，仍是mysql、postgres
對前端理解比較弱，會基本的html，css，模板引擎等比較熟悉

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

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

html/css/js（基礎）
jQuery、jQuery-ui，Extjs（曾經流行）
Backbone，Angularjs（當前流行）、Vuejs
React（將來趨勢）、Vuejs

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周就已經很是熟練了，個人計劃是半年後，讓他們接觸【異步流程處理】和【數據庫】相關內容，學習後端代碼，就能夠全棧了

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）、一路走到如今的總結吧

Part 5：將來

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

謝謝你們

Q & A

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

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

像WebAssembly之類的就不太看好了

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

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

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

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

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

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

nodejs裏json-server 比較好

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

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

足夠輕量級，少選大框架，作好前端該有的優化
注意touch和click的區別，好比fastclick或zeptojs的tap手勢
Chrome profile（css3動畫）
使用weinre真機測試

個人h5實踐

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

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

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

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

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

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

1）你問的不是Node.js，而是Node.js要操做的數據庫。 2）耗性能的計算能夠在架構上平衡的

若是能夠延時，mq就能夠了
若是是非延時狀況，能夠採用其餘語言編寫對應服務，不必非要必定要Node.js 3）咱們目前的場景，尚未在計算遇到瓶頸

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

語義上更加清晰

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

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

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。

全棧工程師之路-Node.js

全棧工程師之路-Node.js

主要內容

講師介紹

Part 1：爲何選用Node.js ？

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

Q1(1季度)

Q2(2季度)

Q3(3季度)

Q4(4季度)

版本帝？

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

除了性能，其餘都是病？

大事兒記

企業級

es && babel

微軟請求 Node.js 支持 ChakraCore

爲何咱們選擇Node.js ？

黑一下go語言吧

選擇

1）可難可易

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

3）特定場景的快速

4）總結

架構平衡

效率問題？

咱們用Node.js作什麼？

目前進度

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

小而美的哲學

從LAMP到MEAN

異步流程控制

Node.js Web開發

Node.js 模塊開發

Part 3：快速開發實踐

一、業務邊界優化

二、靜態api理論

三、api約定

四、約定結構

五、使用npm模塊化

六、編寫生成器

七、Moajs框架和先後端分離

1）moa生成器

2）moa-frontend

3）moa-api

4）總結

其餘

Part 4：全棧 or 全爛 ？

Node.js相關工具

前端開發4階段

Hybrid開發

跨平臺

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

2）移動端：加殼

3）PC端：繼續加殼

4） 組件化：統一用法

5）當下流行玩法

6）總結

如何全棧？

1）從後端轉

2）從前端轉

3）從移動端轉

Part 5：將來

Q & A

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

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

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

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

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

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

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

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

Part 4：全棧 or 全爛？

4）組件化：統一用法

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