Gnar Blog

Why CloudFlare?

原本只想架在小主機上 但由於流量不確定 為避免之後擴充問題 決定嘗試雲端方案 使用 CloudFlare 的主要原因如下：

  • 自身網域都是掛 CloudFlare
  • 擁有良好的防護機制（避免帳單爆炸 🫠）
  • 解決方案豐富，整合得很好

使用後也發現 CloudFlare 對於服務的整合上真的非常方便

All in CloudFlare

CloudFlare 提供了 Workers 讓開發者能自行部屬環境 在連結資源上非常方便 本專案使用 Next. Js 建構，搭配多項 CloudFlare 服務：

使用的服務與架構

  • D 1 (Database)
    • 支援 SQL 語法，可搭配 drizzle 使用
  • KV Namespace (Cache)
    • 以 key-value 暫存 D 1 查詢結果
    • 減少 API request time：800 ms → 200 ms
  • R 2 (Cloud Storage)
    • CloudFlare 自家的 S 3 儲存方案
    • 「R 2」代表「Reduced Redundancy」，象徵更低成本
      這裡有踩到一個坑 NextJS 預設會自動壓縮圖片 看請求會發現 由 _next/image/{img_url} 輸出圖片 就算 Image 裡面元素放的是外部連結也會被壓縮 Image 要補上 unoptimized 關閉 Next. Js 的影像優化機制 由於圖片已先行處理過成 webp，不需要額外優化 由 500+ ms 降至 160~180 ms (20 kb)

專案架構與開發流程

在 AI 的協助下 目前在開新專案我會透過以下流程

  1. 確認可行性

    • 目標: 能透過 YouTube 影片結合字幕達成「歌詞播放器」效果。
      • 控制播放器
      • 取得播放器進度
    • 流程
      • 請 LLM 生成最簡版本驗證可行性
      • 可行後再逐步訂出 SPEC SPEC 的制定，以自己開發經驗來說，都是會滾動調整的，不一定要完美，但盡可能精準列出需求

  2. 訂 SPEC

    1. 列出需求 包含功能、環境、工具、部署環境等
    2. 和 LLM 討論並調整 通常 LLM 都會過度設計，挑出自己需要的內容，減少不必要的設計
    3. 如需資料庫或複雜結構
      • 先訂出 INTERFACE
      • 請 LLM 補充架構，確認是否有少考慮的設計
    4. 最後我會盡可能選擇自己熟悉的語言、工具
      • 盡可能能理解整體專案結構，現在用下來的體驗雖然首輪的功能是沒問題的，但後續如果有新增功能，很容易發生 side effect
      • 如果有新工具要學習，先讓 LLM 產出簡化範例，快速理解使用方式

  3. 測試上線 整套服務幾乎都掛給 CloudFlare

  • 不需額外特別處理防攻擊、快取優化等問題
  • 除基本功能外，額外加入以下監控與分析：
    1. Google Analytics - 分析網頁流量來源
    2. Google Search Console - 提供網站索引與搜尋追蹤
    3. Google PageSpeed Insights - 測試網頁效能
  1. 補充 CloudFlare 有提供 ZeroTrust 的功能 可以設定特定路徑需要經過 CloudFlare 的認證才能存取 如果管理人員數量不大，可以直接透過該設定指定路徑的存取方式 而權限的解析，可以直接解析 cloudflare 的 jwt，使用下來學習成本低，蠻推薦使用的

最後來放一些網站截圖