Dockerfile、環境變數與 API endpoint：又一次自我懷疑與架構整理之旅 🐳🌳

今天的第一個挑戰，其實昨晚睡前就開始煩惱了：「Danny，你 Dockerfile 裡的啟動命令是不是又亂寫了？」果然，一早檢查 deployment log 時發現，前端的 CORS 一直在鬼叫，後端 API 的 domain whitelist 根本沒吃進去。稍微 debug 一下才發現，原來是 Dockerfile 裡啟動命令格式有問題，環境變數沒正確注入，導致 CORS 一直預設成 localhost。每次遇到這種問題我都會忍不住自問：「這種低級錯誤你還要犯幾次才學乖啊 Danny？」🤷‍♂️

順便趁這次機會，把之前一直拖著沒做的環境變數設定腳本也寫一寫。過去每次部署 beta、development、production 環境時，都得手動改 .env 文件，然後再三檢查，生怕漏了什麼設定。今天乾脆一次寫個 bash script，讓環境變數自動化管理，以後只要一個指令就能切換環境，不用再手動複製貼上了（這種手動操作實在太容易搞錯，每次都讓我壓力山大）。一邊寫腳本一邊想：「Danny，以前你到底怎麼忍受這種人肉設定的折磨啊？」🤦‍♂️

做完環境變數的 script，順手又把 `.gitignore` 裡面加了環境特定的 .env 文件，避免不小心把敏感資訊 commit 上去。這種東西雖然看起來簡單，但就是那種「你沒做沒事，但一旦出問題就會後悔到爆炸」的事情。現在總算能安心一點了吧。

下午把 api-client 裡的 API base URL 結構重新整理了一次，移除了之前多餘的版本號 prefix。原本 API URL 裡面有個 `/v1`，但回頭想想，這種版本號放在 URL 裡面，未來如果要升級到 v2 時，前端是不是又要整個改一輪？後來決定乾脆直接去掉，反正 API 的 breaking change 本來就應該盡量避免，版本管理應該靠 header 或其他方式處理才對。這種決定其實我也猶豫了很久：「Danny，你這樣真的比較好嗎？還是你只是想偷懶？」🤔 但想了想，還是覺得這樣的設計比較靈活，至少未來 API 升級時不會被 URL 卡死吧（希望如此）。

整理完 api-client，回頭看了一下 IngreLens 的架構文件，發現已經跟實際狀況脫節不少，於是又忍不住開啟了文件更新模式。說真的，文件這種東西每次寫都覺得很煩，但每次遇到坑時又會後悔沒好好維護。這次乾脆花了點時間，把系統架構圖跟技術選型的部分重新梳理了一次，至少下次回頭看時不會又一臉懵逼：「Danny，當初這裡你到底怎麼想的？」🤷‍♂️

順便今天也在 requirements 裡新增了 aiohttp，原本一直都是用 requests 做 HTTP call，但最近越來越覺得同步 call 在某些場景下有點拖慢了整個 API 的回應速度。雖然 asyncio 的東西之前也不是沒碰過，但每次引入新東西時還是會有點不安，忍不住自問：「Danny，你真的需要這東西嗎？你會不會只是想玩新玩具？」但考量到後續成分分析跟第三方 API call 會越來越多，還是決定給 aiohttp 一個機會。反正試了不行再退回 requests 也不遲（希望到時候不會打臉自己）。

最後，今天也稍微調整了前端 FeedbackContent component 的聯絡資訊顯示方式，之前一直覺得那裡的資訊有點混亂，使用者常常找不到該去哪裡聯絡我們。這種小細節雖然看起來不起眼，但每次有使用者抱怨時我都會覺得有點愧疚：「Danny，你每次都說要以用戶為中心，但這種 UX 的小問題你居然現在才發現？」😅

今天的工作雖然又是各種小修小補，但每次這種架構整理的過程，總會讓我重新思考產品的設計跟未來的發展方向。也許這種不斷懷疑、不斷修正的模式，就是創業的日常吧。