Architecture

🤞 完整範例：Github Repo │ 👻 Live Demo：點我看 demo 本專案實作略過點擊次數統計及來源訪客分析。 短網址（Short URL）是什麼？ 短網址（Short URL）是將原始長網址透過 URL shortening 技術轉換為較短字串的結果，使連結更容易分享、記憶與管理。常見服務如 Bitly 與 TinyURL。 範例 原始網址（Original URL）： https://www.google.com/maps/place/Taipei+101+Shopping+center/@25.0341017,121.5642863,19z/data=!3m1!5s0x3442abb6d95eb43b:0xbfc3edc9e6aa3050!4m6!3m5!1s0x3442abb6da80a7ad:0xacc4d11dc963103c!8m2!3d25.0341222!4d121.5640212!16s%2Fg%2F11fx91ft3n?entry=ttu 短網址（Short URL）： https://url-shortener-doe.vercel.app/twLgDN 🥺🥺🥺 由於本專案部署於 Vercel，並使用其提供的免費子網域作為服務域名，而該網域本身字元較長，因此短網址的整體長度也相對受到影響（所以本篇範例和 Demo 的短網址會比較長喔）。 例如使用 reurl.cc 產生的短網址長度就只有這樣：https://reurl.cc/53ZNyR 為什麼需要短網址？ 縮短冗長 URL，節省字元空間 便於在字數受限的平台（如社群媒體、簡訊）分享 提升連結外觀整潔度與可讀性 可追蹤點擊次數、來源、地理位置等數據 可自訂短網址 slug，強化品牌辨識 隱藏原始網址中的參數與路徑結構 部分服務支援設定連結到期時間，控制存取期限 短網址的實際運作流程 當使用者點擊一個短網址時，系統背後其實會經歷一連串非常快速的查詢與轉址流程。從使用者的角度來看只是一次點擊，但在系統內部則包含「識別 → 查詢 → 重新導向」三個核心步驟。 整體流程可拆解如下： 1. 使用者請求短網址 使用者在瀏覽器輸入或點擊短網址：https://url-shortener-doe.vercel.app/twLgDN ，此時請求會被送往短網址服務的伺服器。這類伺服器通常是邊緣節點（Edge server）或 API server。 2. 系統解析短碼（Short Code） 伺服器會從 URL path 中解析出短碼：twLgDN，這個短碼是整個系統的核心 key。 3. 查詢對應的原始網址（Original URL） 系統會透過 key-value lookup 查詢儲存層，例如：Redis、Database、Cache layer。 ...

🤞 完整範例：Github Repo │ 👻 Live Demo：點我看 demo 專案被擴充得越來越大時，發現自己埋的坑越來越多。 為了讓示範更清晰，本文先略過 TypeScript。 前期 API 的呼叫方式 前期開發 React 專案時，我習慣將 API 請求統一集中在資料夾 /api 下，由每個 component 單獨呼叫使用。 專案規模擴大後出現的架構問題 隨著專案的規模愈來愈大，功能愈來愈複雜時，同一個 API 在多處被呼叫，我開始碰到以下問題： 每個 component 需各自維護 loading / error / data 等狀態，導致狀態管理分散、代碼冗餘 同一支 API 被多處重複呼叫，導致請求重複，造成不必要的 Network、後端壓力及 UX 延遲 資料 cache 的缺失，不同 component 中拿到的資料內容可能出現不一致，需額外處理 資料轉換邏輯分散，難以維護 錯誤處理容易不一致，難以維護，使用者體驗不穩定 跨 component 的資料共用困難，狀態同步成本高，可能需要不斷地通過 props 傳遞或使用 store ⋯⋯ 架構的重構：API / Service / Hook / Component 因此，我決定重新設計資料存取的架構。將原本由 component 直接呼叫 API 並處理所有相關邏輯的做法，依責任拆分為 API 層、Service 層、Hook 層與 Component 層。透過職責分離，讓每一層專注於單一責任，進而提升整體的可讀性、可維護性與可擴充性。 ...