なぜLinearはこれほど爆速なのか？技術的な裏側を徹底解剖

プロジェクト管理ツールの「Linear」が、なぜあそこまでサクサク快適に動作するのか気になりませんか？この記事では、驚異的なパフォーマンスを実現しているLinearの技術的アプローチを深掘りし、その秘密を明らかにします。

ブログ投稿の要点は要するに、クライアント側で変更を加えて、うまくいったと仮定してバックグラウンドで保存する、ということだね。

こういうローカルファーストな同期Webアプリは本当に面白いし、すごく役に立つこともあるけど、前提が少し間違っている気がする。

「Linearでイシューを更新するのにかかるのは数ミリ秒。同じことをする従来のCRUDアプリだと300msくらいかかる」
「クライアントとサーバー間でやり取りされるデータには数百ミリ秒のコストがかかる」

光速に起因するHTTPクライアントとサーバー間の大きなRTT（往復時間）の問題は解決しようがない。

でも、バックエンドをユーザーの近くに配置して高速化することはできるよ。

例えば、ほとんどのユーザーに対してRTT約10ms以内でWebアプリのバックエンドを動かし、バックエンドのレスポンスも約10ms以内で返すことは十分に可能だ。

つまり、同じ操作が300msではなく30ms程度で完了するような、従来のCRUDアプリを作ることは間違いなくできるはず。

去年、ある人がLinearの同期エンジンをリバースエンジニアリングして、カッコいい解説付きでGitHubに公開していたよ。
https://github.com/wzhudev/reverse-linear-sync-engine/blob/m... (https://github.com/wzhudev/reverse-linear-sync-engine/blob/main/SUMMARY.md)

結果整合性のあるデータベースを書くのは難しい。Linearのユースケースならいいかもしれないけど、自分の更新がサーバー（つまりチーム）に反映されたかどうかわからないのは問題だ。これまで関わったプロジェクトで同期のラグが原因で数え切れないほどのトラブルを見てきたから、自分は常に同期的なソリューションを選ぶようにしている。凝った仕組みなんて、どうしても必要な時以外は持ち込まない。ユーザーにはネットワーク遅延を「我慢」してもらう方がいいし、その分サーバーを爆速に最適化したいね。

これは面白いね。正直なところ、Linearを「速い」と思ったことは一度もない。ほとんどのWebアプリと同じくらい遅延があるように見えたけど、JIRAと比べればもちろん爆速だ。ただLinear自体は素晴らしいし、JIRAの拷問から解放されるのは本当に新鮮だよ。

楽観的更新ルートと「速さ」の話をするなら、まずはGmailの話から始めるべきじゃないかな？

職場ではLinearを使っているよ。少数派なのは間違いないけど、自分はUXにかなり苦労してる。速いとも思わないし。確かにページ自体はそこそこ速くロードされるけど、データが読み込み中だという視覚的なインジケーターがないまま、ページ上の数字だけが書き換わっているのを半分くらいの頻度で見かけるよ。

Linearは速いっていう話をずっと聞いてたけど、実際に毎日使うようになって熱が冷めちゃった。検索はかなり遅いし、UIもしばしばカクつく（見た目はいいんだけど）。「Pulse」は小規模でもノイズの洪水だし、必要なものを見つけるのに苦労して、結局全部お気に入りに入れるハメになっている。

初期のTrelloがダントツで最高のプロジェクト管理ツールだったな。

スピードの答えはプリロードにある。基本的には初期化時にクライアントDBをダウンロードして、あとはキャッシュ無効化戦略を持つことだね。自分はまさにこのパラダイムにおけるデータ同期の部分を実行するためにstarfxを作ったよ。 https://starfx.bower.sh/learn#data-loading-strategy-stale-wh... (https://starfx.bower.sh/learn#data-loading-strategy-stale-while-revalidate)

Linearは、本来ならこうした最適化を必要としない種類のアプリに見える。インデックス作成のためにローカルにDBコピーを持つのは理解できるけど、通常のトランザクションには不要だろう。このアプリは、バックエンドで普通にスケールしそうなアプリの例に見えるよ。単一のイシューに対する同時書き込みは本来珍しいことだし、大規模顧客向けにシャーディングが必要なら、かなりうまく分割できるはずだ。

このアプリの何がバックエンドで数ミリ秒以上を必要とするのか、そしてローカルコピーがどうやってそれを改善するのかがわからない。ローカルコピーを持つことで、かえって不整合が起きるんじゃないかな（もし起きないなら、バックエンドだって同じくらい速いはずだしね！）。

もしIndexedDBを内部で使っているなら、あれは最初の書き込みが異常に遅くて、2回目以降のロードはすごく速い。データを読み込むなら、IndexedDBに入れる前にまず別の方法でロードしないと高速化はできないね。

LinearはminifyされたJSで21MBもあるけど、これはあまりに重すぎる。自分は最近、読み取り専用データベースが必要な辞書系PWAを作ったんだけど、zstd圧縮を完備したシンプルなシステムを自作して、わずか38KBのWASMモジュールに収めたよ。