タグ

ブックマーク / zenn.dev/chimame (5)

  • RPC対応によりCloudflare Workers間の連携がすごいことになった

    時間の2024/04/05にCloudflareからRPCを使用したCloudflare Workers間の通信が発表されました。 これによりいくつかの課題が解決されると同時にCloudflare上にアプリケーションを構築する利便性が1段階どころか2段階以上上がったといっても過言ではないと思っています。 このRPCの対応によりService Bindingsが更に使い勝手がよくなったのでそれの紹介です。 出来上がりのコードはここにありますので、時間の無い方はこちらを参照ください。 前提条件 以前RemixとPrismaでD1に接続する記事を書きました。 その中で容量制限の問題があると書きましたが、それを解消する話をベースに今回のRPC対応の内容を書きます。ですので記事を読んでない方はCloudflare Workersの無料版はビルドファイルが1MBまでの制限があるということを念頭にお

    RPC対応によりCloudflare Workers間の連携がすごいことになった
  • Remix 2.7で安定版となったCloudflare PagesのVite対応の実現方法を読み解く

    Remix 2.7がリリースされました。この2.7からは今までunstableであったVite対応が正式版として採用されたバージョンとして登場しました。 この2.7以前はunstableであったものNode.jsのランタイムでは動作するものが提供されていましたが、Cloudflare Pagesでの動作するものは提供されていませんでした。しかし、2.7のリリースと同時にCloudfalre Pagesで動作するものがリリースされたということで何が変わって、どう対応しているのかというのを調べた結果を纏めておきます。 2.7.0のリリース後にいくつかのバグが修正されているので、2.7.0ではなく移行のバグ修正版を使用することをオススメします。 また、Vite版への移行は公式にドキュメントがあるので合わせて読むと理解が深まると思います。 初期package.jsonの違い まずは、従来版とVit

    Remix 2.7で安定版となったCloudflare PagesのVite対応の実現方法を読み解く
  • 現状Cloudflare WorkersでGraphQLサーバを構築するならコレ

    結論 Cloudflare WorkersでGraphQLサーバを立てて普通に動く TCPでのデータベース接続も問題ない(ベータなので使ってると何かあるかもしれないが) Node.js互換は完全ではないので、Node.jsが必要な処理はオリジンサーバを用意するのが吉 動機 Cloudflare WorkersはCDN上のプロキシやRemixやNext.jsのレンダリング用のバックエンドとして使うというようなことが多いです。フロントエンドからデータ取得や更新するためのAPIとなると別のバックエンドサーバを立てて、構築するのがほとんどだと思います。 自身も漏れなくそのパターンでNode.jsでバックエンドサーバを立てることが多いですが、そうなると簡単に建てれるCloud Runを初手で選ぶのですが、Cloud Run自体は素晴らしいサービスなんですが、更に欲が出てくるのが人間です。 デプロイを

    現状Cloudflare WorkersでGraphQLサーバを構築するならコレ
  • 実用に耐えうるCloudflare D1で使えるORM(ぽいのも含む)達

    現状Cloudflare D1で使用できるORMとその使用方法ついてに纏めておこうという自分のメモを兼ねた記事です。記事中でRemixとの組み合わせで書いてますが、最後のSuperflare以外はRemixは特に必要ありません。 前提条件 ORMだけでなく、Databaseのマイグレーションも出来て運用に耐えるものを選択 今回の記事ではできるだけ実運用に耐えうるものを書いてみました。 まとめ Kyselyはクエリビルダーだけあって、ORMでは届かないSQLを書き足す場合には採用の価値あり D1だけで見るとDrizzleは意外と使える。(Prismaに比べると見劣るのは仕方ない) Superflareはまだまだアルファの域を出ないのでProductionでは採用出来ない。 今の所、初手で選ぶなら Drizzle >= Kysely >>>>>> Superflare かなという印象です。 K

    実用に耐えうるCloudflare D1で使えるORM(ぽいのも含む)達
  • Next.jsのISRを独自に構築する ~ Cloudflare Workers編(Cache APIの注意点) ~

    Next.jsにはIncremental Static Regeneration(以降: ISR)というレンダリングの仕組みが存在します。ところがこれを利用するにはVercel上でNext.jsを使用しないと完璧な動作をしないことは知られています。ですが、このISRの仕組みは従来のSSRよりサーバの処理コストはもちろん、キャッシュという仕組み上レスポンスにも非常に効果のあるものです。 今回はこのISRを独自に構築するための技術を記事として起こしていきます。 記事の続きとなるものはこちらに記載しておりますので、合わせて御覧ください。 【前提条件】 ISRが何という説明は記事では行いません。 システム構成上、1記事ですべてを説明するにはボリュームが大きいので複数記事に分けさせて頂きます。 記事で詳細するシステム構成には一部成約が存在します。 使用するNext.jsもしくはそれに準ずるもの

    Next.jsのISRを独自に構築する ~ Cloudflare Workers編(Cache APIの注意点) ~
  • 1