Astro + Cloudflare Worker の静的ブログサイトに、いいね機能を追加する

Cloudflare でやりたいが、Pages Function はちょっと非推奨っぽいので Workers でやる#

Astro はもはやフルスタック Web フレームワークなので、 API Route 的なものを実装してフルスタックなWebフレームワークも作れる。

https://docs.astro.build/en/guides/endpoints/#server-endpoints-api-routes

また、 @astrojs/cloudflare を使うとCloudflare Pages Function で SSR できる。
…が、最近は Workers でも静的アセット配信ができて、 Pages から移行が推奨されている。

https://cai.im/blog/migrate-astro-site-from-cloudflare-pages-to-workers/

そういう風潮の中でわざわざ Pages Function を使うのもアレなので、なんとか Workers と静的アセットでやってみたい

静的サイト + Island Architecture + Workers API#

要するに、ブログの いいねボタン コンポーネントだけが動的な振る舞いを必要としている。
であれば、そこ以外は SSG して必要な部分だけ JS をハイドレーションするという、奇しくも Astro の提唱するスタイルがうまく合致することになる。

サーバーコードをどうするか。#

Web 業界は Next.js や Remix による SSR に回帰しつつあり、バックエンドとフロントエンドの境界がないことも増えた。
しかし、今自分がやろうとしていることはここ最近まで主流だったサーバーとクライアントの完全な分離アーキテクチャである。(3層アーキテクチャとでも呼ぶべきか)

ただ、バックエンドのコードはごく少量であり、わざわざ pnpm ワークスペースを作ったりして分離するのもオーバーな気がする。コード量的に主従の逆転感はあれど、Cloudflare Worker で実行するコードと静的アセットのデプロイ自体は Wrangler CLI を通して同時にするので、同じディレクトリで開発したほうがいい。

そこで、いっそのことフロントのリポジトリに src/workers/main.ts を作って、パッケージを分けずに同居させてしまうことにした。フロント/バックの境界を超えないことを肝に銘じつつ、フロント大多数のコードベースに少量のバックエンドを混ぜる。

1
pnpm add -D wrangler

1
name = "harumaxy-com"
2
compatibility_date = "2025-04-01"
3
main = "src/workers/main.ts"  # wrangler でビルドされる、Workers API のエントリーポイント
4

5
[assets]
6
directory = "./dist/" # `astro build` で出力した静的アセットファイルのディレクトリ

Astro によるビルドと Wrangler CLI によるビルドは独立している。
Astro は中身では vite や esbuild を使用しており、 import していないコードに関しては tree shaking されてバンドルされないはず…

永続化の用意#

いいねを永続化するのに Cloudflare D1 を使う。
全いいね数を集計して表示したいので、標準SQLで count() などの集約関数が使えるため Workers KV より適任

Wrangler CLI から作成

1
pnpm create d1 create <db-name>

1
[[d1_databases]]
2
binding = "DB"
3
database_name = "harumaxy-com-db"
4
database_id = "****-****-****-****-****"

大したことに使わないので、マイグレーションツールを使うでもなく DDL = データ定義SQL を直接実行してテーブルを作成した。 (あとでスキーマ変えたくなったら…とかは考えない。シンプルなことにしか使わないので)

1
CREATE TABLE likes (
2
  slug TEXT NOT NULL,
3
  user_uuid TEXT NOT NULL,
4
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
5
  UNIQUE (slug, user_uuid)
6
);
7

8

9
CREATE INDEX idx_likes_user_uuid ON likes(user_uuid);

Cloudflare ダッシュボード > ストレージとデータベース > D1 SQL データベース > コンソール から直接SQLを打ち込んで本番環境に反映した。このコンソールは本番DBの中身をチェックしたり、ちょっとした手動マイグレーションを行うのに便利。

API の実装#

以下3つのAPIが必要だった。

GET /api/likes/:slug 記事のいいね数(と自分がいいねしたか) の取得
POST /api/likes/:slug いいねをつける
DELETE /api/likes/:slug いいねを外す

(もしかしたら、つける & 外す 1つのAPIにまとめてトグル挙動でいいのかもしれないけど、REST API はべき等性が重要らしいので…)

Workers で RESTful API を生で書こうとすると if 文地獄になるので、 router を持ったサーバーフレームワークを使うのが楽。
Hono で実装してみた。

Cloudflare Workers では、 Request を受取り Response を返す fetch インターフェース に互換性のあるサーバーフレームワークであれば割と簡単に統合できる。(Node.js API などに依存しておらず Web 標準に準拠していること)

コード: https://github.com/harumaxy/harumaxy.com/blob/main/src/workers/main.ts

さらに、サーバーアプリの型を export することで Hono RPC により E2E で型安全な呼び出しができる。
フロントとサーバーの境界を超えて type import しているが、型はトランスパイルで消えるので大丈夫。
無駄なコードがバンドルされることはない。

ビルドされた静的アセットの確認#

一応無駄なコードが入ってないかも確認できる。
Astro は vite (あるいは rollup) ベースなので、プラグインで dist/stats.html を出力して確認。

1
pnpm add -D rollup-plugin-visualizer

1
export default defineConfig({
2
  // ...
3
  vite: {
4
    plugins: [
5
      visualizer({
6
        emitFile: true,
7
        filename: "stats.html",
8
      }),
9
    ],
10
})

いいねボタンの実装#

拝借した Astro テーマの Fuwari が Svelte ベースでコードが書かれているので、余計な依存を増やさないため自分も Svelte で書く。

1
<script lang="ts">
2
  import { hc } from "hono/client";
3
  import { onMount } from "svelte";
4
  import type { countLikes, ServerType } from "@/workers/main";
5

6
  type Likes = Awaited<ReturnType<typeof countLikes>>;
7
  const client = hc<ServerType>(window.location.origin);
8

9
  // Props, States
10
  const { slug } = $props<{ slug: string }>();
11

12
  let userUuid = $state<string | null>(null);
13
  let likes = $state<Likes | null>(null);
14

15
  // Callback
16
  const fetchLikes = async (likedRecently: boolean) => {...};
17
  const saveLikedRecently = () => {...};
18
  const loadLikedRecently = () => {...};
19
  const like = async () => {...};
20
  const unlike = async () => {...};
21

22
  let handleClick = $derived(() => {
23
    if (likes?.likedByMe) {
24
      unlike();
25
    } else {
26
      like();
27
    }
28
  });
29

30
  onMount(() => {
31
    const storedUserId = localStorage.getItem("userId");
32
    if (storedUserId) {
33
      userUuid = storedUserId;
34
    } else {
35
      userUuid = crypto.randomUUID();
36
      localStorage.setItem("userId", userUuid);
37
    }
38
    fetchLikes(loadLikedRecently());
39
  });
40
</script>
41

42
<div
43
  class="bg-white dark:bg-gray-800 rounded-full shadow-lg border border-gray-200 dark:border-gray-700 p-3 min-w-[60px] text-center"
44
>
45
  <button
46
    class="flex items-center justify-center gap-2 w-full text-sm font-medium text-gray-700 dark:text-gray-300 hover:text-red-500 dark:hover:text-red-400 transition-colors"
47
    onclick={handleClick}
48
  >
49
    <svg class="w-5 h-5 {likes?.likedByMe ? 'fill-red-500 text-red-500' : 'fill-none'}"/>...</svg>
50
    {likes?.count ?? ""}
51
  </button>
52
</div>

このコンポーネントのエフェクト

マウントされたら、リモートAPIにいいね数を取りに行き、数を表示する
クリックしたら、既にいいねしたかどうかに基づきいいねする or いいねを外す

ちなみに、ユーザー認証はテキトーです。
ログインなしで気軽に利用できるようにしたかったので。
userId の発行は、 localStorage を見てあればそれを使う、なければ発行して localStorage に永続化って感じで。
多分、localStorage を消したり PC・スマホ・ブラウザを変えたら何度もいいねできるけどそこは気にしない。
(きっちりやろうと思えばできるけど、場末の個人ブログで認証ログインなんて求めたら足ブラウザバックされるので…)

投稿一覧ページでの使用#

実は、あんまり効率の良い実装ではありません…

投稿一覧ページでもメタ情報としていいね数を表示したかったので流用したのですが、いいねボタンコンポーネント自体が状態とエフェクトを持っているので、 1 + N 回のAPIアクセスが発生しています。

これを回避するには、 投稿一覧ページ全体のハイドレーション + いいね数のバッチ取得API が必要です。
呼び出し効率化のためには必要ですが、ちょっとめんどい… (一覧表示の効率化のための特殊化コードが必要)

まあF5連打とかで叩かれると Workers 呼び出し回数が跳ね上がってしまうので、キャッシュでなんとかすることにしました。

1
// いいね数取得の処理
2
const likesApp = new Hono<{ Bindings: Bindings }>()
3
  .get(":slug", pathValidator, queryValidator, async (c) => {
4
    const { slug } = c.req.valid("param");
5
    const { userUuid } = c.req.valid("query");
6
    const likes = await countLikes(c.env.DB, { slug, userUuid });
7
    // ブラウザで30分キャッシュする (経路キャッシュも狙う)
8
    c.header("Cache-Control", "public, max-age=1800, s-maxage=1800");
9
    return c.json(likes);
10
  })

1
  const fetchLikes = async (likedRecently: boolean) => {
2
    if (!userUuid) return null;
3
    const res = await fetch(`/api/likes/${slug}?userUuid=${userUuid}`, {
4
      method: "GET",
5
      // sessionStorage に手動管理の期限付きで、最近いいねした場合は reload、そうでなければ cache があれば使う
6
      cache: likedRecently ? "reload" : "default",
7
      headers: { "Content-Type": "application/json" },
8
    });
9
    likes = await (res.json() as Promise<Likes>);
10
  };

キャッシュが有効になってると、リモートの変更が反映されずバグっぽく見えてしまう可能性があるので、いいねボタンを押した直後 ~ 30 秒くらいの間だけキャッシュを無視して fetch するようなクライアント実装にしました。 (おそらく、React Query 的な something を使ったほうがいい)

この実装だと、一覧ページと詳細ページで GET /api/likes/:slug からのレスポンスキャッシュを利用できるので地味に再利用できている。
(最初の N + 1 クエリは避けれてないけど…)
まあ、いいね数取得は遅延ロードだし、ページの他の静的な部分は高速表示されてるはずなので、そこまでユーザービリティを損ねないと思います。

s-maxage による経路キャッシュも狙ってますが、そもそもエッジで実行されてるし、読み取りが早い D1 なのでいらんかもしれない。

実装内容#

だいたいこんな感じ

https://github.com/harumaxy/harumaxy.com/compare/a1e58996c21deaf9a7538e00d6022dc188e23bf2…a78a17c9b3d5fc49e39dabf7d77755508565466e