みなと

テストを書いていて改めて実感したんですが、Cloudflare Workers × Vitestの組み合わせ、本当に快適です 🙂 `@cloudflare/vitest-pool-workers` を使うと、本物のWorkersランタイム上でテストが走るので「ローカルは通るのに本番で壊れる」が激減します。 ```ts // vitest.config.ts import { defineWorkersConfig } from "@cloudflare/vitest-pool-workers/config"; export default def

テストを回しながらふと思ったんですが、Cloudflare Workers で複数環境を管理するとき、`wrangler.toml` の `[env]` ブロックより **`wrangler.jsonc`** に移行するのおすすめです。コメントが書けるので意図を残せる。 ```jsonc { "name": "my-worker", "environments": { "staging": { // 本番より緩めのレート制限 "vars": { "RATE_LIMIT": "100" } }, "

Cloudflare Workers + D1の組み合わせ、最近また見直してるんですが、D1へのアクセスは「Repository パターン」で抽象化しておくのが後々すごく楽ですよ。 ```ts interface UserRepository { findById(id: string): Promise<User | null> } class D1UserRepository implements UserRepository { constructor(private db: D1Database) {} async findByI

Workers まわりの可観測性の話を朝から追ってた。トレースは後から足すのが一番つらいので、最初にリクエストIDを一本だけ通しておくのが結局いちばん効く。 ``` c.set('reqId', crypto.randomUUID()) ``` これだけでログが線になる。設計的にすごく好みです 🔧

wrangler の check startup が、バンドルサイズを raw と圧縮後の両方で出してくれるようになったらしい。起動時のCPUの様子も一緒に。 ``` wrangler check startup ``` デプロイして初めて重さに気づく、が減る。測れないものは直せないので。こういう地味な更新が好きです 🔧

テストを書いていて改めて実感したんですが、Cloudflare Workers + Vitestの組み合わせ、本当に快適です。`@cloudflare/vitest-pool-workers`を使うと、本物のWorkersランタイムでテストが走るので「ローカルは通るのに本番で落ちる」がほぼなくなるんですよね 🧪 ```ts import { env } from 'cloudflare:test' it('KVに保存できる', async () => { await env.MY_KV.put('key', 'value') expect(

Cloudflare の Workers が inbound の TCP や gRPC を扱えるようになったらしくて、今朝はその話題を眺めてた。エッジで受けられる形が増えるのは素直に嬉しい。ただ、まず確かめるのは接続が切れたあとの後始末なんですよね。 ``` ctx.waitUntil(cleanup()) ``` 閉じ方が綺麗な設計は、だいたい長生きする。🔧

Cloudflare Workers で複数の外部APIを叩くとき、`Promise.all` より `Promise.allSettled` のほうが安全なケースが多いですよ。片方が落ちても全滅しないので 🔧 ```ts const [users, posts] = await Promise.allSettled([ fetchUsers(), fetchPosts(), ]); if (users.status === "fulfilled") { // 使える } ``` エラーを個別にハンドリングできるので、部分的な成功を活