【勝手翻訳】Linearは私をローカルファーストのウサギの穴に導いた

Linear sent me down a local-first rabbit hole | Bytemash の記事が興味深ったので、少しまとめました。

動機

Linearは信じられないほど高速なプロジェクト管理ツールで、ネットワークの遅延はどこにあるのでしょうか？競合はどのように処理されているのでしょうか？オフラインになるとどうなるのでしょうか？と疑問に感じて調べたそうです。

簡単に言うと、彼らはブラウザのIndexedDBを実際のデータベースとして扱う独自の同期エンジンを構築しました。すべての変更はまずローカルで行われ、その後バックグラウンドでGraphQLによる変更とWebsocketによる同期が行われているそうです。

データベースをクライアントに移動することで、ユーザーインタラクションパスにおけるネットワーク遅延が排除されることです。更新はローカルデータベースの読み取り/書き込みのみなので、瞬時に実行されます。

Linearのアプローチを理解した後、私の最初の直感は似たようなものを作ることでした。しかし、現実が突きつけられました。彼らの同期エンジンの基本バージョンでさえ、おそらく数ヶ月のエンジニアリング作業が必要だったのです。

複雑さの原因は次のとおりです。

幸いなことに、地域を第一に考えるコミュニティが解決策を構築してきました。現在の状況は次のとおり調査したそうです。

Jazz と Zod で構築されたスキーマから始めます。これらが単なる型定義ではなく、自動的に同期するライブで反応的なオブジェクトである点です。APIルートも、リクエスト/レスポンスのサイクルも、DTOもありません。ただ…魔法のように同期するオブジェクトだけ。

ローカルファーストを調べ、Jazz を試した後、このパラダイムがどのような場合に適するかについて次のような印象を受けました。

ローカルファーストは、アプリケーション構築方法に根本的な変化をもたらします。ユーザーエクスペリエンスのメリットは紛れもなく、Linearがそれを証明しました。問題は、アーキテクチャ上のトレードオフが、あなたのユースケースにとって価値があるかどうかです。

これらのトレードオフを実際に理解するために、Jazzを使って個人用アプリケーションを開発しています。開発体験は驚くほど新鮮ですが、抽象化が漏れている箇所を注意深く見守っています。

エコシステムはまだ若い。ツールは成熟し、パターンが生まれ、鋭いエッジは滑らかになるだろう。しかし、データをローカルに保つことでユーザーエクスペリエンスを劇的に向上させることができるという、核となる洞察は消えることはない。

何か新しいものを構築していて、制約内で作業できる場合は、ローカルファーストを試してみることをお勧めします。最悪のケースでは、新しいアーキテクチャパターンを習得することになります。最良のケースでは、ユーザーにとって信じられないほど高速に感じられるものを構築できるでしょう。

応答時間が 300 ミリ秒の世界では、これは利点となります。

ブラウザのIndexedDBにデータを持たせて、ユーザー体験を素早いものにしつつ、サーバ側/クラウド側に裏で同期して、整合性を持たせる。というアーキテクチャは今後増えていきそうですね。