最近のこと2025年10月某日
最近のことなど。Tech系の話が中心。（というかこのブログでは多分もうそれ以外やらない）
Remix/Drizzle on Cloudflare Workersについて
前回の時点でネックだったRemix on Cloudflare Workersは、Remix starter template使えば割とあっさり解決できたので、基本的には杞憂だった。これでRemix on Cloudflare Workersが動かせることが分かったので、今後開発するWebアプリは基本路線としてRemixを採用し、Cloudflare Workersに乗せていこうと思う。
また、Drizzleが普通に使いやすいORMだということもわかった。生SQL書く部分はPrismaと比べると見劣りしたり等、部分的には厄介な仕様が存在するが、基本的にはPrismaよりDrizzleのほうが使いやすいという状態まで来ている。何よりWorkersと相性がいい（Prismaみたいに軽量のアダプタいれないといけないといった変な考慮が発生しない）のが良い。今後の開発で採用するORMはDrizzleでいこうと思う。
で、そうなると、昔作ったあれやこれやをこのスタックで作り直したくなるのが人情というものだ（？）。現状何も問題がなく動いているアプリを今すぐにリプレースしなければいけないということは当然ないが、Remix＋Drizzleに魅せられた今、Next.js＋Prismaで動いているやつらを積極的に保守していく気は正直湧かない。むしろどうやって動かしていたんだか忘れてきている部分もあり、早いところ移植しないと自分的にも首を絞めかねない状況に陥る危険性がある（何か起きても保守できない可能性がある）。なので、この移植計画がひそかに裏で進行中である。自分専用アプリならもはや適当にsunsetしてもいいのだが、仮にもpublicに見えてる（見せてる）アプリはそういうわけにもいかず、これらが優先的な移植対象になってくる。具体的なアプリの選定と開発作業に水面下で着手し始めている。
ただこういうことやっているとそのうち「Remixに飽きたなあ…」とかいって他のフレームワークに手を出したくなってくるはずで、そのときまた別のフレームワークに移植するかというと、してもいいんだがそこにそれほどの時間と労力をかけたくない。当然だがこの引っ越し作業はそれなりに体力と時間を要するものなので、あまりこれにばかり自分のリソースを割きたくない。（他にやりたいことがたくさんあるのだ）なので、移植は進めつつも、アプリの取捨選択を順次進めていくことも、併せて検討しないといけないな、というのが、移植作業に合わせて今思っていることの一つである。無計画にいろいろ作りすぎた(作りすぎている)ところがあるので、それをもう少しまとめるようなことを考えないといけないなー、と思っているところなのである。今更、って感じだが…
Tシャツ管理機能の改善
以前開発したTシャツ登録・管理機能の中身を少し改修した。この機能、最初の発想は 「とにかくアナログ運用から早く脱却したい」 だったので、深いこと考えずとりあえず最低限の要件を満たすものを早さ重視でまず作ることに集中した。結果、DBが全く正規化されていなかった。具体的にいうと、登録履歴のトランザクションデータしか持ってなくて、マスタが存在しない。データのイメージは以下のような感じ:
| 日時 | バンド | カラー | カテゴリ | Tシャツ名 |
|---|---|---|---|---|
| 2025/10/21 10:11:12 | ストレイテナー | 白 | 半袖 | ほげほげT |
| 2025/10/19 09:10:11 | ストレイテナー | 黒 | 半袖 | ふがふがT |
| 2025/10/18 08:09:10 | ストレイテナー | カーキ | 半袖 | へげへげT |
| 2025/10/17 08:09:10 | ストレイテナー | 白 | 半袖 | ほげほげT |
各レコードにそのTシャツそのものが持つ属性情報「バンド名」「Tシャツの色」「半袖か長袖か」などの情報を保持しているので、同じTシャツを複数回着た時にはこの辺の情報が冗長で登録されることになる。このため、例えば「Tシャツ名を変更したい」という場合、トランサクションテーブルで同じバンド・カラー・カテゴリ・Tシャツ名を持つレコードを抽出してきて一括で全部更新する、といった、なかなか香ばしいupdateを投げなければいけなかった。(上の例だと10/17と10/21で同じ「ほげほげT」を着てるが、「はがはがT」に変更したいという場合、10/17と10/21両方を一括で更新しなければならない)最初の要件 「とにかくアナログ運用から早く脱却したい」 を最低限満たすための実装という意味では間違っていなかったが、運用が落ち着いた頃には、この変な挙動を改善したいという思いが合って、これに8月の中旬頃から着手し始めていた。
完全に正規化する場合は「バンドマスタ」とか「色マスタ」とか、Tシャツに付随する情報を全部別のマスタテーブルに分離するのが筋なんだろうが、作るのが面倒くさそうだったのと、仮にそこまでやってしまうと今度はユーザー（使用者）としての立場での管理が大変そうだという思いがなんとなくあり、一旦「Tシャツマスタ」とだけ分離することにした。つまり上の例だとTシャツマスタは:
| ID | バンド | カラー | カテゴリ | Tシャツ名 |
|---|---|---|---|---|
| 111 | ストレイテナー | 白 | 半袖 | ほげほげT |
| 222 | ストレイテナー | 黒 | 半袖 | ふがふがT |
| 333 | ストレイテナー | カーキ | 半袖 | へげへげT |
になって、登録履歴のトランザクションテーブルは:
| 日時 | TシャツID |
|---|---|
| 2025/10/21 10:11:12 | 111 |
| 2025/10/19 09:10:11 | 222 |
| 2025/10/18 08:09:10 | 333 |
| 2025/10/17 08:09:10 | 111 |
みたいになる。これだけでも大分スッキリして、少なくとも最初の課題（「Tシャツ名を変更したい」という場合、トランサクションテーブルで同じバンド・カラー・カテゴリ・Tシャツ名を持つレコードを抽出してきて一括で全部更新しなけれならない）は完全に解消になった。
ただ一方で、当初は登録履歴のトランザクションのみで運用する想定で開発した機能だったので、そこに管理の都合で割と無理やりこの「Tシャツマスタ」を登場させたことで、データの登録や更新のフローが若干面倒になった。というのも、この機能は、「その日着るTシャツの情報を登録する」という日常の行動と連動しているので、やはり基本的にはまず「登録履歴」こそがデータの主役なのだ。「まずマスタ登録をしてからその日着る情報を登録する」というようなルーチンではない。そのTシャツを過去に着たことかあるかどうか（Tシャツマスタの新規登録か更新か）も、結局「登録履歴」と突合しなければわからない。よって、Tシャツマスタはそういう意味では「オマケ」に過ぎないため、登録履歴だけ作ってさえいればそれでよかった時と比べると、余計に一つ考慮しなければいけないオブジェクトが増えたことになる。その日の記録を登録する前に、過去の履歴を検索し、存在しなければ、登録履歴とマスタを一緒にinsert、過去着たことあるTシャツの場合は登録履歴だけinsert、のようなフローである。「一度も着たことがなければまずTシャツマスタを手動で作る」というフローを入れても良かったが、その場合その日の記録を登録する前にマスタの作成作業が必要になり手間が増える。この機能の運用の趣旨は、「その日の記録を登録する」という日常の行動にあり、運用の中でそれ以外の作業は極力増やしたくなかった。結局、現状の運用をそのままにする形で、裏でデータ作成を振り分ける今の実装に落ち着いた。
振り返って見るとシンプルだが、ここは、自分の日々の行動（運用）と、実際のデータ管理（のための実装）のバランスを考えて、結局こうするしかないな、というところに落ち着くまで、どのような設計にするべきかちょっと考え込む時間が発生し、なんというか「エンジニアリングしてるなあ」と実感した体験だった。どのアプリを作るにしても、それは自分用アプリを作っていてもそうだが、こういうところで設計の検討を喧々諤々としている時間はなかなか面白いものだ。面倒くさかったが、面白い開発をしたなーと振り返っている。
その他
- このブログ、2024円1月ころに開設して以降ビルド回りを特に気にしないままずっと来ているのだが、さすがにそろそろ何か気にしたほうがいいんじゃないかという気がしてきている。というかもっと具体的に言っちゃうとつまり
hugoとPagefind。Remixの方に注力しすぎていてこっちは全然放置だったので、今最新のhugoとかPagefindがどうなってんのか全くわからない。どうもCloudflare Pagesのビルド環境も新しくなっているらしく、この辺整えたほうが良い気がしてきている。ただ上にも書いたNext.js→Remixの移植作業が開始しており、こっちにそこまで時間割きたくない。というかなんあらいっそブログもRemixで作り直しちまうか？とか一瞬考えたが、静的コンテンツをRemix使うのはなんかちょっと違和感あるし、かといってNext.jsのSSGするか？と言われるとそこまで大仰なことしたくないしな…と…後者の考えは当時から変わってないのでその辺自分の感覚はそこまでブレてはいないらしい。まあとにかくここをもう少し長い目で見て改善していかないとなと思っている次第。 - Vercelから卒業したい。別にVercelが嫌になったというわけじゃなくて、管理負担をなくすために、単純にホスティングのサービスを限りなく少なくしたいというのが理由だ。もっと具体的にいうとCloudflare(Workers/Pages)に全部寄せたい。Vercelで動かすことの特有のメリットというのを最早あまり感じなくて、エッジコンピューティングのランタイムという特徴ならCloudflareも同じだし、実際Vercelで動かせるものはWorkers/Pagesでもほぼほぼ同様に動く。（余談だが、この点、Herokuのような純正（？）PaaSはやはり一線を画しており、使うことのメリットを感じられる。やっぱりHerokuはいいですよね（ポジショントーク）。）それと、Vercelで動かすにしても、DNSやらWAFやらは結局Cloudflareを使うことになるわけで、それだったら最初からCloudflareでいいじゃんという気になっている。この「DNSとかでCloudflare使うんなら最初から全部Cloudflareでいいじゃん」はCloudflareを推してるというわけではなくて、どちらかというとCloudflareにまんまとハメられているという感じがしないでもないが、とにかくそんな気持ち。実際それですでにいくつかはCloudflareに移植済だ（自作漫画サイトRESIGN THREATなど）。ただあと2つほどまだVercel上で動いているのがあり、これらをなんとかしたい。1つは自分専用アプリなのだが日々ヘビーに使用する用途がありすぐにsunsetというわけにはいかない（移行期間が必要である）。もう1つはほとんど使ってないのですぐにでもsunsetできるが、一応publicに公開しているものなのですぐに閉じるのには若干の抵抗がある。そんな感じでVercel大脱走を検討中。という話。
