cutty.dev 的技術棧 — 有意識的選擇

大多數的「我的技術棧」文章都是一份引以為傲的新技術清單。看看，我有這個，我有那個，這裡還有上週才出的新函式庫。這篇會有所不同。

因為事實是，當你獨自執行一個專案時，你追求的不是最流行的。你追求的是那種不會讓你凌晨三點驚醒的東西。而這正是 cutty.dev 技術棧的核心所在：追求無聊而非流行，追求歐洲風格而非美國風格，從根本上注重隱私，且足夠簡單，讓一個人就能搞定。

我會依序說明，就像我們在喝咖啡時聊天一樣。

Astro 伺服器端渲染 (以及為什麼不選擇更「酷」的方案)

cutty.dev 是一個具備伺服器端渲染（SSR）功能的 Astro。每個請求都會經過伺服器，組合成頁面並回傳完成的 HTML。無聊嗎？這正是其精髓所在。

我想要三件事：無需沉重架構的伺服器端渲染、現成的完善多語言支持，以及沒有額外開銷的速度。Astro 提供了一切，且代碼保持清晰易讀。當我在兩個月的停頓後回到它時，我清楚知道發生了什麼。對於單人開發項目來說，這比任何一年後就沒人維護的流行插件都更有價值。

一個檔案取代煙火資料庫

SQLite。一個資料庫，磁碟上的一個檔案。再加上一個與 TypeScript 溝通的查詢層，因此當我更改資料結構時，錯誤會在我的編輯器中彈出，而不是在午夜的生產環境中出現。

為什麼偏偏是這個？cutty 是「read-heavy」。有人點擊短連結，我們進行讀取並增加計數器。就這樣。SQLite 可以輕鬆應對這種流量，直到每天非常龐大的數字。那備份呢？複製檔案即可。結束。不需要複雜的複製程序，也不需要沒人記得如何運作的腳本。

這裡要注意一點，因為這是一個常見的陷阱：人們聽到「SQLite」時會覺得它只是「用於通過課程作業的小玩具」。事實並非如此。更少的移動部件意味著更少可能出錯的地方。這不是為了節省成本而犧牲品質，而是一個深思熟慮的決定。

伺服器位於歐洲，這並非巧合

位於歐盟的專用伺服器。自有 TLS、具備自動 HTTPS 的反向代理、容器化應用程式。

這是 cutty 處理數據的方式之基石。我清楚地知道它們物理上存放在哪裡（對於歐盟客戶和 GDPR 來說，這不是一個有趣的資訊，而是一個必要條件），我不依賴單一供應商，沒有任何數據會自動洩漏到海外，且費用是可預測的，而不是隨著流量波動而跳動。

是的，來自西方的便利平台能提供更快的起步。點擊、部署、運行。只是你必須以用戶數據的存放地作為代價。對我來說，這是一筆糟糕的交易。

使用自己的模型進行翻譯，在本地端

cutty 會說 25 種語言。這是由運行在我基礎設施上的本地、開源 AI 模型進行翻譯的。我不會將介面中的文本發送給任何外部供應商。

好處是實用的。單次翻譯的成本為零。我對品質擁有完全的控制權，並且可以隨時更新它們。而且機器始終需要人工審核，因此這 25 種語言中的每一種都經過了檢查。但事實上，因為是我親自處理，這意味著隱私並非價格表中的一項條目，而是整個架構本身具備的特性。

Tailwind、容器以及一些較小的決策

風格？Utility-first，也就是 Tailwind。沒有 CSS-in-JS，沒有獨立的樣式檔案，一切都直接寫在模板中。我不需要浪費時間去構思類別名稱，未使用的樣式也不會進入最終頁面，而且設計也會保持一致，因為系統本身就強制要求了這一點。對於一個人來說，每一分鐘都不應該浪費在瑣碎的事情上。

這就是 Docker 的部署。無論是在本地還是生產環境，都是相同的環境，不再有「在我的電腦上可以執行」的問題。而且如果有一天需要，我可以在大約半小時內將整個系統遷移到另一台伺服器。可移植性是一種無聲的獨立形式。

我的心得

無聊的技術棧勝出。Astro, SQLite, Tailwind, 容器。一切都已成熟、被廣泛使用且有詳盡的文檔。在最不需要的時候，不會發生任何崩潰。

歐盟的託管已經準備好投入生產環境了，真的。那種「你必須使用美國大型雲端才能展現專業」的說法，純屬幻想。在地化的 AI 也是可行的，不需要為了獲得不錯的翻譯而將數據交給外部 API。最後一件事：一個人可以發布出看起來像是整個團隊共同完成的作品。只需要記住，時間比金錢更昂貴，並從這個角度來選擇每一個組件。

當你在建立屬於自己的東西時，面對每一項技術都要問自己一個問題：一年後我能獨自維護它嗎？如果不能，那麼你大概已經得到答案了。

這一切都在這裡運行：cutty.dev。如果你想討論其中任何一個決定，請寫信至 [email protected]，我會在當天回覆。