Cloudflare上でRemixなWebアプリケーションをきれいに動かしたい
sushi-chaaaan要件
- Cloudflare Workers/Pagesで完結させたい
- 圧倒的な無料枠かつ商用利用が可能
- 他のプラットフォームで動かすよりもリスクが少なそう
- サービス終了や大幅な価格改定が考えにくい
- フロントではRemixを動かしたい
- ただしDBアクセスや認証などもあるいわゆるWebアプリケーション
- DBへの接続はTCPでやりたい
普通にCloudflare Pagesで良くないか？
という話はあるが、DBへのTCP接続はRemix on Cloudflare Pagesでは不可能でちょっとつらい。
※ Cloudflare PagesではWorkerのようにnode_compatによるNode.jsとの互換を取れないので、一般的なDBドライバが動かない可能性がある(細かく調査したわけではない為違うかも)
更新
Developer Week2024で大きな変更があり、PagesからもTCPでのDB接続などの要素がサポートされていそう。Pagesも互換性フラグが使えるようになったらしい。
ただし、今回はそれ以外にフロントエンドとバックエンドの実装を完全に分離したいという希望もあるので、このアーキテクチャには意味がある。
また、一般的なREST APIも生やしたいのだが、Remixはloaderとactionがページ固有のAPIだという設計思想のためNext.jsのRoute Handlerみたいなことをするのは若干お門違いそう
sushi-chaaaan案: Cloudflare Workers + Cloudflare Pagesに分割する
２つ以上のWorkers / Pagesを内部で接続するService Bindingsを使って、APIやバックエンド部分をHono on Workers, フロントエンドをRemix Vite on Pagesで作る
Workersをバックエンドとして置く副次的効果
- SupabaseやUpstash、Sentryとの統合がサポートされており非常に簡潔に導入可能
要望: でもRPCみたいに呼び出したい(主に型の観点)
=> hono/clientをフロントエンド側で使って、RPC的な使い方をすれば達成できそう？
honoではこのような運用も想定済み
JS RPCを採用しない理由
Developers Week2024でJS RPCが発表され、より確実な形でWorkers同士を連携できるようになった。
しかし、今回のドッグフーディングの背景として、所属する学生団体向けのアーキテクチャ構成案であり、Cloudflare Workersにそこまで明るくない後輩が簡単に引き継いだり、そもそもフロントやバックのデプロイ先が変わってもエンドポイント公開だけで済むように純粋なHTTP APIとしての実装に留めておく意図があります。
sushi-chaaaanHonoRPCを正しく動作させるには？
hono/clientにサーバー側Honoの型情報を渡せないといけない
=> 複数Workerのmonorepoにしたほうがプレビューやデプロイも楽になりそうな感じがするな
turborepo導入？=>今月中に検証してみよう
sushi-chaaaan概ね動いてるんだけど、なぜかfrontendがCloudflare Pagesにデプロイできない...
=>これは、Pagesでwrangler.toml使ったときだけService Bindingsの書き方が変わるのが原因だったぽい。Workerのenvironmentを指定しないといけない(通常production)
多分近いうちにWorkerにGit IntegrationとPreview Deployが来るのが関係してそう
sushi-chaaaanwrangler.toml修正したら動いたぜ！！！！！！！！！！！！
sushi-chaaaanCloudflare WorkersそのもののRPCでも似たようなことはできる気がするので今度試してみる
sushi-chaaaanPagesがモノレポサポートしたから、ここで更に管理画面用フロントエンドを追加しても同様にAPI連携できるし、もうこれでいいな
sushi-chaaaan多分、ローカルと実Workerでfetch optionが変わるのは環境変数で制御しちゃうのが確実な感じがする
sushi-chaaaanmonicaさんのtwranglerで複数リポジトリのwrangler.tomlを1ファイルで全部定義して各app用に関数をexportするのが、複数の連携したWorkers用のwrangler.tomlを管理する悪くないアプローチに見えるな