沒穿方服

使用 cloudflare/next-on-pages 的專案 feeders，上線快 5 個月了。

功能需求不複雜，所以想找低價、好開發、又能達到足夠品質的方案。但實際做下去，開發的不便還是有感，也在網站乏人問津的狀況下就超出了免費額度。

首先談 Next.js 14 App router

我算第一次用，小小意外：

• 點連結後有一段無反應的時間

  在 server 初始回應之前，瀏覽器是全無反應的，也就是比點擊原生 <a> 回饋更差，這個我很難接受。

  參考 Next.js App Router navigation indicator and the delay after onclick - DEV Community。

  文章有一些對策，我後來乾脆裝一個進度條元件，它今年轉生成新專案 BProgress。 這種 UI 本是多此一舉，現在為了遮醜不得不用。

• 使用 hash 的客戶端導覽 (client side navigation) 沒有處理

  一樣是基於 server 為重的設計，Next.js 對於使用 URL hash（#xxx 部分）做的導覽沒有理會。它不是一個 route，處理上一頁、下一頁時也會漏掉而出問題。框架和原生功能打架。

  類似這個 issue 說的情形：#56112: Server rendered routes with hashes do not work with browser back/forward navigation。

  解法是自己監測 hashchange 做反應；另外也要監測 popstate 事件（會發生於上一頁、下一頁），自己比對 URL pathname，需要時補做 router navigation，見 commit bootleq/feeders@c211ff7。

然後是 next-on-pages

• Runtime 與 API、產品線（D1、R2 等）的先天限制

  next-on-pages 只能用 edge runtime，一些 API 也跟 Next.js 的規格不太一樣。

  實際障礙例如不能做 ISR、考慮 cache 時要重新認識當時的 cache API（現在看，又不同了）。

  再說到 D1 等 edge 特化的產品（註：沒有強迫一定要用），有些限制像是不支援 transaction 如果在遇到時才發現，恐怕真的無解。

  註：後來出現了 OpenNext 可以在 worker 使用 node.js runtime。

• worker 限額

  壓縮後超過 1MB 就會超出免費額度（worker 部分，靜態檔不算），我一開始沒注意到，後來要減肥就來不及了（我真的努力過）。
  後來有人提報 1MB 連 starter 專案都不夠用，就在 11 月放寬到 3MB 了。

  CPU time 免費額度只有 10ms，付費則有 30s 也差太多了吧。
  看一些討論是只要有密碼學運算、解析 DOM、載入較大的資料，隨便就會超過 10ms。 我的 app 有做身分認證和載入大顆 JSON，峰值遠遠超過 10ms，或許努力調校可以壓下去，但要長期活在這條線下實在削足適履。

• git push 部署和 wrangler 上傳只能二選一

  假如想先用 wrangler pages deploy 指令部署，後期再換成跟 github 整合，照文件說法是只能開新的專案。
  Doc: Git integration | Direct Upload。

• 突然不能 deploy 的事件

  曾經發生過 vercel 上游變動，Pages 專案就突然無法 build，也就無法部署新版本的事件，issue #908。
  看 PR #909 勉強可以算 vercel 的問題，但確實需要等 cloudflare 這邊救火。

結論

速度和費用表現是真的不錯（雖然無法免費），但底層相容性的東西會帶來多餘工作，也有心理負擔。 適合真正 edge 特化的輕量功能，或小專案以積極冒險的心態進入。