Nuxt.js 自版本3後，就開始內建了一個Nitro 伺服器引擎，我們只需加上一個server folder ，就可在裏面設定後端伺服器的邏輯，並與資料庫如MongoDB接連，很大程度取替了典型的後台框桇如Express.js或Nest.js等等，究其實，使用這個內建Nitro有以下好處：
1) 整合式開發體驗：Nuxt 實現了前端和後端功能的無縫整合。借助 Nitro，開發者可以直接在 Vue 元件旁邊編寫伺服器端邏輯，從而獲得更流暢的開發體驗。這種整合簡化了 API 的建立和伺服器端渲染 (SSR) 的處理流程，無需像 Express 那樣建立單獨的後端框架。
2) 伺服器端渲染 (SSR) 效率：Nitro 支援 SSR，無需向後端發送額外的 HTTP 請求、這意味著頁面渲染時可以直接呼叫伺服器函數，從而降低延遲並提升效能，這對於搜尋引擎優化 (SEO) 尤其有利，因為搜尋引擎可以更有效地索引完全渲染的頁面。
3) 基於檔案的路由：Nitro 採用基於檔案的路由系統，簡化了 API 端點的建立（這方面倒真費時費神），指定 API 目錄中的每個檔案都會自動對應一個特定的路由，從而更易於管理和擴展應用程式。
4) 自動設定：Nuxt 會自動配置 Vite 和 Nitro 等基本工具，讓開發人員能夠專注於建置功能，而不是設定環境，這減少了配置傳統 Express 設定所帶來的開銷。
當然，事物必有兩面，使用 Nuxt 和 Nitro 的缺點是可擴展性受到限制，雖然 Nitro 非常適合中小型項目，但在大型應用程式中可能會面臨挑戰。隨著專案規模的擴大，嚴格的基於檔案的路由方式可能會變得繁瑣，與 Express 更靈活的路由功能相比，它在管理大量路由方面效率較低。
再者，習慣於 Express 豐富的中間件和插件生態系統的開發者，可能會覺得 Nitro 的功能有些限制。雖然 Nitro 的設計目標是輕量高效，但它可能無法提供像 Express 那樣的客製化和可擴展性，尤其是在處理複雜的後端邏輯時。
儘管 Nuxt 簡化了開發的許多方面，但其底層架構的複雜性可能會為新開發者帶來一定的學習曲線，與更直接的 Express 框架相比，理解如何有效地將 Nitro 與 Vue 結合使用可能需要更多的時間和精力。不這，隨著人工智能的協助，這方面也愈發輕鬆。
我個人就曾以這方法建立了一個網誌網站，誠心說，相比過往使用Nuxt 2，Nuxt 3 和Nuxt 4真的稱心得多。
