Cloudflareスタックを使ってみたかった

Cloudflareの主にPagesとWokersとD1を使ってWeb&モバイルアプリケーションを作りたかった

開発体験も重視

前提としてクライアントにWebだけでなくモバイルも対応させたいため、Pages Functionsではなく、独立したバックエンドサーバーを建てる必要があった。

つまりWorkersでサーバーを建てる

まず、Honoを触った。
感触はとても良かったが、一つ問題が発生する。

モバイル対応しながらEnd-to-Endな型安全開発を実現するためには、honoのRPCモードやtRPCではなく、OpenAPIかGraphQL（gRPCは開発体験が無理）を使う必要があった。

そこでHonoのZod OpenAPIを使った。

しかし、ParamとBodyを同時に取得できなかった謎のバグ？だけでなく、OpenAPIをほぼ生で書いていく必要があったため、そもそもの開発体験がうーんという感じだった。

理想はFastAPIやNestJSの開発体験だった。

そこで、HonoをやめてCloudflareのitty-router-openapiを使ってみるもそもそも型安全じゃなかったり。。。

Cloudflare WorkersでDXの良い型安全なOpenAPI開発はまだ時期尚早であったことを認識し、GraphQLを使うことに決める。

しかし今度は過去の開発経験から、「せっかくGraphQL使うならDBスキーマからCRUD自動生成くらいしてほしい」という欲が出てきてしまった。(RESTではそうならない)

そう、DrizzleからDrismaにする必要が出てきたのだ。

そもそもDrizzleのクエリの仕方は癖がありPrisma育ちの自分からすると少し書きづらいところもあり、それも相待ってPrismaにしたかった。

しかし、D1未対応という現実が待ち受ける。

そもそもD1対応がKyselyかDrizzleの選択肢しかない状況で、D1を使おうとするのが違ったのかもしれない。

ここでD1を諦める。

さようならD1。おかえりSupabase。

PrismaかつCloudflare Wokrersを使うとなれば、Prisma Accelarateを使う必要があるが、そもそもD1の夢を捨て去った自分にとってCloudflare Workersに固執する必要も無くなった。

さようならWorkers。おかえり何か。

SupabaseのEdge FunctionsではPrisma Accelarateを使う必要があるため、Node.jsも動かせるVercel FunctionsやCloud Functionsを使うのもあり。

あれ・・・何か大事なことを忘れている・・・？

結論、Cloudflareスタックはまだ早い。

Prisma D1対応求む