Next.js 自託管爭議:OpenNext 引發框架獨立性討論

BigGo Editorial Team
Next.js 自託管爭議:OpenNext 引發框架獨立性討論

開源專案 OpenNext 的出現在 AWS 和其他平臺上部署 Next.js 應用程式的介面卡,引發了關於 Next.js 框架獨立性和自託管能力的廣泛討論。雖然 Next.js 在開發者中越來越受歡迎,但社群對 Vercel 鎖定和部署靈活性的擔憂已經浮出水面。

OpenNext 的主要特性:

  • 支援 App 和 Pages 路由
  • API 路由支援
  • 動態路由
  • 靜態站點生成(SSG)
  • 伺服器端渲染(SSR)
  • 增量靜態再生成(ISR)
  • 中介軟體支援
  • 伺服器端操作
  • 圖片最佳化
  • NextAuth.js 整合
  • Edge 執行時支援

自託管的複雜性

儘管 Next.js 提供內建的自託管選項,但社群揭示了部署挑戰的複雜現狀。一些開發者在使用簡單的 Docker 容器化時取得了成功,但在 Vercel 生態系統之外嘗試實現邊緣計算和無伺服器架構等高階功能時,卻面臨重大障礙。OpenNext 旨在透過提供類似 Vercel 的無伺服器部署功能來彌合這一差距。

成本考慮

不同託管解決方案的成本影響已成為討論中的關鍵因素。一個社群經驗分享顯示,在 Vercel 上託管一個相對低流量的應用程式每月需要支付數百美元,其中影像最佳化是一個特別棘手的問題。在遷移到使用 SST 的 OpenNext 後,同一應用程式的計算和資產服務成本據報道降至每天約15美元,儘管這需要大量的工程努力。

我們在 Vercel 上最大的成本(每月數百美元)是影像最佳化,這是因為應用程式在處理影像時效率極低,部分原因是 Next.js 中一些不友好的預設行為,部分原因是疏忽大意。

框架演進和支援

Next.js 團隊已經認識到改進自託管能力的重要性。Next.js 的一位代表確認,他們正在與 OpenNext 維護者積極合作,以解決剩餘的部署問題並加強社群介面卡的維護。這種合作標誌著框架可移植性改進的積極一步,儘管一些開發者對 OpenNext 能否跟上 Next.js 更新表示擔憂。

使用 OpenNext 的知名組織:

  • Gymshark UK
  • Udacity
  • TUDN
  • NHS England

基礎設施考慮

雖然 OpenNext 提供了部署靈活性,但它也帶來了自己的一系列考慮因素。該專案似乎偏向某些基礎設施即程式碼(IaC)工具,特別是 SST,這導致一些開發者質疑其與現有基礎設施工具(如 AWS CDK)的整合。這凸顯了現代網路部署架構中平衡靈活性和標準化的持續挑戰。

圍繞 OpenNext 的討論反映了行業向框架獨立性和部署靈活性發展的更廣泛趨勢,同時也突顯了 Next.js 作為成熟的Web開發框架的持續演進。隨著組織越來越多地尋求對其部署基礎設施的控制,像 OpenNext 這樣的工具可能在連線框架功能和部署需求之間的差距方面發揮關鍵作用。

來源引用:OpenNext: Open-source Next.js adapter for AWS