第十期 AMA，掘金團隊請來了阿里 Node 基礎框架 EggJS 的核心開發者 — 天豬 做了為期三天的 Ask Me Anything (AMA) 活動（已結束）。
我們在此精選了一些來自使用者的提問及天豬的回答。
關於天豬
- 個人 GitHub：github.com/atian25
- 個人知乎：www.zhihu.com/people/liuy…
- 個人掘金主頁：juejin.im/user/577753…
- 個人微博：weibo.com/liuyong25?i…
社群小夥伴精選提問
Egg 的最大的亮點是什麼？ ─ @Lanwy
圍觀大佬，可以說下你覺得 Egg 的最大的亮點是什麼嗎？?只能說一點
最大的亮點是定位吧，Egg 的定位是框架的框架，在 Koa 的基礎上提供了一套載入規範，從而延伸出外掛和上層框架的概念，達到生態共建和差異化定製的平衡點，助力不同團隊的架構師孵化出適合自身業務場景的上層框架。
過多約束是否阻礙 egg 的大規模推廣─ @託尼的夏天
egg 相比其他 node 框架，約束太多了，這是否阻礙了它的大規模推廣
首先，Egg 是很輕量的，它的約束其實很少，就寥寥幾個擴充套件點，比起 sails loopback 等上層框架可謂極簡了，它專注於提供這些上層框架的最核心的共性 – 一套載入器。你覺得太多，可能是我們官網文件的問題，很多都是外掛提供的，並沒有整合。
其次，Egg 並不太需要推廣，它最初是為了支撐阿里內部各大 BU 之間的協作問題，涉及到各行各業，譬如電商，自媒體，遊戲，金融等等千差萬別的業務場景，因此我們的定位是專注於做框架的框架。如下圖所示
另外，我們這幾個人一直都受益於開源，因此一開始的目標就確定要開源出來。至於推廣，老實說，不是我們的 KPI。
hapi 和 egg 的差異在哪？ ─ @chenchao
都是配置優先，請問，hapi和egg的差異在哪？在企業開發中，如何抉擇？兩者有沒有哪些對比express凸顯出來的劣勢？
hapi 並沒有配置優先吧，它跟 Express，Koa 是差不多層次的，都在微框架這一層。Egg 是在它們之上加了一層 Loader 機制。一般我們基於 Express 或 Koa 開發的時候，團隊裡面往往都會在上面封裝一層業務框架，Egg 的定位就是抽象出這一層的一些通用能力，讓大家基於同一套基礎規則來封裝上層業務框架，達成生態共享的狀態。
Express 的侷限性，剛好最近我的一本書中有總結了下，主要在於：
- 只是對 Node 的 HTTP API 做了一層很薄的封裝，暴露給開發者的 API 抽象程度不夠，不便管控。
- 中介軟體模型是線性的，管進不管出，只是處理了 req 進來那條鏈路，而沒有管 res 出去那條。
- 基於 Callback 的中介軟體模型，不可避免的受到回撥地獄的影響。
egg的擴充套件中help.js和app.js哪個更適合擴充套件工具方法？ ─ @magican
egg 的擴充套件中 help.js 和 app.js 哪個更適合擴充套件工具方法？就約定來說適合 help，但是 help 是繫結到上下文的，就記憶體佔用是不是 app 更好？
記憶體這個不要去過多考慮，基本上按大家的業務量級，不會有什麼問題的。在我們的定位裡面，helper 是給到模板來做區域性的 formatter 的。擴充套件方法，看你具體的場景，甚至可以放到
ctx.service.xxUtils上
國內用node做後端的情況還多嗎？職業發展要怎麼規劃？─ @gea
天豬大佬，現在國內用 node 做後端的情況還多嗎？職業發展要怎麼規劃？ 因為我是一個兩年多工作經驗 noder，開始工作的時候是做前端，我自己轉型做後端，現在做了接近兩年的純 node 後端工作，最近感覺大多數企業把 node 的場景都開始向前偏移了，我個人覺得 node 用來做後端是足夠的，效能方面也不是那麼大的硬傷，可以通過 k8s 等一系列的架構和方式去消除減弱效能的缺點，但是 node 後端越來越少，要轉向前端還是轉向其它語言呢？
微服務化其實給 Node 帶來的是利好，提供服務即可，不關注後面的語言。目前國內用 Node 的團隊，我覺得是兩極分化：
- 阿里這樣的大公司，有完善的基建和中介軟體支撐，因此可以大放異彩。
- 創業小公司，追求速度和效率，所以也能放手實踐。
- 反而是中間的中小公司，包括一些大公司裡面的團隊，受限於運維基建和話語權，推起來比較痛苦。
效能其實各大語言發展到今天，對於絕大部分業務場景來說，輪不到拼這個天賦的時候。選擇一個技術，更多的是看團隊的技術棧 + 運維基建 + 中介軟體服務支撐程度 + 話語權。
就 Node 發展的話，建議還是進阿里體驗一下，在國內阿里的 Node 和其他公司，是完全兩個不同的階段。或者至少了解下阿里 Node 在這個過程中的實踐，踩坑經驗，未來方向，從而有的放矢。
點評下nest，說說您或者egg團隊對他的看法？─ @鯨吃瓜
請問天豬大哥能否簡單的點評下nest，說說您或者egg團隊對他的看法，以及他的優缺點?
nest 是近年來新出的一個框架，比較亮眼的是 TypeScript 和從 Spring 過來的一些概念。
從我們的角度來看，企業級應用有很多要素，包括程式設計模型約束、擴充套件點、多程式管理、日誌、安全、RPC 等等非常多的方面，TypeScript 靜態型別帶來的好處，是其中的一小點，但並不是全部。裝飾器等特性，目前還在 Stage 階段，並沒有落地到 Node LTS 版本中。在我們看來，靜態型別帶來的好處，還不如把單元測試覆蓋率做上去更實際。
TypeScript 也並不是某個框架獨有的，就像螞蟻鳳蝶團隊就有在用 TS 開發 Egg 應用（聽說他們做了個 tegg 框架，後面也許會放出來）。
順便重提下框架對比，從我們的角度看來，框架有三層：
- 基礎框架：Express，Koa
- 框架的框架：Egg
- 上層業務框架：tegg，chair，sofa-node，ThinkJS，Sails，Loopback，Nest
它們的定位：
- 微框架專注於底層中介軟體模型，是 Node HTTP 之上很薄的一層。
- 上層業務框架，是針對某個領域和業務場景定製的業務框架，針對團隊自身的業務場景和技術選型下的組合。（當然也有一些大教堂式的大而全框架）
- 上層業務框架一般每個團隊都會封裝一個，就像當年阿里各大 BU 那樣，而 Egg 就定位介於前面兩者之間，抽象出上層框架的一些共性 — 一套載入規範，一方面提供外掛能力來複用，一方面提供框架定製能力供團隊架構師定製自己的上層業務框架。
Node 新人如何成長？─ @L丶q
一直混跡於創業公司，致力於各種業務以及解決問題，有時候特別基礎的知識都要去查一下才能確定，個人技能也是層次不齊，感覺迷茫了怎麼辦
關鍵還是總結，遇到問題後，多思考，遇到了什麼問題，解決了什麼問題？同類場景是如何解決這個問題的？他們之間的對比是怎麼樣的？誰優誰劣？如果他們的方案各自優點結合起來，又會怎麼樣？
或者這麼說，未來你參與面試的時候，面試官希望聽到你說 「我用過 xx 框架」，還是希望聽到你說：「我在做 XX 專案的時候，預研過 XX 和 YY 框架，最終因為 XX 等原因，我選擇了 XX 框架。在這過程中，我遇到了 XX 問題，為此我去看了 XX 原始碼，發現他們是基於 XX 原理的，還有優化的空間，於是自己嘗試了 XX，解決後寫了 XX 總結文章，甚至嘗試給 XX 框架提了一個 PR 解決了這個問題」 — 這句話好像是小芋頭說的。
對話：天豬 & 楊雪晉 & 字字珠璣關於開源、egg.js 社群的看法
楊雪晉：我在公司的技術選型中 Node 一塊使用了 Egg，兩期下來發現開發沒問題但體驗很一般。錯誤提示很不明確，官方文件華而不實，三方模組濫竽充數，框架約束邯鄲學步。錯誤提示方面您可以說是 Nodejs 非同步原因不好定位錯誤，官方文件只是好看但業務開發中我們發現很多地方文件沒有詳細說明，第三方模組諸如 egg-jwt 典型的 npm copy 過來改改充數的也能被官方推薦使用，egg 的框架約束對比一下 Laravel，目錄和模組名作為類，大寫後，路由卻必須小寫！而且關於模組的引入 ES6 提供了兩三種方法，官方文件和你們開發的 cnode 社群原始碼上用的是程式碼重複量多的那種，關於 Controller 層有個 egg-validate 外掛的使用也可以獨立出來檔案中，也可以放建構函式中，這些官方文件都沒有說明，自定義引數檢驗和定時器這些更不那麼重要但是簡單的確說明過度了。
天豬 ：
感謝反饋，社群這塊確實有挺大的進步空間。你指的濫竽充數是 awsome-egg 那個吧？那個目前只要是提 PR 就能合併的，目前只作為一個索引，我們並沒有精力去逐個分析原始碼和評價方案，這塊如果社群有同學有興趣，可以考慮參與進來接管。
jwt 那個是社群外掛，不是官方維護的。 validate 那個不是內建外掛，所以沒有寫入文件。cnode 那個其實也不是官方重寫的，是樸老師之前召集社群重構的，第一期只專注於遷移，並沒有優化。
楊雪晉：多謝解釋了，抱歉我的態度可能稍微激動了點，實在希望 Node 社群也能有相對完美的 web 框架和生態系統。
天豬 ：
沒事的，我們每個人在社群都是有多重角色的。就像蘇千他們也是 Koa 的核心開發者，而 Koa 本身也已經完成了自己的核心目標了。然後上一層的封裝，他們是作為 Egg 的核心開發，輸出到 Egg 裡面的。同樣，更上層的業務框架輸出，我們是以另一個角色，在其他專案裡面輸出的，可以關注下螞蟻最近開源的 sofa-node 。
也可以看看我們這篇專欄《InfoQ 專訪死馬：為什麼說Egg.js是企業級Node框架》zhuanlan.zhihu.com/p/36240171
楊雪晉：請你們在公司專案中使用下 egg，碰到問題在 github 提交 issue。確實官方回覆很快，基本上是天豬回覆的多，而且是回覆後即便沒解決問題也立刻關閉 issue，即使如此 egg 專案的 issue 依舊存在很多問題為明顯的不足之處，我感覺不到官方團隊有對 egg 技術創新上做追求
天豬 ：
- 如果沒有解決可以重新 open 的，這是社群，不要有負擔。
- 老實說，egg 本身的職責基本上已經完成了，它就是一個載入規範，核心已經很穩定了。
- 剩下的，我們其實跟你們沒啥區別，都是社群的一分子的身份，去完善生態。
- 而日常開發中我們沒用到的模組和實踐，我們真的沒能力也沒辦法花時間去專門研究，畢竟我們只是一個虛擬團隊，我們主要是為了支援各自部門的 Node 演進。
- 阿里的很多後端和運維基建和社群不一樣，(當然我們在儘量擁抱)，故開源的外掛都是我們在內部實踐成熟後，才有可能作為社群的角色分享出來。
字字珠璣：請問下大佬們這麼擁抱社群有基於KPI考核的部分在驅動嗎?然後有新的專案直接上node的嗎?還是就是用node替換原來成熟的體系?
天豬 ：
- 擁抱社群一直都是阿里的傳統，我們有阿里開源小組。
- 我們自己本身就很受益於開源社群，回饋是理所當然的。甚至我們很多人都是從社群招募進來的。
- 開源其實有好處的，就好像我們現在招人，很多已經具備 egg，ant design 的能力，有效的降低了人員招聘篩選和培養成本。
- 開源從來都不可能是 KPI。我們的 KPI 之一是各自團隊的工程基建，只是為了更好的完成這一目標，我們會考慮協作和建立生態，然後順便分享出去。
- Egg 也從來不是一個實體團隊，我們都是分佈在不同部門不同城市的，不可能有一樣的 KPI。
『替換體系』這事情真的很難，不是說說就可以的，涉及到生態，運維基建，中介軟體 SDK ，監控，應用治理等等非常多的領域。Node 的目標從來就不是替代 Java，它們的定位是不一樣的，是互補的。阿里的 Node.js 也是蘇千樸靈等前輩們足足經歷了 8 年的開荒，才衝出一條血路，有了今日的開花結果。
皮一下很開心的問題
請問你為什麼叫天豬…？ ─ @諾墨
請問你為什麼叫天豬……
大學時暱稱是阿天，我們那個時代流行加個豬字尾作為暱稱，因此。。。
天豬和飛豬有啥關係？ ─ @bearever
天豬和飛豬有啥關係?
他們給我發過一枚飛豬天使使用者勳章。
本期 AMA 社群小夥伴提了許多實用問題，感謝天豬認真地為掘金小夥伴解答了不少疑問。瀏覽更多的問答，可以到天豬的 AMA 進行閱讀和討論。
本週 AMA：《開發者必備的 Docker實踐指南》小冊作者–有明
本週 AMA 正在進行 時間：2018.11.13 - 2018.11.15，活動傳送：?戳這裡
本週 AMA 嘉賓為《沒什麼難的 Docker》書籍、《開發者必備的 Docker實踐指南》小冊作者–有明，大家有任何關於 Docker 、虛擬化、容器技術、個人成長、團隊管理問題都可以找他交流技術~