ステロイドの聖杯：Swarm.jsの完全同期と同形JavaScript

今日、Habréでは、複製されたモデルのテクノロジーを紹介します。これにより、ローカルデスクトップアプリケーションと同じくらい簡単に、コラボレーションおよびリアルタイムのWebアプリケーションを作成できます。 アプリケーションを開発するとき、リアルタイムのデータ同期は、TCPストリーム、HTTPリクエスト、またはソケットからの電流と同じ方法で、即座に、そして間違いなく利用できるはずだと考えています。 Swarmで記述されたHTML5アプリケーションは、自律性、ローカリティ、ダウンロード速度の点で、ネイティブのものより劣りません。

Swarmライブラリを使用すると、1か月間にSwarmを使用しなかった場合よりも週末に多くのことができます。 さらに重要なことは、それなしではできなかったことを実行できることです。 この同期ライブラリは無料で提供しています。







本日、Swarm + Reactで 記述された反応性HolyGrail -on-steroidsアプリケーションであるTodoMVC ++を投稿します。 以下は、アプリケーションで示されている機能のリストです。

• インスタントロード-ページはサーバー上でレンダリングされ、圧縮されたHTMLとしてクライアントに届きます。 次に、コードとデータが取得され、ページが活気づきます。 動作中の同形JavaScript 。
• WebStorageのデータキャッシュ-作業結果を失うことなく、読み込みを高速化し、オフラインで作業することができます。
• オフライン作業-データはすでに明確になっていますが、キャッシュマニフェストを追加すると、HTML5アプリケーションはインターネットなしでロードして動作できます！
• リアルタイム同期-いくつかのブックマークを開く（WebStorageを介した同期）か、携帯電話/ iPad /他のブラウザー（WebSocket）で同じページを開きます。
• 複雑に同期されたデータ構造（はい、それはcomplex-syn-chro-ni-zi-ru-e-we-eです）。

一般に、アプリケーションは、単純な（ローカル）MVCアプリケーションとして、ネットワークへの参照なしで記述されます。 同期とキャッシングはSwarmライブラリレベルで完全に行われ、アプリケーションはモデルのローカルバックボーンのようなオブジェクトで動作します。



そのため、ここにアプリケーション自体があります： ppyr.us。

コードは次のとおりです。github.com / gritzko / todomvc-swarm



アプリケーションとライブラリの詳細な分析は次の資料にありますが、現在、レプリカ、CRDT、および理論的根拠に関する多くの手紙があります。



現在、クライアントとサーバーの両方で同期が強く求められています。 インターネット大手のサーバーエコノミーでは、同期を必要とするさまざまなストレージとデータ処理ツールがますます増えています。 真実の源としての1つの大きなデータベースの原則は、拡張が困難です。 しかし、私たちは主にクライアントについて話している。 今日、一般ユーザーは多くのデバイスを持っています。 ノートパソコンの画面に表示されるデータがiPhoneの画面に表示されるデータと一致しない場合、ユーザーは動揺します。 レプリカの同期はどこでも必要であり、データ同期システム（SD）はすぐにデータベースと同じ消費財になると考えています。



現在の詳細は、業界のリーダーでさえ、同期の決定を「作業の種類」段階までしか完了していないことです。 GDocsはオフラインではまったく機能せず、GTalkとSkypeは体系的にチャット履歴からレプリカを失います。Evernoteはさまざまなバグで有名です。 そして、これらはリーダーです。 一般に、同期の問題は驚くほど複雑で多面的です。 Evernoteをお試しください。 Evernoteがローカルアプリケーションの場合、学生は80/20サブセットを作成できます。 彼がMySQLとPHPを持っているように、Zuckerbergはfacebookを書きました。



同期の基本的な複雑さは何ですか？ 古典的な複製および同期テクノロジーの仕組み、レプリカIDのサポート方法を理解しましょう。 最も簡単な方法は、すべてをセンターで行うことです。 すべての書き込み操作は中央のデータベースに集まり、読み取り操作の新しい結果はセンターから戻ります。 信頼性が高くシンプルなように見えますが、すぐに3つの側面から困難に近づき始めます。

1. 同時実行性-前の操作に対する答えがオンになっている間、クライアントは別のことを何とかして、それをどのように組み合わせるかはもはや明確ではありませんが、
2. すべての操作が1つのポイントを経由するスキームのスケーリング
3. センターが顧客に応答しないか、応答が遅い場合、インターネットが不十分な状態で機能する。

このスキームをスケーリングする最初の典型的なステップは、 典型的な データベースに 実装されているマスタースレーブ複製です。 マスターは操作を線形ログに入れ、このログをスレーブに配布し、スレーブは同じ線形順序でデータレプリカに適用し、同じ結果を取得します。 これは読み取り値のスケーリングに役立ちますが、最終的な整合性要素を追加します。 スレーブは若干の遅れを伴って更新されます。 記録の問題は残ります-すべての記録は同じセンターを通過します。 線形化は、 PaxosやRaftなどのコンセンサスアルゴリズムを使用して分散レプリカに拡張できますが、線形化は「リーダー」、つまり すべて同じセンター。 センターが閉じられると、水平方向に拡大し始めます-ベースを「破片」に切断します。 ここで、線形化とACID全体が、千の小さなACIDに引き裂かれます。



まあ、オフライン作業では、センターと線形化の互換性がありません。 もちろん、オフラインは「もうすぐではない」と言うことができますが、実際には、オフラインは定期的に発生します。 私たちがツイートしたり、何かが好きなら、これは容認できますし、何かがより深刻な場合、それはほとんどありません。 たとえば、ウェイターが電線を蹴り、インターネットが消えた場合、管理者がライトを点滅させて車で到着するまで顧客をレストランから追い出すことはできず、無料でサービスを提供することもできません（ IIKO共同設立者のMax Nalskyの例）。



さらに、サーバー側でのこれらの冒険はすべてクライアント側に影響しません。 クライアントは、サーバーが互いに同意し、結果を報告するまで単に待機します。 悪名高いプロジェクトで、 Meteorはリアルタイムでクライアントの同期を試み、実際にMongoDBをクライアントにキャッシュしました。 すべてを鮮明に機能させるために、サーバーの応答を待つことは「レイテンシー補正」のトリックによって隠されていました。 クライアントは操作をキャッシュにロールしてサーバーに送信し、サーバーは正常に適用されたかどうかを確認し、適用されていない場合はパッチを送信します。 このアプローチは疑わしい以上のものです。 「-ルシャ、車をガレージに入れましたか？」 「はい、部分的に！」



ここに、線形化を伴うこのような複雑な話があります。 さて、より興味深いのは、線形化のスコアが付けられている一般的なソリューションを調べることです。 GitとCouchDBの2つの良い例があります。 GitはLinus Torvaldsによって書かれました。LinusTorvaldsはLinux開発者の中でまさに「中心」でした。 これがおそらく彼が中心がゆっくりであり、中心が拡大縮小しないと非常に感じた理由です。 gitでは、マスターとマスターの原則に基づいて同期が行われます。 データはバージョンのダイグラフとして表示され、すべての並列バージョンはいつかマージする必要があります。 スケーリング-完璧、オフライン-問題ありません。 CouchDBでもほぼ同じです。 クライアントにCouchDBのようなロジックをもたらす試みがあります-pouchdbとhood.ie。



この分野で完全に新しいものはCRDTであり、今日私たちはそれについて話している、長い導入についてすみません。 CRDTは、収束/可換/クラウドレプリケートデータ型です。 CRDTの一般的な考え方は、線形化の代わりに半順序を使用することです。 操作は多くのレプリカで並行して実行でき、一部の操作は競争力があります。 異なるレプリカで発生し、お互いを知らず、そのうちの1つが「最初」ではなく、異なるレプリカで異なる順序で適用されます。 使用されるデータ構造が、因果関係に違反しない操作のこのような簡単な並べ替えに耐えることができる場合、センターに関連するすべての問題は単純に解消されます。



もう1つの質問は、CRDTデータ構造がいくつあるかということです。 結局のところ、コンピューティング消費財全体-変数、配列、連想配列-は、CRDTの形で非常に実現可能です。 そして、お金を数えると？ 次に、線形化とACIDの保証がまさに必要ですか？ 残念ながら、新しいものは忘れられた古いものであることが判明しました。 会計で使用されるデータ構造-勘定、残高-は非常にCRDTであることがわかりました。 確かに、ルネサンス期に会計の伝統が形成されたとき、インターネットは存在しなかったため、線形化なしで抜け出しました。



CRDTの素晴らしい放射機能は、センターに接続されていなくても完全に機能するライブレプリカです。 まあ、センターに走ることなく、すべての操作の即時適用。 このような自律性と速度は、2つの場合に特に関連します。 まず、モバイルデバイス用-信頼性の低いインターネットで、外出先で使用されます。 CRDTを使用すると、将来の使用に備えてデータを保存し、バックグラウンドで同期してローカルで静かに作業できます。 第二に、特にリアルタイムでのコラボレーション機能を備えたアプリケーションの場合（Google Docs、Apple iCloudについて考えます）。 このようなアプリケーションでは、「状態」は大きく、急速に変化します。サーバーへの実行とその逆は、coの中の釘です。



データをオフラインで操作できる非CRDTテクノロジーがあります。 Dropboxはその同期APIを提供します。StrongLoop 、 Firebaseなど、などがあります。 これらのすべてのソリューションは、Last-Write-Wins（LWW）の原則に基づいて動作します。各レコードにはタイムスタンプが割り当てられ、大きなマークを持つレコードは前のレコードをミルします。 Cassandraは同じ原理に基づいています。 そして、私たちのSwarmライブラリで、最も一般的なプリミティブはLWWオブジェクトです。 Swarmの利点は、LWWで解決できないデータ構造です。 たとえば、編集中のテキスト。



一般に、分散システムのLooking Glassでは、逆のことが当てはまります。 通常のプログラミング言語では、最も単純な操作は変数の増分++です。 配列の操作は少し難しく、オブジェクトと連想コレクションはさらに複雑です。 分散システムでは、すべてが正反対です！ LWWオブジェクトと連想コンテナは特に複雑ではありません。 線形構造（配列、テキスト）は非常に複雑で、カウンターは非常に複雑です。 これは、LWWオブジェクトが最初に行われたCassandraの例で見ることができ、カウンターは、そのままで、まだ完了しています。







ポイントに到達します。 ライブラリの動作を示すために、Swarm + ReactでTodoMVCを作成することにしました。 実際、Swarm + Reactの最初のTodoMVCは7月にAndrei Poppによって1日以内に書かれましたが、そのコードは「 イディオマティック 」ではありませんでした。 今回は、線形コレクション（ Vector ）、サーバーレンダリング、たくさんのグッズを追加しました。 さらに、通常のTodoMVCは少し退屈で役に立たないように思えました。 たとえば、React + flux TodoMVCを見ると、著者が単純なアプリケーションでこれらすべてのトリックをだましている理由を理解することは非常に困難です。 したがって、1つの機能-再帰性を追加しました。 Tabキーを押すと、ユーザーはネストされた「子」リストに移動します。 また、インターフェイスをリアルタイム同期に適合させました。 そのようなアプリケーションは、すでに少なくともいくつかの実際的な利点を表しています。 また、ユーザー間で簡単に共有できるように、URLにアプリケーションのステータスを表示し始めました。 一般的に、止めることは困難でした。 過去のリアルタイムプロジェクトの開発と比較して、Swarmの人にはある種の剣の宝庫があり、いつも他の人を噛むために手がかゆいものがありました。



アプリケーションとライブラリの詳細な分析は、次の資料にあります。



@swarm_jsプロジェクトtwitterのアップデートをフォローしてください。