iT邦幫忙

2025 iThome 鐵人賽

DAY 11
0
佛心分享-SideProject30

《韌性生活指南:用科技打造更堅韌的日常》系列 第 11

Day 11|系統架構決策:為何選這樣的技術組合?

  • 分享至 

  • xImage
  •  

日常中的韌性練習:讓準備變成生活的一部分

「最好的防災,不是臨時啟動的備案,而是持續進行的日常。」

這不是在颱風天打開網站的瞬間,
而是在一個普通的週末早晨——
主角打開「韌性生活指南」,
看到首頁上浮現一段 AI 提醒:

「距離上次檢查避難包已過 90 天,
天氣轉濕,建議檢查電池電量與食品保存期限。」

系統根據使用者的行為紀錄(MongoDB Atlas),
透過後端 Node.js / Express 排程,自動發送「週期性檢查提醒」。
AI 模組同時生成一段生活語氣的建議,而非警告:

「你今天不必重新採買,只要確認現有物資。
若有過期項目,系統會自動幫你建立待補清單。」

清單生成後,前端(Next.js)頁面立即更新,
可選擇「自動比價購物」或「暫存提醒」兩種模式。

這樣的機制,不需要災難、也不依賴恐懼。
它讓準備變得像日常維護手機一樣自然——
安靜、不打擾,卻持續在身邊運作。

因為真正的韌性,不是臨時防守,
而是平時就建立起的 可回復力(recoverability)與自我掌控感


「架構的目的是為了讓產品能真正跑起來。」

在前十天,我們談了理念、使用者、情境與需求。
今天,正式踏進技術篇的第一步:
要用什麼樣的系統架構,才能支撐「防災避難包智慧推薦平台」?


為什麼要談「架構」?

對一個 side project 來說,最常見的迷思是:

「是不是要用最潮、最先進的技術,才顯得厲害?」

但實際上,架構設計不是堆疊 buzzword,而是找到「能跑得動、能維護、能迭代」的組合。
尤其這個專案,重點不是打造一個完美的系統,核心在於 「推薦清單」「資訊可及性」 ,讓用戶可以 快速獲得實用的防災建議 ;讓 防災資訊真正被看見、被理解、被使用


架構全覽:六個組件

以下是我為這個專案選擇的技術組合,並附上思考過程:

  1. 前端:React / Next.js + Tailwind CSS

    • 理由:快速開發、社群資源豐富,Next.js 讓 SEO 與 Server-Side Rendering 更容易。
    • vibecoding觀點:UI 要「乾淨清晰」,讓用戶專注在清單,而不是被花俏的設計分散注意。
  2. 後端:Node.js / Express

    • 理由:輕量、快速建 API,能自然串接 AI 模組、資料庫與外部 API,對接前端與資料庫最合適。
    • vibecoding觀點:避難物資會隨時間、場景動態調整,後端要是能「調度資訊」的中樞,確保每個請求都被正確轉譯。
  3. 資料庫:MongoDB Atlas

    • 理由:雲端託管、文件型結構彈性高,方便儲存不同情境的物資清單(如地震 vs 颱風)。
    • vibecoding觀點:使用者輸入的年齡層、家庭型態、是否有寵物,對應到「物資集合」時,需要靈活結構。
  4. AI 模組:OpenAI API

    • 理由:用於生成個人化(情境化)說明與推薦理由,將艱澀的官方清單轉化為「人能理解」的語言。
    • vibecoding觀點:AI 不只是推薦,而是把「冷冰冰的清單」翻譯成「溫暖的指引」。
  5. 外部服務:momo / PChome / 誠品 API(電商串接)

    • 理由:直接把清單轉化為「購買入口」,從指南到行動一氣呵成。
    • vibecoding觀點:災難準備常因「懶得去買」而中斷,若能直接串購物平台,就能降低心理阻力。
  6. 部署:Vercel + MongoDB Atlas(雲端組合)

    • 理由:Vercel 天然適合 Next.js 專案,搭配 MongoDB Atlas,能快速布署且維護成本低。
    • vibecoding觀點:部署要像「防災演練」一樣簡單快速,讓開發者不被技術環境困住。

https://ithelp.ithome.com.tw/upload/images/20251013/20178703x1PN56mwDR.png


決策邏輯:為什麼不是別的?

  • 不用Django/Rails?
    太重,對小型專案來說維護成本過高。
  • 不用SQL資料庫?
    防災物資清單結構多變,NoSQL 彈性更大。
  • 不用本地部署?
    這是要分享的 side project,不是企業內網系統,快速上雲更符合需求。

為什麼 AI 模組仍需要後端?

AI 模組(OpenAI API)雖然強大,但它不能取代後端。
後端是「指揮中心」,負責整合多方資料並確保安全與邏輯。

  • 安全性:API Key 不暴露在前端。
  • 商業邏輯:後端先整合家庭資料、官方清單與電商資訊,再交給 AI。
  • 流程控管:防止 AI 輸出錯誤或重複結果。
  • 成本管理:簡單邏輯由後端運算,AI 僅用於必要的語意生成。

簡單說,AI 是「顧問」,後端是「總管」。
沒有後端,AI 就無法安全有效地成為產品的一部分。


小結

選擇能讓產品能長出來的技術。

這個組合的核心精神是:

  • 前端簡單易用
  • 後端輕巧穩定
  • 資料庫彈性足夠
  • AI提升使用者體驗
  • 部署快速、維護低成本

接下來的幾天,我會依序拆解每一塊,從使用者介面開始,一步步打造出能「真正陪伴使用者」的防災平台。

明日預告(Day 12): 前端設計——如何讓「韌性」成為 UI 的語言?


上一篇
Day 10|使用者旅程地圖:從問卷到個人化清單
下一篇
Day 12|前端設計:React/Next.js 與使用者介面
系列文
《韌性生活指南:用科技打造更堅韌的日常》30
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言