Alleycat:我重新製作了部落格的CMS
大家好,我是無能。
我重新製作了部落格的CMS。
GitHub - haturatu/alleycat: cms & frontend · GitHub



話說回來,如果做到這種程度,那用WordPress不就好了嗎?這部分我還是有點疑問。
為什麼要製作它
我的部落格原本在2020年左右從WordPress遷移到LumeCMS,最初的遷移意圖如下:
WordPress
佔用相當多的記憶體
專為個人部落格託管MySQL是多餘的
功能擴展完全依賴插件
CSS等容易變得混亂無法將
admin下的端口分開,難以安全管理直接複製貼上圖片非常方便
所有圖片都會生成縮圖等,產生了不必要的資源
LumeCMS
也佔用相當多的記憶體
由於是SSG的CMS,每次更新一篇文章都會重新構建所有內容,這不夠環保
無法直接複製貼上圖片進行上傳
簡潔性非常好
實際上,只用
markdown寫作並沒有遇到任何困難,但從手機更新的情況也相當多,那時候就比較麻煩了
大致如上所述。
需求
因此,必要的需求如下:
CMS本身可以按端口進行分離
支援圖片複製貼上上傳,並自動生成連結
即使從手機也能輕鬆編輯的設計
CSS盡可能保持在可理解的最小限度
最終不可避免地會增加,這也沒辦法
外部依賴的CSS增加會變得難以理解,所以盡量避免
即使沒有JS也能在前端顯示
從性能角度來看,靜態構建是必需的,而且我也希望它能對我偶爾使用的
w3m用戶友好
目錄(TOC)是必需的
僅僅有這個,可讀性就完全不同了
不過,之前
Lume的TOC本身是從h2開始的,這是為什麼呢?我當時想,但標題不包含在TOC中,這點或許還算可以理解?但不知為何,
Lume的範圍只到h3左右?可能是因為容易破壞設計吧?
編輯器有Rich Editor和
md會比較方便用於手機編輯
現在才意識到資料庫的寶貴
關於實作
我個人覺得Pocketbase非常好用,所以採用了它。資料備份也不需要特意實作,可以直接從標準的Web UI保存備份的zip檔案。
機密資訊的處理也由Pocketbase妥善實作,非常方便。資料庫似乎是SQLite。
此外,我一直想做但門檻很高的多語言支援,決定透過註冊Gemini API來實現。

即使是Google翻譯,也必須特意移動到瀏覽器上方點擊翻譯按鈕,看了許多文件頁面後,我還是覺得有內建翻譯會比較好。不過,這僅限於文章頁面。
如果改變到那種程度,部落格網站不就變質了嗎?或者說,我會在意部落格作者是從哪個國家的視角來寫作的,所以日本人希望以日本人的身份來呈現About頁面,而且在其他頁面也沒有感受到必要性。
inode數量或說磁碟I/O的課題
即使是SSG也面臨類似的問題,構建後文件數量增加時,磁碟I/O會被大量掃描。不不,先不提「文章不會多到inode耗盡吧...」這種吐槽,我不想增加不必要的磁碟讀寫。
關於這點,實際上構建後的公開資料並不需要那麼高的持久性。因此
$ rg tmp
backend/ssr/config.go
13: staticExportDir = getEnv("STATIC_EXPORT_DIR", "/tmp/alleycat-static")這樣,預設將文件輸出到/tmp下,將靜態構建後的文件放置在RAM上進行分發。
圖片資料的儲存位置
基本上,我希望能夠從Web編輯器複製貼上並上傳圖片,並且盡可能讓匯出本身更容易保持文章和圖片集的完整性,因此我決定直接將二進位資料存入Pocketbase。
雖然這點可能有些爭議,但我從來沒有特意查看圖片儲存的資料夾,而且這樣可以減少複雜性。此外,在Pocketbase上進行確認也更容易,這也是我這樣做的原因。
最終資源:500MiB以下

我覺得效果還不錯。
進行構建時會如上圖所示,但待機資源大約是這些。大致會收斂到150MiB以下。

能夠在包含CMS在內的這些資源下實現,我覺得很不錯,而且我也想自己嘗試一下Codex在前端設計方面能做到什麼程度,這也是一次很好的嘗試。
那麼,下次再見。請多指教。