Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Full Stack Cloudflare Wokrers_at_Workers Tech T...
Search
Horai
March 07, 2025
1
270
Full Stack Cloudflare Wokrers_at_Workers Tech Talks in Osaka_2025
Horai
March 07, 2025
Tweet
Share
More Decks by Horai
See All by Horai
HonoとPostgreSQL with Workersを本番投入に向けて検証している話
horai93
3
1.3k
Cloudflare PagesとNewtでHeadless CMSをやってみた
horai93
0
340
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Visualization
eitanlees
146
16k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
14
1.5k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Automating Front-end Workflow
addyosmani
1370
200k
Designing for Performance
lara
608
69k
Bash Introduction
62gerente
614
210k
The World Runs on Bad Software
bkeepers
PRO
68
11k
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Done Done
chrislema
184
16k
Transcript
大変だけど最高な Full Stack Cloudflare Wokrers @Workers Tech Talks in Osaka
#2 Kosuke Horai
自己紹介 • 名前: Kosuke Horai • X: @horai93 • 仕事:
TypeScriptで全部書いちゃう少人数なチームでよく 働いています • 現職: “site:任意の転職サイト Cloudflare Workers” でhit した会社で働いています
話すこと 1. Cloudflare Workers でFull Stack な Webアプリケーションを書きたい 2. Cloudflare
Workers 全振りにおける課題 3. 運用してみた a. Bindingsが便利 4. 見えてきた課題と展望 a. Cache b. Database c. etc..
Cloudflare Workers でFull Stack な Webアプリ ケーションを書きたい
PagesじゃなくてWorkers? • WorkersでもPagesでも同じようなことができるが微妙に違う • 現状は双方に片方にしかない機能があったりする ◦ 雑にGithubと繋いでデプロイするのは Github Pagesの方が楽 ◦
例えばStorybookはPagesとかでGithub接続でいいんじゃないかと思っています 1. Cloudflare Workers で Full Stack な Webアプリケーションを書きたい
WorkersとPagesは統合される(された?) 1. Cloudflare Workers で Full Stack な Webアプリケーションを書きたい
WorkersとPagesは統合される(された?) • 実際にはまだ中途半端な状態 • とはいえWorkersをベースにやっていくのが良さそう ◦ Pagesの方が特殊で、Workersの方が素直に感じている • これまではフロントエンドを考えるとPagesの方が有力だった ◦
Next.jsは next-on-pages (https://github.com/cloudflare/next-on-pages) でデプロイ可能 1. Cloudflare Workers で Full Stack な Webアプリケーションを書きたい
アプリケーションはNext.jsで書きたい! • Remixを書いてたが求人を見てもNext.jsの方が多い • もちろんRemixや他のFWがダメな訳では無いがそれでもNext.jsが王道 ◦ (実際にはそんな理由で技術選定をするのは良くないですが、とはいえ Cloudflareを活かしたいとい う理由でNext.jsから離れてた筆者からするとキャッチアップが大変 ...)
• Next.jsでcacheをうまく扱いながらサクサクなWeb Applicationを良い感じに書きた い! 1. Cloudflare Workers で Full Stack な Webアプリケーションを書きたい
@opennextjs/opennextjs-cloudflare の登場 • 2024 9月26日にCloudflareのBuilder dayで発表された • WorkersでNext.jsが動かせる ◦ edge
runtimeではなくNode.js runtime(Cloudflareによるnodejs compatibility) • 2025年3月7日時点ではまだ
[email protected]
1. Cloudflare Workers で Full Stack な Webアプリケーションを書きたい
フロントエンドはNext.jsで書ける!!
APIはHonoで書きたい!
なぜ Hono? • Next.jsのApp Routerでサーバーも書い てしまうことはできる • とはいえapiとフロントは切り離しておき たい... •
HonoでWeb StandardsなReq/Resに よるAPIの書き心地が最高 • Honoはどこでも動く のでもちろん Workersにデプロイできる! 1. Cloudflare Workers で Full Stack な Webアプリケーションを書きたい https://x.com/honojs/status/1700865974201991635
FEもBEもWorkersで書いて、 どちらも妥協せず使える! 最高!!
本当に??
@opennextjs/opennextjs-cloudflare の課題 • (再掲)2025年3月7日時点ではまだ
[email protected]
• 直近までcacheサポートがなかった。。 • せっかくNext.js使うのにCacheが良い感じに扱えない 2.
Cloudflare Workers 全振りにおける課題 (実は3月現在 d1によるCache サポートが入った @opennextjs/opennextjs-cloudflare#320)
データベースの枯れた選択肢がない • Cloudflare D1を採用する • トランザクションが必要だったり Writeヘビーだと怖いがReadメイ ンであれば使えそう • ただ10BGのsize
limitがある 2. Cloudflare Workers 全振りにおける課題
実際に運用してみた
CacheはProxyで実現 • HonoでProxyのWorkersを作成、KVにキャッシュする • Next.jsのアプリケーションは前段で全てCache Workersを通す 運用してみた 参考: Cloudflare Workersプロキシパターン
https://zenn.dev/yusukebe/articles/647aa9ba8c1550
Service Bindingsが便利 • CacheのWorkerからNext.jsを呼び出すのにBindings(http)が使える • Next.jsからのデータ取得もBindings(RPC)でシームレスに繋がる 運用してみた
Service Bindingsが便利 • fetch部分を `c.env.NEXTJS_APP.fetch(...)` のようにするだけで呼べる • これによってNEXTJS_APPはhttpに露出しなくても呼び出せる 運用してみた
Next.jsからHonoへのデータ取得はRPCコール • 運用してみた
なんとか良い感じに!(?)
課題、今後の展望
今後の展望 • @opennextjs/cloudflareの成熟を待ちつつCacheを試す • BindingsでPR単位のプレビュー環境を作れない(作れても大変) • Cloudflare D1がまだ成熟していない?(有力なDBの選択肢の不足) ◦ データのエクスポートをするにも公式の
export apiは処理がブロッキングされるため 気軽に実行できない (D1のdocumentより) > A running export will block other database requests. ダメゼッタイ `npx wrangler d1 export <database_name> --remote --output=./database.sql` ◦ Branchingがサポートされる予定の模様
Appendix
Appendix - Service bindingsのLatencyがないは本当? • new Date()を返すだけのWorkers を用意 • Service
BindingsのRPCにより呼 び出してかかった時間を計測
Appendix - Service bindingsのLatencyがないは本当? • 初回リクエストで10msぐらい余分にかかってそう • 直後のリクエストではそれがなくなる
Thank You!