第一個 SaaS 框架 Saavo，折騰完了，還是不太滿意

最近總算把第一個 SaaS 框架整理到可以發布的程度，挑了個簡短的名字 Saavo，沒想到等框架發布了，才發現他奶奶的，竟然也有人弄了一個同名的網站，當初買網域的時候明明還沒有。說實話，做完還是有點高興的，畢竟以後再建立專案，總算有一個可以直接拿來用的範本了。不過回頭看程式碼，整體上還是不太滿意，已經開始想下一版應該怎麼改了，看來東西剛做完就想重寫這個毛病，還是沒改掉……

1. 又造了一個輪子

做 SaaS 總有一些繞不開的東西，登入、使用者管理、付款、郵件、檔案儲存、多語系等等，產品本身的功能都還沒開始寫，就得先把這些東西準備好。每次都重新弄一遍確實麻煩，所以這次把它們放進了一個範本，之後有新的想法，就可以直接在這個基礎上繼續做。

現在除了範本本身，還有建立專案的 CLI 和配套文件，可以從命令列下載範本、初始化本機環境，再按照文件設定需要的服務，最後部署上線。功能方面這裡就不一個一個介紹了，詳細內容可以看文件，這篇主要是想記錄一下做完之後的想法，免得過一陣子又忘了當初自己為什麼這麼選。

發布前又整理了一輪，發現要處理的細節還真不少。例如內容集合是自動產生的，原始碼套件裡不應該附帶，但刪掉之後又得確保初始化時能重新產生，否則型別檢查就直接報錯。還有圖片，原本放在那裡感覺沒什麼，打包之後才發現檔案不小，又去清理沒用到的圖片、壓縮剩下的資源，圖片格式換了之後，還得把網頁和文件裡的引用一起改掉。

文件也是，範本裡的指令改了，文章裡的說明就得跟著改，還得確認到底有沒有漏掉。程式碼、範本、文件，單獨看每一件事都不複雜，放在一起就容易出現這邊改完，那邊還是舊的情況。反正發布前又從頭檢查了一遍，總算把這些問題整理了一下。

2. 做完之後的一些想法

首先還是結構的問題。目前框架整體上有些混亂，雖然分層還算明確，但有些地方做得並不好，特別是資料庫交易（transaction）的處理，用起來不是很順手。現在我還沒完全想清楚，究竟是這些地方沒設計好，還是這種分層方式本身就不太適合。單純把每一層劃清楚，好像也不能解決所有問題，程式碼放在哪裡是一回事，真正寫業務邏輯的時候順不順手又是另一回事。

我隱約覺得，模組化可能會更合適，特別是用來搭配 AI 寫程式的框架，想要什麼功能就引入什麼模組。比如需要付款功能，就把付款模組加進來，不需要的功能就不用帶著，之後修改某個功能的時候，也盡量能在對應的模組裡解決。聽起來倒是挺舒服，不過真要做起來，估計又是另一回事。

SaaS 裡面這些功能並不是完全獨立的，付款功能要知道使用者是誰，使用者又可能有訂閱和權限，一個模組依賴另一個模組的時候該怎麼組織？底層能力由誰提供？設定和資料庫的變更要怎麼處理？這些機制如果沒先做好，最後很有可能只是把現在的程式碼換幾個目錄放進去，名字叫模組，改起來還是得牽動一大串，那就沒什麼意思了。所以這個方向我覺得可以研究，但對框架底層的要求應該會比現在高不少。

再來就是登入驗證，當初真的不應該自己寫，麻煩不說，還花了不少心力，現在回頭看，應該直接改用 Better Auth。造輪子的時候覺得自己處理也可以，做完再想想，這些心力到底有沒有必要花，還是有點後悔。新版準備把這部分換掉，沒必要什麼東西都自己維護。

畫面渲染引擎也是一樣，現在這部分是自己寫的，我也不是很滿意，當初應該選 TanStarter。無奈開始寫這個 SaaS 範本的時候，按我當時了解的情況，TanStarter 還沒發布正式版，最後就自己弄了。現在回頭看這個選擇，總覺得有些地方繞了遠路，不過都已經寫完了，總不能因為現在覺得另一個方案更好，就立刻把整個專案推翻重來。

目前對於下一版，我隱約有個想法，可能會用 Void + TanStarter，再加上現在這個 SaaS 範本已經實作的功能，盡可能把各個模組拆清楚，最後組合在一起。具體怎麼組合、哪些能力應該放在底層、哪些可以獨立出去，目前還沒想清楚，先記在這裡，省得過一陣子又冒出別的想法，把這個給忘了。

不過這次準備先忍住，不急著研究下一版。以前折騰部落格的時候，從 Ghost 換到 WordPress，再換到 Next.js，每次換的理由好像都挺充分，最後程式換了幾輪，文章卻沒多寫多少。這次如果也是範本剛做完，就開始研究另一個框架，估計過一陣子又能寫一篇重構紀錄，至於用它做的專案，可能還是沒幾個……

所以接下來會持續用這個範本建立新專案，多用一下裡面的功能，有問題就改，慢慢把各個模組磨好。哪些功能確實重要、哪些需求值得做、哪些地方看著分層很清楚，用起來卻到處卡手，總得真正做幾個專案才能知道。等以後遷移、建立新框架的時候，也能知道自己到底要改什麼，不然光憑現在這點感覺，換一種結構，搞不好還是一樣的問題。

先用起來吧，下一版的事情等用過之後再說。