ピン留めされたアイテム

要件

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みたいなことをするのは若干お門違いそう

sushichan044

案: 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同士を連携できるようになった。
しかし、今回のドッグフーディングの背景として、所属する学生団体向けのアーキテクチャ構成案であるためJS RPCは採用していない。Cloudflare Workersにそこまで明るくない後輩が簡単に引き継いだり、そもそもフロントやバックのデプロイ先が変わってもエンドポイント公開だけで済むように純粋なHTTP APIとしての実装に留めておく意図がある。

sushichan044

HonoRPCを正しく動作させるには？

hono/clientにサーバー側Honoの型情報を渡せないといけない
=> 複数Workerのmonorepoにしたほうがプレビューやデプロイも楽になりそうな感じがするな

turborepo導入？=>今月中に検証してみよう

sushichan044

概ね動いてるんだけど、なぜかfrontendがCloudflare Pagesにデプロイできない...

=>これは、Pagesでwrangler.toml使ったときだけService Bindingsの書き方が変わるのが原因だったよう？Workerのenvironmentを指定しないといけない(通常production)
多分近いうちにWorkerにGit IntegrationとPreview Deployが来るのが関係してそう

sushichan044

wrangler.toml修正したら動いたぜ！！！！！！！！！！！！

sushichan044

monicaさんのtwranglerで複数リポジトリのwrangler.tomlを1ファイルで全部定義して各app用に関数をexportするのが、複数の連携したWorkers用のwrangler.tomlを管理する悪くないアプローチに見えるな