【2024-02-22】Remixを2.7.0にアプデする

背景

2.7.0になってVite使えるようになったってよ。

対応してみた

以下で作成されるアプリと見比べながら対応した。

npx create-remix@latest --template remix-run/remix/templates/vite-cloudflare

ref: https://remix.run/docs/en/main/future/vite

ざっくり対応してみてデプロイしたらエラーが発生。

Error: Failed to publish your Function. Got error: Your Functions script is over the 1 MiB size limit (workers.api.error.script_too_large)

サイズがでっかくなったのか？

原因

Limits · Cloudflare Workers docs

A Worker can be up to 10 MB in size after compression on the Workers Paid plan, and up to 1 MB on the Workers Free plan.

無料プランの上限である1MBを超えていたから。
金払えば10MBに上限が引き上げられる。

何がそんなにでかいんだ？ログ見てみる。
components-FxmZKhWw.js ってなんだろう。やっぱJoy UI(MUI)周りがでかいのかな？

01:16:38.388	build/client/.vite/manifest.json                           24.23 kB │ gzip:  2.14 kB
01:16:38.398	build/client/assets/Typography-0gNoGkRa.js                 65.75 kB │ gzip: 23.26 kB
01:16:38.398	build/client/assets/index-7VWLnNPR.js                      80.38 kB │ gzip: 21.54 kB
01:16:38.398	build/client/assets/components-FxmZKhWw.js                163.85 kB │ gzip: 53.13 kB
01:16:39.093	build/server/index.js             177.21 kB

回避方法

1. 課金

「Workers Paid Plan」はここのことかな？
バンドルサイズ上限についてどこにも言及されていないけど。
開発プラットフォーム | Cloudflare

03-02追記：あってた
Limits · Cloudflare Workers docs

2. Service Bindings

Cloudflare Workersのバンドルサイズはデフォルトでは1MBです。これはRemixのアプリケーションを1つのCloudflare Workersにデプロイするので仕方ないといえば仕方ないです。ですが何かしらの対策をする必要があります。そこで1つの提案としては以下のライブラリを使用してRemixを複数のCloudflare Workersに分割するということを検討してもいいと思います。

なるほど。やりようはあるよと。

結論

リリース前にお金払いたくないし、今は機能追加に集中したいなぁ。
当分Remixは2.6.xで開発しよ。

03-03追記：以下Scrap内で課金したことを書いた😇

saneatsu

【2024-02-22】カスタムドメイン周りでエラー

背景

元々Pages側にカスタムドメインを設定していたが、R2の設定を試すためにR2側でもカスタムドメインを設定した。Pagesの方が無効になったので、R2側のカスタムドメインを削除して、Pages側に再設定し直したところ、Pages側のカスタムドメインが「非アクティブ（エラー）」になっている

CNAMEなどの問題はなさそうなんだけどな。

試す

DNSのレコードを一旦削除して再度カスタムドメインを登録してみると以下のようになった。
色々調べて再度このページに戻ると上のように「非アクティブ（エラー）」になっていた。
が、取得したドメインには問題なくアクセスできる。

結論

良くわからんがアクセスはできているし一旦無視して進む。
DNSの変更やSSL設定の変更が反映されるまで、数時間から最大で48時間かかるって書いてあったし。

追記

2日経っても「非アクティブ（エラー）」のまま。だけどカスタムドメインにアクセスすると正常に表示されるし一旦無視しとこ。

更に追記

3日経ったらなぜか「アクティブ」になっていた...（治っていた）。
なんでなんだ。。

saneatsu

【2024-02-22】メモ

今後こういうこともやっていきたい

saneatsu

【2024-02-24】D1の定期的なバックアップを考える

背景

見える。いつか開発環境と本番環境を間違えた操作をしたり、DB操作周りでやらかす未来が。

調べる

バックアップ形式（スナップショット・Time Travel）

そもそもD1はデフォで用意してますよと。
スナップショット形式でのバックアップはアルファ版までで、今はTime Travelというものがある。

wrangler d1 info YOUR_DB_NAME を実行してversionがbetaだったらバックアップ方法がTime Travelになっているということになる（betaだった）。

自動バックアップ

1h毎に自動でバックアップして24h保持している。
バックアップ中はDBへのアクセスをブロック（1〜2秒で完了するらしい。ホントに？）。
その間に来たアクセスが来たらキューに入れられるので大丈夫。

手動

wrangler d1 backup create YOUR_DB_NAME でできるっぽい。

$ npx wrangler d1 backup create YOUR_DB_NAME

✘ [ERROR] A request to the Cloudflare API (/accounts/ACCOUNT_ID/d1/database/DB_ID/backup) failed.

  The request is malformed: DBs created during D1's beta do not support backups yet:
  DB_ID (v3) [code: 7400]

β版で作成されたDBはバックアップに対応できてないと。
Webからできそうな導線がある。

/backup を入力して「実行」ボタンをクリックしてみる。
無事にできた。
試しに復元してみよう。

前の日付を選択できるようになっているし、「データベースを復元する」ボタンから無事に復元できた。

バックアップ一覧取得

wrangler d1 backup list YOUR_DB_NAME で行える。
得られる情報は以下。

作成日
ブックマークID
テーブルの個数
サイズ
状態（バックアップ中 or バックアップ済）

ローカルにダウンロード

wrangler d1 backup download YOUR_DB_NAME BOOKMARK_ID でできる。
その後 wrangler d1 execute YOUR_DB_NAME --file=users_export.sql でDBに反映

過去7日以内の状態しか復元できないという制限があるから、もし仮にDB周りの復旧に7日以上かかるみたいな場合、とりあえず復旧開始直前の状態をローカルとかどっか別の場所に移して（ダウンロード）しておいて、8日以降に復旧されたらローカルからDBに反映する、みたいなことをする必要があるのかな？？

結論

デフォルトであるのでとりあえず安心。
ありがたい🙏

saneatsu

【2024-02-24】D1でDrizzleのTransactionsは使えない

背景

Drizzleの公式に従ってトランザクションを書いていたら以下のエラーが発生

To execute a transaction, please use the state.storage.transaction() API instead of the SQL BEGIN TRANSACTION or SAVEPOINT statements. The JavaScript API is safer because it will automatically roll back on exceptions, and because it interacts correctly with Durable Objects' automatic atomic write coalescing.

SQLのBEGIN TRANSACTIONやSAVEPOINTステートメントを使用するのではなく、state.storage.transaction() を使用しろとのこと。