ローカルファーストなソフトウェア：クラウドがなくても動くツールであるべき理由

心当たりがあるはずです。依存しているアプリが、最悪のタイミングで「計画メンテナンス」でダウンします。締め切り前夜、ローンチ当日の朝、本当に仕事をしようと確保した数時間の午後。スピナーか502ページか、「問題を調査中」という明るいステータスツイートを眺めながら、待ちます。選択肢がないからです。データは相手のサーバーにあり、アプリは薄いクライアントであり、相手のサーバーが上がっていないと、手元には何もありません。

あるいは別のパターン。会社が買収され、18ヶ月後にワークフローの基盤全体を築いたプロダクトがサンセットされます。コミュニティに感謝するブログ記事が上がり、30日間のエクスポート窓口が開き、そして消えます。3年間毎日使っていたものは、欲しくもない何かのランディングページへのリダイレクトになります。

あるいは料金のパターン。一人あるいは小規模チームに合っていたプランが消えます。使っていた機能が、3倍の料金のプランの背後に鍵がかかります。払うか、去るか。しかし去るということはデータを置いていくことを意味します。エクスポートはリレーションの半分を失ったCSVか、来週までレートリミットに引っかかるAPIか、他の何も読めないフォーマットだからです。

これがクラウド依存のソフトウェアのコストであり、人々は押し戻し始めています。

その押し戻しには名前があります。ローカルファーストと呼ばれ、私は今のソフトウェアアーキテクチャにおいて最も重要なアイデアの一つだと思っています。新しいからではありません（実はコンピューティングで最も古いアイデアです）。SaaSのゴールラッシュの間に私たちが集団として忘れ、請求書が回ってきた今、思い出しているからです。

「ローカルファースト」が実際に意味するもの

「ローカルファースト」という言葉は、2019年のInk & Switch（Evernoteのチームが設立した研究ラボ）の研究論文に由来します。"Local-first software: You own your data, in spite of the cloud" という論文は、別のソフトウェアの作り方の原則を提示しました。精神は単純で、実行は難しいものでした。もし、毎日使うソフトウェアが、あなたのデバイスを真実の源として扱い、クラウドをオプションの便利さとして扱ったらどうなるか。

私が考える中核の原則は次のとおりです。

データはまずデバイスに、次にクラウドに置かれます。 「クラウドに同期されローカルにキャッシュされる」のではありません。ローカルが先です。ローカルのコピーが本物で、クラウドのコピーはレプリカです。

インターネット接続がなくてもアプリは動きます。 「gracefully に degrade する」のではありません。動きます。Wi-Fiを切ったまま開き、データを読み、編集し、新しく作り、閉じる。すべて壊れずに済みます。

クラウドは同期と共同作業のためであり、基本機能の要件ではありません。 これが鍵の区別です。クラウムは機能であり、依存ではありません。欲しいときはそこにあり、いらないときは不在です。

データはあなたのものです。 いかなるベンダーも締め出せません。支払いを止めても、会社が倒産しても、知らないうちに犯した利用規約違反でBANされても、データはまだあなたのマシンに、読めるフォーマットで存在します。

両隣の2つのアーキテクチャと対比する価値があります。

クラウドファーストは、ほとんどのSaaSの姿です。データはサーバーにあります。アプリ（Webアプリ、モバイルアプリ、Electronラッパーを問わず）は、データを取得して描画する薄いクライアントです。サーバーが落ちるか、ネットワークが落ちるか、セッションが切れれば、手元には何もありません。自分のデータへのアクセスを借りている状態です。

ローカルオンリーはもう一つの極端です。90年代の古いデスクトップアプリや、スクリプトで開くSQLiteデータベースファイルを想像してください。すべてがマシン上にあります。同期も、共同作業も、マルチデバイスもありません。永遠に動きますが、孤立しています。ハードディスクが死んでバックアップがなければ、消えます。ラップトップとデスクトップで作業したければ、手動でファイルをコピーし回ります。

ローカルファーストはその統合です。ローカルオンリーの恒久性と所有を、クラウド同期の便利さと共に得ます。ただし同期は付加的であり基盤ではありません。同期を取り除いてもアプリは動きます。クラウドを取り除いてもデータは残ります。

ローカルファーストが解く問題

クラウドファーストのソフトウェアで実際に壊れていることを具体的に見ていきましょう。上の原則は抽象的ですが、問題は具体的です。

稼働時間への依存

クラウドアプリに関する面白い事実があります。壊れる場所が2つあります。あなたのネットワークが落ちればサーバーに届きません。相手のサーバーが落ちればサーバーからあなたに届きません。どちらにしてもスピナーを眺めることになります。どちらの故障モードも制御できません。インターネットプランを上げることはできても、AWS us-east-1の不調を止めることはできません。

ローカルファーストのアプリが壊れる場所は1つ、あなたのマシンだけです。マシンがオンならアプリは動きます。それだけです。制御できないネットワークへの依存も、見えないサーバーへの依存もありません。故障の影響範囲は「あなたとデータセンターの間のインターネット全体」から「目の前のラップトップ」に縮みます。

ローカルマシンが決して故障しないとは言いません。故障します。ハードディスクは死に、バッテリーは膨らみ、コーヒーはこぼれます。しかしローカルマシンの故障は一人の問題であり、解決策の分かった問題です（バックアップ、新しいマシン、別デバイスの同期コピー）。クラウドサービスの故障は全員の同時の問題であり、唯一の解決策は待つことです。

サンセット問題

これが実際に私を怖がらせる問題です。仮説上の話ではないからです。絶えず起きています。

会社がツールを作ります。人々が採用します。ワークフローを築き、何年分ものデータを入れ、日常生活に組み込みます。そして会社が資金を使い果たすか、プロダクトではなくチームを欲しい誰かに買収されるか、「エンタープライズAIソリューション」その他の流行りのピボットをします。プロダクトがサンセットされます。

クラウドファーストのアプリがシャットダウンすると、すべてを失います。サーバーの電源が落ち、アプリは動かなくなり、サーバーに住んでいたデータは消えます。エクスポートが提供されるかもしれません。それが使えるかもしれません。30日の猶予があるかもしれません。ないかもしれません。

ローカルファーストのアプリがシャットダウンすると、失うのはアップデートだけです。それだけです。既にインストールしたアプリは動き続けます。マシンに住んでいたデータは、まだマシンにあります。ツールを無期限に使い続けられます。ただ新機能やバグ修正は得られません。いずれ、OSのアップデートがアプリを壊すかもしれません。それは現実の問題です。しかし「いずれ動かなくなるかもしれない」と「3月31日に動かなくなり、データも一緒に消える」は全く異なる命题です。

人々のデータを道連れにしたクラウドアプリの墓場があります。Google Reader。Sunrise。Workflowyの旧料金モデル（サンセットではないが、「あなたのデータが有料壁の向こうに」という瞬間でした）。資金を使い果たしたすべての小さなSaaS。ローカルファーストはこれに対する構造的な防衛です。データが誰かのサーバーに置かれたことがなければ、サンセットでデータを追い出されることはありません。

価格交渉のレバレッジ

クラウドSaaSには、人々が十分に考えていない特定のレバレッジがあります。データを人質に取るのです。

SaaS企業が悪意でこれをしているとは言いません。ほとんどはしていません。しかしアーキテクチャが、使う使わないにかかわらずレバレッジを与えます。支払いを止めれば、アクセスを切れます。そしてここでの「アクセス」とは、「何年もかけて作ったデータを開き、読み、使う能力」のことです。エクスポート機能は彼らが制御するバルブです。良くも悪くもできます。すべてのリレーションと添付を剥がしたCSVにもできます。30日与えることも、何も与えないこともできます。

ローカルファーストはこのレバレッジを完全に取り除きます。ローカルファーストのアプリの支払いを止めても、アプリは動き続けます。データは残ります。開き、読み、編集する能力は残ります。失うのは同期、アップデート、プレミアム機能、つまり本当に払う価値のあるものです。選択肢がないから払っているものではありません。

これはアンチSaaSではありません。私はたくさんのSaaSに課金しています。しかし毎回、アクセスを借りているのであって道具を所有しているのではないと意識しています。ローカルファーストは道具を所有することについてです。ビジネスモデルは異ならなければなりません。ソフトウェアに、同期に、アップデートに課金します。しかしユーザーとの関係はより健全です。ユーザーは顧客であり、人質ではありません。

プライバシーとコンプライアンス

データが他人のサーバーを経由しません。それは単なる哲学的な点ではありません。法的・運用上の点です。

GDPR、HIPAA、SOC 2、その他のコンプライアンス制度の対象となるデータを扱っているなら、データが触れるすべてのサーバーが責任源です。スタック内のすべてのSaaSは、評価すべきベンダー、署名すべきデータ処理契約、心配すべき侵害面です。クラウドファーストのソフトウェアはこれらの面を増やします。すべてのツールが、データが住むもう一つの場所、侵害されうるもう一つの会社、フロー内のもう一つのサブプロセッサーです。

ローカルファーストのソフトウェアはこれらの面を縮めます。データがマシンに留まれば、他人のインフラに触れません。中核機能について評価すべきベンダーがありません。同期がオプションで使わなければ、データはどこにも流れません。同期を使う場合でも、データがどこに行くかについて意図的な選択をしたのであって、アプリが動かないためにデフォルトでサーバーに流れたのではありません。

単なる基本の尊厳の問題でもあります。書くすべてのノート、走らせるすべてのクエリ、開くすべてのファイルが、モデルの訓練に使うかもしれない企業、集計分析を売るかもしれない企業、自分が聞くこともない召喚状に応じて引き渡すかもしれない企業に見えている必要はない、と思います。ローカルファーストは仕事を自分のことに留める方法です。悪いことをしているからではなく、それはあなたのものだからです。

パフォーマンス

これは過小評価されており、「モダンな」ソフトウェアがいかに遅く感じるかに気づく人が増えるにつれ、より重要になっています。

クラウドアプリは基本的にすべてでネットワークの往復をします。何かをクリックすると、アプリがサーバーにリクエストを送り、サーバーがデータベースにクエリし、データベースが応答し、サーバーが応答し、アプリが再描画します。それはミリ秒、サーバーの場所とホップ数によって数十から数百ミリ秒です。コールド接続、TLSハンドシェイク、DNSルックアップが加われば秒に届きます。タブをクリックするのに1秒かかるアプリを使ったことがあるでしょう。アプリが複雑だからではありません。アプリが遠いからです。

ローカルファーストのアプリはマイクロ秒で操作を行います。データはそこにあります。ディスクはそこにあります。CPUはそこにあります。往復はない、なぜなら移動がないからです。だからローカルファーストのアプリは、どれだけ最適化されていてもクラウドアプリが到達できない速さを感じさせます。エンジニアリングの努力の問題ではありません。物理の問題です。光は速いですが、ローカルのメモリバスはもっと速いです。

これは人々が認める以上に重要です。速さは機能です。10msで応答するアプリと200msで応答するアプリの違いは、手の延長のように感じるアプリと、リクエストを作って返事を待つように感じるアプリの違いです。ローカルファーストはデフォルトで前者を与えます。

トレードオフ（正直に）

ローカルファーストがただだとは言いません。そうではありません。クラウドファーストが10年勝った理由は、構築しやすく、収益化しやすく、スケールしやすいからです。ローカルファーストは本当に難しい問題を解くことを求めます。

共同作業はより難しいです。 クラウドファーストのアプリでは、サーバーが一つで真実の源が一つなので、共同作業は簡単です。二人がドキュメントを編集し、サーバーが編集をマージして終わり。ローカルファーストのアプリでは、二人が二つのローカルコピーを持ち、それらが収束する必要があります。それは分散システムの問題であり、分散システムの問題は有名に簡単ではありません。コンフリクト解決が必要です。並行する編集をデータや状態を壊さずにマージする方法が必要です。ここでCRDT（Conflict-free Replicated Data Types）が登場し、CRDTは本当の研究領域であり、理解せずに使えるドロップインライブラリではありません。

マルチデバイスには同期が必要です。 データをラップトップ、スマホ、デスクトップで欲しければ、何かがそれらの間を動かさなければなりません。その何かは同期レイヤーであり、同期は作ろうとするまで簡単に聞こえるものの一つです。二つのデバイスがオフラインで同じレコードを編集したらどうなる？一週間後にデバイスがオンラインに戻ったら？同期サーバーが落ちていたら？これらは解決可能な問題です。AutomergeやYjsのようなツールがまさにこれを解決するために存在します。しかしアーキテクチャが勝手に解決するのではなく、自分で解決すべき問題です。

箱から出してリアルタイムのマルチユーザー編集はありません。 同期レイヤーがなければ、二人が同じデータを同時に編集できません。それぞれ自分のコピーを持てますが、互いの変更をリアルタイムで見られません。Google Docs風の同時編集が欲しければ、自分で構築する（またはそうするライブラリを使う）必要があります。クラウドファーストのアプリはサーバーが共有ビューなのでこれを無料で得ます。ローカルファーストのアプリはそれを構築しなければなりません。

アップデートはあなたの責任です。 クラウドファーストのアプリでは、ベンダーがサーバーをアップデートし、全員が即座に新版を得ます。ローカルファーストのアプリでは、アップデートが各クライアントに届かなければなりません。オートアップデータがこれを扱いますが、これも構築・保守すべきものであり、ユーザーはアップデートを拒否できます（所有には良いが、全員を最新にしたいベンダーには悪い）。ロングテールの問題もあります。バージョン3でデータ移行を出荷しても、何年もバージョン1のユーザーがいるかもしれず、彼らが最終的にアップグレードしたときにデータを扱わなければなりません。

これらは現実のトレードオフです。だからこそすべてのアプリがローカルファーストになるべきではなく、クラウドファーストが消えない理由です。しかしエコシステムがこれらを扱うのが上手くなっています。CRDTライブラリは成熟しています。同期インフラはコモディティ化しています。ローカルファーストの構築コストは下がり、クラウドファーストのコスト（ドルのコストも依存のコストも）はより見えるようになっています。

実践におけるローカルファースト：誰がやっているか

これは理論上の動きではありません。ローカルファーストの原則に基づく現実のプロダクトがあり、その一部は広く使われています。私が注目しているいくつかを挙げます。

Obsidian はおそらく最も目立つローカルファーストの成功例です。ノートアプリで、すべてをマシン上のフォルダ内のプレーンなMarkdownファイルとして保存します。そのフォルダを任意のテキストエディタで開けます。Dropbox、iCloud、git、Obsidianの有料同期サービスで同期できます。アプリは完全にオフラインで動きます。もしObsidianという会社が明日消えても、ノートはMarkdownのまま、すべてが読める形でそこにあります。これは最も純粋な形のローカルファーストであり、EvernoteやNotionを離れた多くの人がここに着地した理由です。ホストされたwikiの中のデータが決して到達できない方法で、データはあなたのものです。

Linear は部分的な例であり、興味深い例です。Linearはプロジェクト管理ツール（基本的にはIssueトラッキング）で、クラウドに支えられています。しかしローカルファーストに感じるよう設計されています。アプリは積極的にキャッシュし、操作は楽観的で、UIはサーバーが確認する前に応答します。真のローカルファーストではありません（サーバーが落ちるとあまりできない）が、クラウドアーキテクチャの中でさえローカルファーストの原則を体験に適用できることを示しています。速さと応答性は、ローカルの状態を主としてサーバーを同期先として扱うことの直接的な結果です。

Reflect はCRDTの同期レイヤー上に構築されたノートアプリです。ローカルファーストで、マルチデバイス同期が組み込まれています。ノートはマシンにあり、デバイス間で同期し、同期がコンフリクトを自動的に処理します。「ローカルファースト＋同期」モデルの良い例であり、ローカルの所有とクラウドの便利さを得て、難しい部分（コンフリクト解決）は同期インフラが扱います。

BaseVolt は私が最も近いものです、私が取り組んでいるので。デスクトップのデータベース管理パネルであり、Webベースのデータベースツールのローカルファーストな代替と考えてください。データベース（ローカルのSQLiteファイルかもしれないし、リモートのPostgresサーバーかもしれない）に接続し、マシン上でオフラインで動き、クエリや接続情報がサードパーティのサーバーを経由することはありません。保存したクエリや接続設定のデバイス間同期のためのオプションのクラウド同期はありますが、中核のツールはそれなしで動きます。これを挙げるのは、このエッセイがBaseVoltについてだからではありません（そうではありません）。ほぼ完全にクラウドファーストに移行してしまったカテゴリ（データベースツール）にローカルファーストを適用した例であり、その移行は間違いだったと私が考えているからです。

より広いCRDTエコシステム が可能にするレイヤーです。Automerge、Yjs、および類似のライブラリが、リアルタイム共同作業付きのローカルファーストアプリを構築することを実用的にしています。数年前なら、二人にオフラインで同じデータを編集させきれいにマージさせたければ、基本的にオリジナルの研究をしなければなりませんでした。今はライブラリを使えます。これが、ローカルファーストを単一ユーザーのツールを超えて実現可能にしているインフラの変化であり、今後数年で、現在はクラウドバックエンドが必要に見えるカテゴリにより多くのローカルファーストプロダクトが現れると思う理由です。

データベースツールにおいて特に重要な理由

私が最もよく知るカテゴリに焦点を当てましょう。より広いポイントを示していると思うからです。

データベースの管理パネル（データベースを見る、クエリを走らせる、テーブルを閲覧する、スキーマを管理するツール）は、ほぼすべてクラウドに移行しました。Webアプリにログインし、データベースに接続し、ブラウザ越しに作業します。Webアプリがあなたのデータベースに話しかけます。クエリはブラウザから相手のサーバー、あなたのデータベースへ、そして戻ります。

それが何を意味するか考えてみてください。本来2者であるべき道筋（あなたとデータベース）に、3者目を加えたのです。走らせるすべてのクエリが他人のサーバーを経由します。接続の認証情報がそのサーバーに保存されているかもしれません。クエリ履歴がそのサーバーに住んでいます。クエリの結果（顧客データ、財務記録、健康情報、何でも含むかもしれない）が、あなたに戻る途中でそのサーバーを経由します。

これがローカルファーストが反対するアーキテクチャであり、データベースの場合、議論は特に明確です。データベースはローカル（マシン上のSQLiteファイル）かもしれないしリモート（AWS上のPostgresインスタンス）かもしれないが、インターフェース（データベースとやり取りするもの）までがホスト型サービスである必要はありません。データベースに直接接続し、ローカルでクエリを走らせ、ローカルで結果を描画するデスクトップアプリは、すべてをSaaSバックエンド経由でルーティングするWebアプリよりもシンプルで、速く、プライベートで、堅牢です。

セキュリティ上の議論もあります。すべてのSaaSデータベースツールは潜在的な持ち出し点です。ツールが侵害されれば、攻撃者が顧客が接続したすべてのデータベースへのアクセスを得るかもしれません。このパターンは他のSaaSカテゴリでも見られています。接続情報をローカルに保存し、データベースに直接接続するローカルファーストのデスクトップツールは、その面を完全に取り除きます。中介者を侵害する余地はない、なぜなら仲介者がいないからです。

Webベースのデータベースツールが邪悪だとか役立たずだとは言いません。正当な理由があります。インストール不要、共有が簡単、デフォルトでクロスプラットフォーム。しかし「データベースツール＝Webアプリ」というデフォルトの前提は間違っており、シフトすると思います。Webアプリの便利さは、データベースのトラフィックをサードパーティに経由させる価値はなく、直接接続して即座に応答するローカルファーストのデータベースツールを使えば、Webアプリ版はストロー越しに作業するように感じます。

ツールが本当にローカルファーストかを見極める方法

「ローカルファースト」はマーケティング用語になりつつあり、それは希釈されることを意味します。少しのデータをローカルにキャッシュするプロダクトがローカルファーストと名乗るでしょう。読み取りのオフラインモードを持つプロダクトがローカルファーストと名乗るでしょう。だから、誰かがそのラベルを主張したときに使うチェックリストを、私が使い、皆さんにもお勧めするものを示します。

インターネットなしで動くか？ 「キャッシュされたデータを読めるか」ではありません。ネットワークを完全に切った状態で、ツールの中核のこと（作成、編集、保存）ができるか？答えが「閲覧はできるが編集はできない」や「編集はできるがオンラインになるまで保存されない」なら、それはローカルファーストではありません。オフライン耐性のあるクラウドファーストであり、ないよりは良いですが同じではありません。

データはアプリなしでアクセスできるフォーマットで保存されているか？ プレーンなファイル（Markdown、JSON、SQLite）が理想です。アプリしか読めない独自のローカルデータベースは、リモートサーバーよりは良いですが、完全なローカルファーストではありません。アプリが壊れフォーマットが未文書なら、立ち往生します。ゴールドスタンダードは、妥当なツールなら何でも開けるフォーマットのデータです。Markdown、CSV、SQLite、JSON。単一のアプリより長生きするフォーマットです。

会社が明日消えても、ツールをまだ使えるか？ これがサンセットテストです。会社がシャットダウンし、サーバーを削除し、存在を止めても、動くアプリとデータがまだあるか？真のローカルファーストアプリなら、答えはイエスです。失うのはアップデートと同期ですが、アプリとデータは残ります。オフラインキャッシュ付きのクラウドファーストアプリなら、答えはノーです。アプリは、もう存在しないサーバーのクライアントだからです。

クラウドはオプションか必須か？ 具体的には、クラウドは同期と共同作業（オプション、付加的）に使われるか、それとも認証とデータ保存（必須、基盤的）に使われるか？ログインしないとアプリが使えなければ、クラウドは必須です。認証はクラウドへの依存です。データがサーバーに保存されローカルコピーがキャッシュなら、クラウドは必須です。アカウントも接続もなしに完全に動くなら、クラウドはオプションです。

ツールは4つすべてを合格しなくても有用です。しかし4つすべてを合格するツールは、私がここで意味するローカルファーストであり、ローカルファーストと名乗りつつサンセットテストに不合格のツールは、その言葉をマーケティングとして使っています。

未来

ローカルファーストがクラウドSaaSを置き換えるとは思いません。それが主張ではありません。クラウドファーストは多くのものにとって正しいアーキテクチャです。データが本質的に共有されリアルタイムなもの（マルチプレイヤーゲーム、ライブダッシュボード、カスタマーサポートキュー）、計算がクライアントより重いもの（大規模分析、ML推論）、価値がネットワークにあるもの（マーケットプレイス、ソーシャルプラットフォーム）。これらではクラウドが機能ではなくプロダクトです。

しかし、大きくて過小対応のツールのカテゴリ（ノート、コードエディタ、データベース管理、ファイル管理、個人知識ベース、デザインツール、執筆ツール）にとって、ローカルファーストはより良いアーキテクチャです。これらはデータが主にあなたのもの、作業が主に単独または小チーム、中核の操作が本質的にローカル（テキストの編集、クエリの実行、ファイルの整理）、クラウドが基本能力を加えずに便利さを加えるツールです。これらのツールでは、すべてをサーバー経由にするのは理由のない税であり、ローカルファーストはその税を取り除きます。

ローカルファーストに対する歴史的な主な反論は同期でした。「ローカルファーストは単一ユーザーには素晴らしいが、共同作業やマルチデバイスが必要になった瞬間に崩れる」。その反論は2015年には妥当でした。今は妥当度が低いです。CRDTエコシステム（Automerge、Yjs、およびそれらを巡る成長するパターンの集合）が、小さなチームがオリジナルの分散システム研究をせずにリアルタイム共同作業付きのローカルファーストアプリを構築できるほど、同期を解決済みの問題にしています。インフラはコモディティ化しています。コスト曲線は曲がっています。

今後数年で、ローカルファーストがニッチな哲学からメインストリームのアーキテクチャの選択に移行すると思います。10年前にモバイルアプリで「オフラインファースト」がそうだったように。どこでもではなく、合うカテゴリで。そして今ローカルファーストのツールを採用するユーザーは、5年後にもまだデータを持っている人たちになると思います。データがマシンに、所有するフォーマットで、サーバーの許可なしに動くアプリにあったからです。

まあ、それが賭けです。クラウドは消えません。しかしすべてのツールが機能するためにサーバーを必要とするという考えは消えていきますし、今すぐでなくても早すぎることはありません。

まとめ

ローカルファーストを気にするべきです。あなたの仕事の所有者を変えるからです。クラウドファーストのソフトウェアは自分のデータへのアクセスを貸し、家主は家賃を上げ、立ち退かせ、建物を取り壊せます。ローカルファーストのソフトウェアはデータをマシンに、制御できるフォーマットで、誰かのサーバーが上がっていようがいまいが動くアプリに置きます。アクセスではなく、道具に課金します。

これはニッチな関心事ではありません。毎日使うツールに適用された、借りることと所有することの違いです。そして実用的になりつつあります。同期インフラは成熟し、ツールは良くなり、クラウド依存のコストは無視しにくくなっています。

データベースを扱うなら、これは二重に重要です。データベースツールはあなたとデータの間のもう一者であるべきではありません。直接の接続であるべきです。ローカルで、速く、プライベートで、あなたのもの。

basevolt.app で試してみてください — サインアップもクレジットカードも不要です。

これについて議論したい、あるいはローカルファーストな何かを構築していて意見を交換したいなら、X でフォローしてください。