Superflare's Design Principles
最近Cloudflare Workers + D1(SQLiteベースの分散データベース)の組み合わせにアツさを感じており、さらにそこに乗せるアプリケーションを開発するフレームワークとしてRemixに注目しています。RailsならHeroku、Next.jsならVercel、RemixならCloudflareという様相です。
とはいえCloudflareについて現状ではフルスタックに対応している仕組みがあるわけでもなく、いろいろ工夫しながらボイラープレートを作る必要があるのが現状。そんな中で粗削りだけれどもフルスタックなフレームワークになるかどうかというところで注目されているのがSuperflareです。
今回はそんなSuperflareのDesign Principlesを勉強がてらまとめてみました。
Superflare's Design Principles
長い間Laravelを使ってきているが、最近はJavsScriptフレームワークの領域に多くの時間を費やすことになってきている。
しかし「フルスタック」ソリューションとして使えると言われているRemixやNext.jsはデータベース、キュー、セッション、バックグラウンドジョブ、メール通知、ファイルアップロードなど、アプリケーションを開発する際に必要な要素をLaravelのフルスタックのようにサポートしているわけではなく、そのような要素についてはそれぞれの目的に適したライブラリをセットアップする必要がある。Superflareはこのような状況に対応するものだ。
Cloudflare as the "Supercloud"
Cloudflareは当初SSLを備えた無料のCDNとしてスタートした。その結果多くのユーザー集め、次にはWorkersを発表した。エッジでJavsSciptを安価に実行できるプラットフォームとしてクールだったが、フルスタックソリューションにはほど遠い状況だ。
そんな中、さらに導入されたのがKVストレージだ。すっきりしていて強力だが、まだ適用できる範囲は限定的で、いわゆるリレーショナル・データベースソリューションにはほど遠いものだった。
その後Durable Objectsが登場し、R2ストレージ、スケジューリングワーカーといった個々のサービスが出てきた末に発表されたのがD1(SQLiteベースの分散データベース)だ。D1がフルスタックソリューションとしてCloudflareを活用する最後のピースであると思う。
なぜならWebアプリケーションを構築する方法の多くはデータモデルを中心に展開されるからだ。RailsやLaravelが何十年も成功を収めてきたのは、ActiveRecordやEloquentという強力なデータベース抽象化機能があったからだ。それゆえに、ここまで強力なプリミティブな要素に投資を続けているCloudflareの将来に対して強気で見ている。Cloudflareのセルフブランド「Supercloud」はこのことを如実に表している。
Building Superflare
Superflareは以下の原則で開発されている。
Vendor Lock-in as a Feature
SuperflareはCloudflareのプリミティブの上に構築されている。つまりCloudflareを使わなければSuperflareを使うことはできない。
他のソリューションはベンダーロックインを避けるために却って複雑な仕組みになってしまっているが、ロックインに傾倒することでシンプルなソリューションを提供することができる。
ストレージ:R2を使う
データベース:D1を使う
キュー:Queuesを使う
リアルタイム性:Durable Objectsを使う
繰り返し処理:Scheduled Jobsを使う
制約があるのは良いことだ。
Not a framework
Superflareはフレームワークではない。フルスタックのツールキットである。
Reactのメタフレームワークは相当数作ってきたが、今日に至ってはRemix、Next.jsといった良いソリューションがある。Superflareにおいてわざわざそれを再発明する必要はなく、既存フレームワークの上に乗っかる「フルスタックツールキット」として共存した方が本当にやりたいことを実現できる。
SuperflareはCloudflareとあなたが選んだフレームワークとの間の「接着剤」なのだ。
D1 and New ORM
しっかりしたデータモデルを持つことはあらゆるアプリケーションの基礎となる。SuperflareはD1を中心に構築されており、アプリケーションを構築する際に最初に接することになるものだ。
個人的な好みだが、ActiveRecordスタイルのawait Post.all()のような記述方法が好きだ。データベースバインディングを渡すことも、オプションのJSONオブジェクトを渡すことも、クエリビルだを渡すこともない。これにはトレードオフがあるが、私はこれで満足している。
No Decorators
他のフレームワークではJavaScriptのクラスに機能を追加する方法としてデコレータが採用されているが、Superflareではできるだけ素に近い(メタルな)方法で実装するポリシーとしている。そのため、データベースの属性はTypeScriptのインターフェースとしてモデルファイルに直接定義されている。
Including Auth
Superflareでは、認証はあらゆるアプリケーションの中核部分であるという考えに基づいて構築されている。そのためSuperflareの新しいテンプレートにはUserクラスとデフォルトのユーザーテーブルのマイグレーションを同梱している。これはLaravelでの開発体験に基づくものだ。
一方でRailsは認証機構を提供していないが、アプリに認証を追加したいときはサードパーティーのgemを探す必要がある(大抵はすぐにでも追加できる)。
Tradeoffs
あなたがSuperflareを使わない理由としては以下の事柄がある。
Vendor lock-in
もっとも、これは明らかだろう。
New ORM
Prismaがデファクトなのに新しいORMを学ぶ必要があるだろうか?
Tension with Wrangler and Cloudflare's official roadmap
Cloudflareで働いているので確かなことは分からないが、彼らがSuperflareが現在解決しようとしている課題の解決を目指した一般的な「フルスタック・スイート」の構築に取り組んでいることは間違いないだろう。
これはSuperflareの一部が陳腐化することを表す上に、Superflareの一部が機能しなくなる可能性もあるが、予測としては理解できることだ。
また、今日Superflareはその機能の多くをnpx wranglerに求めている。これはWranglerが開発サーバーの実行やPages APIとのやりとりををするための外部APIを公開していないためだ。これはツールの開発としてリスキーなので、認識しておいた方が良い。
I'm building this for fun
このプロジェクトは私が楽しむために作っているのであって、完璧を目指すわけではない。
所感
往年のRails勢の私としては、Railsの感覚で開発できるRemixにはかなり期待があり、さらにCloudflareへのデプロイも含めてフルスタックにサポートしてくれるSuperflareにも期待があります。D1もまだまだ粗いのでこれからですが、今から注目していても良い技術要素かなと感じています。
開発体制的にSuperflareにベットするのは控えた方が良い気がしますが、フルスタックに結合する際の参考として押さえておいて損はなさそうです。
現場からは以上です。
この記事が気に入ったらサポートをしてみませんか?