Day 5 談到，當便當系統從一家店走向多家店，原本藏在環境裡的固定值開始一個一個變成正式的 Domain Data。

店家、菜單、價格、截止時間，都不能再假設永遠只有一個答案。

但做到這裡，GAS + Google Sheets 還是能用。

登入可以登入。

訂單可以讀。

便當可以下單。

資料最後也都有正常寫進去。

如果只用一個標準來看：

功能有沒有完成？

那我其實沒有什麼非換架構不可的理由。

開始讓我重新思考這件事的，是一個看起來沒有那麼嚴重的問題：

幾乎每一個主要操作，都要等一下。

登入，常常要等約 1～3 秒。

讀取訂單資料，也可能要等。

操作過程重新取得資料，再等。

最後送出訂單，又是一段等待。

任何一次單獨拿出來看，好像都還可以接受。

但便當系統不是每天只做其中一個動作。

使用者走的是一整段流程。

這讓我第一次開始把「一個 Request 多久」和「使用者完成一件事要等多久」分開來看。

單次 1～3 秒，沒有我一開始想的那麼嚴重

如果今天有一支 Request 要跑 2 秒，我第一個反應不一定會是：

這個架構不行了。

因為很多系統操作本來就不是瞬間完成。

更何況當時的 GAS + Sheets 已經成功完成它最重要的任務：

• 快速把系統搬到手機
• 不需要先建立完整 Backend
• 資料直接可見
• 很快就能進入真實使用

如果只是看到：

某個動作：約 1～3 秒

就直接得出：

GAS 太慢
↓
換掉

反而會把問題看得太簡單。

事情開始改變，不是因為某一個 3 秒，而是：

這些等待會在同一段 User Journey 裡一直重複。

後來我不再只看單點 Latency

假設一次訂餐流程大致包含：

進入系統
↓
完成登入
↓
取得目前資料
↓
查看／選擇餐點
↓
重新取得必要狀態
↓
送出訂單
↓
看到結果

使用者不會把這些步驟拆開來評分。

他感受到的是：

等
↓
操作
↓
等
↓
操作
↓
再等

這時候，即使每一段等待單獨看都沒有「慢到壞掉」，整體體感還是會逐漸變差。

我後來開始區分三件事。

這三個不是同一件事。

而 Day 6 影響我架構判斷的是第三個。

Request Latency 是一個點，Journey Latency 才是使用者走過的整條路。

便當系統又剛好是一個每天都會使用、而且任務本身很小的工具。

使用者的目的不是：

使用這套系統。

而只是：

把今天的便當訂完。

當任務本身很小，等待反而更容易被感覺到。

我開始不只問：

有沒有壞？

而是一起看：

• 慢的是不是核心 User Journey？
• 等待會不會每天反覆出現？
• 完成一件事到底要經過幾個等待點？
• 哪些等待是必要工作，哪些可能和目前執行模型有關？

光把等待點攤開來，問題就開始變得不一樣。

這時候我才開始重新看 GAS 的執行模型

這裡有一個很重要的順序。

不是：

覺得 GAS 慢
↓
決定換 Cloudflare
↓
開始搬

而比較接近：

發現完整操作流程反覆等待
↓
開始拆解等待究竟發生在哪一層
↓
重新檢視目前執行與資料存取方式
↓
找一個不同模型做 POC
↓
再決定值不值得遷移

後來出現 Workers + D1，對我來說首先不是一次正式重寫。

比較像是一個問題：

如果把同樣的核心流程放進另一種執行模型，這些等待有沒有機會改善？

我先做的是 POC。

而不是先宣布：

接下來全部搬到 Cloudflare。

這個差別很重要。

因為 POC 的目的不是證明我已經選對。

而是允許結果告訴我：

到底值不值得換。

POC 要回答的，不只是「哪個比較快」

如果只是拿兩個平台比 Benchmark，很容易又變成：

GAS vs Workers
誰比較快？

但真實系統的架構選擇沒有那麼單純。

我需要重新比較的是：

我不是在找：

哪一個技術比較高級？

而是在問：

原本那個選擇替我解決的問題，現在還是不是最重要的問題？

架構不一定是「選錯了」才需要換。

有時候只是：

問題已經換了。

GAS 完成了它的任務

如果現在回頭看 Day 3，我還是會做非常接近的選擇。

因為在第一版時，我最需要的是：

快速實作
+
快速驗證
+
資料可見
+
低進入成本

GAS + Sheets 幫我把系統送到了使用者手上。

也正是因為有人開始每天使用，我才有機會看到：

• 資料開始承擔真實責任
• 固定值開始變成 Domain Data
• 使用流程裡開始累積等待
• 系統開始需要新的長期能力

如果第一版就為了「未來可能有效能問題」，先建立一整套更複雜的 Backend，

很可能是在真實需求還沒有出現之前，就提前支付架構成本。

我不會把這段演進總結成：

GAS 不好
Workers + D1 比較好

我更傾向寫成：

第一階段的問題
→ GAS + Sheets 是合理答案

真實使用後出現新的責任
→ 原本答案開始需要重新驗證

什麼時候「有點慢」真的值得動架構？

這次經驗後，我會先問幾個問題：

1. 慢的是不是核心 User Journey？
2. 等待是偶發，還是每天反覆出現？
3. 問題是單一 Query / UI 可以改善，還是和執行模型本身高度相關？
4. 目前架構的其他優點，是否仍然大於遷移成本？
5. 能不能先用 POC 驗證，而不是直接重寫？

如果只是某一個頁面偶爾慢，

通常不值得拿整個系統開刀。

如果一個 Index、Cache 或 Query 就能處理，也沒有理由為了效能故事去換平台。

架構遷移有自己的成本：

• 資料要搬
• 行為要保持一致
• 身份與權限要重新確認
• 舊資料不能遺失
• 新舊環境會有一段共存期
• 測試與部署方式也會跟著變

「覺得慢」絕對不等於「應該重寫」。

值得注意的是：

核心流程反覆付出等待成本，而且原本架構正在同時面對新的責任。

這時候，重新驗證架構才開始有意義。

我最後換掉的，不只是技術

Day 3 的問題是：

怎麼最快讓這套系統真的可以被使用？

Day 4、Day 5 之後，問題已經逐漸變成：

一套每天真的有人使用，而且責任持續增加的系統，要怎麼繼續長下去？

Day 6 又多了一個新的壓力：

功能可以完成，不代表整段使用體驗已經足夠好。

這也是 Workers + D1 POC 開始出現的原因。

不是因為 GAS 突然不能用了。

不是因為看到新的技術就想重寫。

也不是因為某一支 Request 剛好跑了幾秒，就判定整個平台失敗。

而是當我把整段 User Journey 攤開來之後，第一次很清楚地看到：

那些單次看起來可以接受的等待，正在整條流程裡一遍又一遍地被支付。

架構遷移不一定始於「做不到」。

有時候 forcing function 反而是一個系統每天都能正常完成工作，

但你已經開始知道：

它不應該一直讓使用者這樣等下去。

本系列實作專案

這不是純概念示範，而是一套持續開發中的便當訂購系統。文章著重「為什麼」，GitHub 保留實際程式碼、文件與演進紀錄。

GitHub：https://github.com/henryfir456/bento-order-app

下一篇

效能讓我開始重新思考系統跑在哪裡。

但當系統真的往新的架構移動之後，另一個更根本的問題很快就浮出來了。

同一個人可能從不同入口進來。

員工編號是一種入口，LINE 又是另一種入口。

麻煩的不是：

登入有沒有成功？

而是：

這兩個入口進來的，到底是不是系統裡的同一個人？

當訂單、餘額、權限與歷史都開始依賴「你是誰」，

登入就不再只是一個登入畫面而已。