Local-first software
https://www.inkandswitch.com/essay/local-first/
pdf: https://www.inkandswitch.com/essay/local-first/local-first.pdf
見つけたYudai.icon*2
ちゃんとこういうドキュメントがあったんだ....
同僚とのリアルタイム共同作業を可能にし、あらゆるデバイスから仕事に簡単にアクセスできるため人気があります。しかし、データ保存をサーバーに集中させることで、クラウドアプリはユーザーから所有権と主体性も奪います。サービスが停止すればソフトウェアは機能しなくなり、そのソフトウェアで作成したデータは失われます。
既存のデータ保存・共有手法(メール添付からウェブアプリ、Firebase基盤のモバイルアプリまで)を調査し、各手法のトレードオフを検討する。特に「競合のない複製データ型(CRDTs)」に注目する。CRDTsは根本的にローカルかつプライベートでありながら、設計段階からマルチユーザー対応を実現するデータ構造である。CRDTsはローカルファーストソフトウェア実現の基盤技術となり得る。
ここでCRDTが出てくる!!Yudai.icon
「クラウドなんて存在しない、ただの他人のコンピューターだ」
データが「他人のコンピューター」に保存される場合、その第三者はデータに対する一定の支配権を握ります。クラウドアプリはサービスとして提供されます。サービスが利用不可になれば、ソフトウェアは使えず、そのソフトウェアで作成したデータにもアクセスできなくなります。サービスが終了した場合、データをエクスポートできる可能性はあっても、サーバーがなければ通常、そのソフトウェアのコピーを自分で実行し続ける方法はありません。
良い表現やねYudai.icon
ローカルファーストソフトウェアの7つの理想
No spinners: your work at your fingertips
クラウドアプリではデータの主コピーがサーバー上にあるためデータ変更や多くのデータ検索にサーバーとの往復通信が必要
ローカルファーストは、リクエスト完了を待つ必要がない
全ての操作はローカルディスク上のファイル読み書きで処理可能であり、他デバイスとのデータ同期はバックグランドで静かに行われる
Your work is not trapped on one device
ローカルファーストのアプリが各デバイスのローカルストレージにデータを保持する一方で、ユーザーが作業を行う全てのデバイス間でそのデータを同期させる必要がある
The network is optional
クラウドアプリは通常オンラインでは機能しない
ローカルファーストアプリケーションでは各デバイスのローカルファイルシステムに保存するため、オフライン時でもいつでもこのデータの読み書きが可能
ネットワーク接続が可能になった時点で他のデバイスと同期する
4. Seamless collaboration with your colleagues
複数人が同一ファイルを編集すると問題が生じる
競合が発生するケースが多々ある
クラウドアプリではリラ流タイム共同作業を当然のものとして期待するようになった
ローカルファーストアプリでは多様なコラボレーションワークフローをサポートできるはず
The Long Now
データ所有権の重要な側面は将来にわたって超危機感データにアクセスし続けられること
ローカルファーストウェアで作業を行う場合、ソフトウェアを開発した企業が消滅した後も作業成果は永久にアクセス可能であり続けるべき
「昔ながらの」アプリは実行手段があれば動作し続ける
クラウドアプリはサービスの継続的な利用可能性に依存する
Security and privacy by default
クラウドアプリのアーキテクチャの問題点の1つは全ユーザーのデータを中央集権的なデータベースに保存すること
不正な従業員や企業のサーバーへのアクセス権を得たハッカーが全データを読み取り改竄できる
You retain ultimate ownership and control
所有権の明確化
ユーザー主体性、自律性、データの対する管理権という意味
ユーザーはデータを自由にコピー、修正し、思考を書き留めるべきであり、企業がユーザーの行動を制限するべきではない
知見:
CRDT技術は機能する
チーム内のアプリ開発者は比較的容易にライブラリを統合でき、データの自動マージはほぼ常にシームレスだった
オフライン作業のユーザー体験は素晴らしい
任意の時間作業を継続した後、再接続してどう量と変更をマージするプロセスは良好に機能した
開発者体験は関数型リアクティブプログラミングと組み合わせることで実現可能
ReactのFPRはCRDTと相性が良い
コンフリクトは当初懸念したほど深刻な問題ではなかった
アプリケーション固有の競合解決メカニズムが必要だと想定する
ユーザーが他者と共同作業中に競合に遭遇するのは驚くほど稀で、汎用tきなメカニズムが十分に機能する
オートマージは変更を些細なレベルで追跡し、データ型の意味論を考慮する
人間同士の共同作業は直感的な感覚があり、共同作業者との競合を避ける傾向にある
文書履歴の可視化は重要
ローカルファースト型アプリケーションは問題に対する独自の解決策を見出す必要がある
URLは共有に適した仕組み
URLはコピー&ペーストが可能で、通信チャンネルで共有できる
Peer to Peer systemは完全にオンラインまたはオフラインになることはなくデータがどのように移動するかを推論するのは困難である
分散システムではデータは万華鏡のような複雑性を帯びる
他のユーザーは自身の文書バージョンに対し、その変更を全て・一部・全く反映しない選択が可能
CRDTは膨大な変更履歴を蓄積するため、パフォーマンス問題を引き起こす
CRDTは文字単位のテキスト編集を含む全履歴を保存するため、パフォーマンスとメモリ/ディスク使用量が急速に問題となる
ネットワーク通信は未解決の問題
異なるユーザーの編集が同一物理コンピュータに到達する方法を規定していない
クラウドサーバーは、発見、バックアップ、バーストコンピューティングにおいて依然として役割を持つ
ユーザーが文書を共有した後、他のユーザーが接続する前にノートパソコンの蓋を閉じてしまう状況を引き起こす可能性がある
サーバーとしての役割はクラウドピアとして。
他の役割:
アーカイブ、バックアップ
従来のサーバーAPIへのブリッジ
バーストコンピューティングリソースの提供者
サーバーは真実の源ではなく、支援的な役割を担う