Alleycat:我重新製作了部落格的CMS

3 min

language: ja bn en es hi pt ru zh-cn zh-tw

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

image


image


image

話說回來,如果做到這種程度,那用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來實現。

image.png

即使是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以下

image.png

我覺得效果還不錯。

進行構建時會如上圖所示,但待機資源大約是這些。大致會收斂到150MiB以下。

image.png

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


那麼,下次再見。請多指教。

Related Posts