denoランタイムのedge functionにAPI置いてみた

状況

Reactでフロント書いてAPIサーバー叩くシンプルなやつ

特徴はwriteが多いユーティリティ

あまり不特定多数からreadされない

writeの体験を良くしたくて基本的にOptimistic Updateが支配的になるフロントエンド

SEOは不要

CSRのみの構成でNextは過剰なのでParcelでサクッと丸めてポイっとデプロイを目指すことにした

APIサーバーをサーバーレスで普通に書いても面白くないので、edge functionを使いたい

DBはなんでもいいけど、クエリする時に型はまともなのが良い

こんな感じ。あとは起きたこととか所感をだらだらメモしておく。

全体所感

deno初めて使った

パッケージシステムにとくにハマりどころが無いのが良い

とくに感想が無いくらいに素直

vscodeでのdeno用のextensionを使うのだが、普通のtsのextensionとちょい違うので整合が気になる

フロントtsとdenoのコードベースの相互運用の話は別途書いた

最初はsupabaseでぜんぶ済まそうと思ってたけれど、クエリするときの型が微妙に弱い。テンプレートリテラルベースで型整合のチェックは行える(とはいえ弱い部分もある)のだが補完候補が出るわけではないのでエディタインテグレーションとしては微妙に使いづらさがあった。prismaが使いたくなったので置き換えるなどした。

ポイントはprismaのdenoクライアントは直でコネクションを張らないので、Data Proxyを経由する必要アリ。現状では Prisma Data Platform を利用することになる。これがだいぶ制約になってしまって、dbアクセスに謎にアメリカVirginiaを経由しなくちゃいけなくなってしまった。自前でプロキシを建てる方法もあるらしいけど、試してない。

UPDATE: denoはN-APIの実装頑張っていて、Deno Deployでは直でprismaが使えるという話を聞いた。未検証

さらにsupabaseのedge functionでじゃっかん詰まって、なぜかset-cookieがリバプロで弾かれてしまった。ちょっと原因が調べきれなかったので、edge functionだけnetlifyに移動。結局supabaseはpostgres dbのためにしか使ってない。そもそもフロントの静的ファイルもどこかにおく必要があったので、netlifyにまとめてデプロイするようにした。

結果的にいろいろ実験のツギハギになっていて、かなりやばいネットワーク経路になっている。意味はないが面白い実験にはなった。

Client → netlify edge function (CDN) → Prisma Data Proxy (West Virginia, United States) → Supabase (Tokyo, Japan)

せっかくAPIサーバーがedgeにいるのに、特にキャッシュを持つなどもせずほとんどの処理はオフローディングできていない。結果としてTokyoまで返ってくるのだ。意味がない。となってくると、edgeにレプリカを持っていきたい発想になっていって、次はCloudflare D1とか実験してみたいところ。しかし今回作ったアプリはwriteがわりとあってreadが支配的というわけでもないので、edgeのMutexなど難しい塩梅。面白い。

アプリはオープンソースでここにおいてある。

deno話は他にも書いたので、ぜひこちらも。