第 30 天，聊一下開始玩 Nuxt 的緣由
(本來想寫整合 API 服務，發現內容前面沒提觀念太多，有點跳)

一開始嘗試處理 SEO

混著後端框架寫 Vue (搭配 Rails、Laravel)
為了專案進度和技術線單純，選用該框架 View 層提供的模版引擎
整個專案技術線是單純了，卻造成前端要維護的範圍變大，與後端負責區塊部分重疊

這種寫法很適合全端，但前端卻得雜食

為了讓後人能在短時間內，完全掌控畫面渲染相關區塊、維護時不需要動到原本後端。

先嘗試用 Webpack 自幹 SSR，發現功能不太好維護，拆完權限設定後幾乎是寫個輕量後端框架。

要打 view cached，工就大了、頭也大了

便開始研究其他 SSR 作法，從慣用框架 Vue.js 延伸到 Nuxt
(剛好 Nuxt Release 消息從 feedly 跳出來)

發現 Nuxt 開發上吻合 Vue.js SPA 寫法，學習門檻不高，權限驗證設定彈性、社群維護模組數量多。

最重要的，Nuxt 專案配置、風格有慣例可循，讓前端團隊逐漸統一開發習慣。

現在，依照專案分工決定前端如何開發，有幾個套路

1. 專案負責切版給後端套，選能用後端模板語言的切版工具 (像 Fire.app、Propes)
2. 專案前端框架採用 Vue.js，選 Nuxt
3. 舊專案維護盡量不改原後端框架 View 的區塊
4. 舊專案若是採用 Vue.js，新功能盡量包成 Vue Component，讓後端逐漸 API 化、拿掉舊頁面
5. 採用 Vue.js 的新站若需整合舊站，先考慮搬入 Nuxt

摸到最後，小跑變馬拉松
本來預估篇幅已經增加 40%，含正在研究的部分，還沒寫到

• Nuxt Store
• 解釋詳細架構
• serverMiddleware vs. (route)Middleware
  • serverMiddleware 掛常見後端框架 (Koa、Express)
  • serverMiddleware 應用情境
• Nuxt 文件沒寫的完整生命週期 (包含 Hooks)
• 解釋 Nuxt 不同運行模式下的程式碼打包
• 掛上 API 服務的幾種做法與架構圖解
  • @nuxtjs/proxy
  • Reverse Proxy (nginx / apache)
• Cache 實踐手法
• PWA
• 新舊站整合
• Vue.js SPA -> Nuxt.js

另外，還有人建議做 A/B Testing
搞死我呀？先吸個貓壓壓驚

若是讀者看完 30 天份，感謝你/妳的耐心閱讀

一個人可以走的很快，
但是一群人卻可以走的更遠。

路看起來還很長，我會繼續寫後續，希望多多提供想法和建議，歡迎回饋。