Alleycat: ブログのCMSを作り直した

4 min

cms雑記ブログ自宅サーバー自宅鯖サーバー
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無しでもフロント側見れるようにする

    • パフォーマンスの面でもStatic Buildは必須でありかつ、私も今も時々使うw3mユーザに優しい仕様にしたかったです

  • TOCは必須

    • これがあるだけで見えやすさ全然違う

    • ただ、前までLumeのTOC自体h2からだったのはなぜだった？と思ったけどタイトル相当は TOC に含まれないというのは割とちょっと納得出来るかも？

    • ただなぜか Lume は h3 ？くらいまでしか範囲対象じゃなかった

      • デザイン崩れやすくなるからかな？

  • エディターはRich Editorと md あったら楽

    • スマホから編集用

  • DBのありがたさに今更気づく

実装に当たって

個人的に Pocketbase がかなり使いやすかったので採用しました。データのバックアップもわざわざ実装しなくても、標準のWeb UIからバックアップの zip ファイルを保存出来ます。

秘匿情報系の扱いも、 Pocketbase 側で良しなに実装してくれているのですごく楽です。DBは SQLite みたいです。

また、ちょっとやりたかったけどどうしてもハードルが高かった多言語対応を Gemini API を登録することで多言語対応化することにしました。

image.png

Google翻訳でもわざわざブラウザの上の方に移動して翻訳ボタン押さないといけないし、合ったほうがいいのは色々なドキュメントページ見てやっぱり思いました。ただし、あくまで記事ページベースだけです。

あくまでそこまで変えてしまうとブログサイトとしては変わってしまう？というかブログ筆者がどこの国の人からの視点で書いているかは気になるから、日本人は日本人として About ページ的なの寄りにしたいし他ページで必要性を感じていなかったからです。

inode数というかディスクI/Oの課題

SSGでも同じような問題を抱えてますが、ビルド後のファイル数が増えた場合のディスクI/Oは激しく走査されます。いやいや、 inode 枯渇するまで記事は増えないやろ・・・というツッコミは置いてあまり必要性の無いディスクのrwを増やしたくありません。

これに関しては実際ビルド後のパブリックデータに関してはそこまで永続性の必要はありません。そのため

$ 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