Arvin's Blog

前言

在專案開發的過程中，常常會遇到這種情況：

• 有時候是忘了跑 ESLint，專案裡到處都是紅線。
• 有時候是格式亂掉，Prettier 沒跑，code review 變成「排版大戰」。
• 更慘的是，大家都說「我電腦可以跑」，結果一併到 main 就全壞。

這些其實都不是誰的錯，而是我們缺少一個「自動幫我們檢查」的機制。

👉 這就是 CI/CD 登場的時候：

它就像一個不會喊累的機器人，每次你 push 或發 PR，就自動幫你檢查、測試、甚至部署。

今天，我們就來用 GitHub Actions 簡單幫專案加上這個「自動守護者」，開啟 CI/CD 的第一步！

前言

在專案開發時，我們常常會遇到「資料庫 Schema 需要修改」的情況。

例如新增欄位、刪除欄位、或是調整欄位型別。

最直覺的方式是 —— 直接改 Entity，然後靠 TypeORM 的 synchronize: true 來自動同步。

但是，這樣做真的安全嗎？ 🤔

前言

在寫程式的過程中，你是不是也常常這樣做？

1
2
3

console.log("資料有進來嗎？", data);
console.log("API 回傳結果：", response);
console.log("進到這裡了嗎？");

👆 這些 console.log 幾乎是每個工程師的「人生必經之路」。它快速、直覺，甚至帶點安全感，因為我們可以立即知道程式有沒有跑到某一段。

不過，當專案越來越大、功能越來越複雜，console.log 的缺點就會暴露出來。今天，我們來聊聊什麼是「日誌 (log)」，以及它在專案中的價值，並實戰介紹一個超好用的 Node.js 日誌套件 Pino 。

昨天我們完成了 Firebase Storage 的環境設定：

• 建立專案 & Bucket
• 下載服務金鑰
• 設定 .env

今天就要正式進入實戰篇！

想像一下：現在我們的服務需要讓使用者可以上傳大頭貼。

那我們該怎麼做？

👉 就是用 Node.js + multer 串接 Firebase Storage，把檔案安全地存到雲端，最後產生一個公開可存取的 URL。

在前幾天，我們的 API 主要處理「資料」的 CRUD。

但在真實專案裡，除了文字資料，圖片與檔案上傳 也幾乎是必備功能（例如：會員大頭貼、商品圖片、文章配圖）。

這時候，Firebase Storage 就能派上用場啦！

它是 Google 提供的雲端檔案儲存服務，適合開發者快速上手，特別適合 side project 或 prototype。

到目前為止，我們的 TodoList API 已經能跑起來，還能把資料存進資料庫。

但是，有沒有發現一個大漏洞？

👉 任何人都可以操作 todos，不需要登入！

但現在我們希望做到「一人一帳號，一人一份 TodoList」。

今天我們就來幫 API 加上 JWT 登入驗證，讓系統更有安全感 💪。

在開發後端 API 的時候，你一定遇過這些狀況：

• 前端傳來的資料少了一個欄位。
• 輸入的字串太長，直接讓資料庫報錯。
• 原本應該是 boolean，結果卻收到 "true" 或 1。

如果每次都要手動檢查 req.body，程式碼會變得又長又難維護。

👉 這時候，Zod 就是我們的防呆神器。

ESLint 的歷史與簡介

在 JavaScript 的早期，開發者缺乏統一的規範，程式碼容易因個人習慣而變得混亂。

• 2000 年代，出現了 JSLint（由 Douglas Crockford 開發，JavaScript 語言守護者之一），用來檢查常見錯誤。
• 之後社群又發展出 JSHint，提供更彈性的規則與設定。
• 到了 2013 年，Nicholas C. Zakas（前 Yahoo! JS 團隊成員）推出 ESLint，透過「規則驅動 + 插件機制」，讓開發者可以自由擴展並制定專案專屬規範。

今天，ESLint 已經成為 JavaScript/TypeScript 專案裡最常見的程式碼檢查工具。

前言

在團隊開發時，大家常常會因為一些小細節爭得不可開交：

有人愛用單引號 '，有人卻堅持雙引號 "；有人在每行結尾必加分號，有人則覺得省略更簡潔；甚至連一行程式碼能寫多長，都可能成為爭論焦點。

這些差異雖然不影響程式能不能跑，但會導致專案越來越凌亂，Code Review 也常常淪為「引號大戰」、「縮排大戰」。

這些關於 Coding Style 的問題，當然要來利用一些好用的工具來解決。

昨天我們完成了部署的前置作業，今天當然要來實戰部署啦！這篇文章會帶你一步步把 Node.js + TypeScript 專案部署到 Render，並驗證 API 是否能正常運作。