Logux：接続が失われ、データが同期されました-Andrei Sitnik（Evil Martians）のインタビュー

インターネットがクライアント上で突然消えるとどうなりますか？ おそらく一瞬ですか、それともより具体的な期間でしょうか？ ユーザーとしての私たち全員は、不安定な信号、フローティング通信品質に直面しています。 面白いビデオを見たいので、それは重要ではないかもしれません。時には多くの人がそれに頼ることができます-列車の切符を買うか、同じインターネットの料金を支払う必要があると想像してください。



メディアなどのエンドユーザーが非常に重要な領域では、理由を理解せずにサイトを4秒以上開いた場合、すでに13％のユーザーが去っています。 ここで、まだコメントを送信しようとしているユーザーが、通信の問題のために常に「脱落」していると想像してみましょう。



撤退と失敗の割合は明らかに大きくなります。 これを避ける方法は？ データがクライアントとサーバーの両方から送信されることを保証する必要がある状況で何ができますか？



PostCSSの作成者でありAnd Evil Martiansの主要なフロントエンドであるAutoPrefixerのAndrey Sitnikは、この質問やその他の質問に答えます。



















-なぜコミュニケーションの問題について話しているのですか？ これは、単に物理的/ネットワーク機能に関連した質問ではありませんか？



-OSIはあまり話題ではありません。 LoguxはRESTとAJAXを置き換えます。 つまり、純粋に適用されるレベルです。 Loguxは次の問題を解決します。

1. 単純なクエリには多くのコードが必要になりました。
2. サーバーからのデータのライブ更新は、書くのがはるかに困難です。
3. 優れたオフラインサポートは一般に地獄を書いています。 ただし、「500 msオフライン」が常に存在するため、オフラインが常に必要です。これらはボタン上の一定のボタンです。

このため、Loguxはクライアントとサーバーの間に特別な仮想イベントチャネルを作成します。



クライアントはこのチャネルにイベントを入れることができます-Loguxは可能であればそれらを送信します。 サーバーにも同じことが言えます。 技術レベルで段階的に見ていきましょう。

デブリーフィング

1.クライアントでは、Redux APIを備えた1対1のライブラリになります（Reactには接続されていません。下位レベルのAPIがあります）。 同じ方法でアクションを作成します。 ただし、一部のアクションでは、同期キーを設定できます。true-Loguxはそれらをサーバー自体に配信します。 このライブラリはWebソケットを保持し、pingを送信して、接続があることを確認します。



「しかし、このライブラリがReactに結び付けられていないのは何が良いのでしょうか？」



すべての人がReactで開発するわけではありません（これはさまざまな環境に非常に適しています）。 誰かがVue.js、Angularを使用できます。 または、HTMLがないJSアプリケーションがあるだけなので、Reactはそれほど必要ありません。 どうぞ



2.追加のライブラリ。接続が失われた場合にスペシャルを表示します。 ページ上部の「接続なし」バッジはファビコンを変更します。 送信チャネルにイベントがあり、接続がない場合は、すべてのデータが保存されていないこともユーザーに通知します。



-なぜユーザーはこれを知っている必要がありますか？ これはどのような形式の相互作用にとって重要ですか？



-ユーザーからデータが提供された場合、それらが保存されていないことをユーザーに通知する必要があります。 この振る舞いがデフォルトであるべきだと思います。 ライブラリは、このような通知自体を記述し、それを設計により適切に統合するために、多くの点でオプションです。 ただし、Loguxを使用して分析のためのユーザーアクションを収集する場合など、通信の問題を表示できない場合もあります。



次のステップ。



3.接続が表示されると、Loguxクライアントとサーバーは、通信がないときに追加されたイベントを互いに送信します。



-それは明らかです、それは論理的です、いくつのアクションがキューに入れることができますか？



-通常、イベント10〜20。 ただし、厳密な制限はありません。クライアントとサーバーのメモリにどれだけ収まるかです。



-これらのイベントの順序は？



-イベントの順序は非常に厳密に制御されています。 ここでの問題は、1人のユーザーのイベントの順序だけではありません。 ただし、複数のユーザーが作業している場合でも、すべてのシステムですべてのイベントの順序が同じである必要があります（最終状態が同じになるように）。 そのため、Loguxでは、各イベントに作成時間が割り当てられます。 非常に注意が必要です。たとえば、クライアントとサーバーの時間差も考慮されます。



-一部のイベントを実行する必要がなくなるほどで​​はないでしょうか？ 相互アクションの依存関係チェック？



-クライアントは、不要なイベントからログを消去できます。 これはすでにビジネスロジックによって決定されています。



次のステップ：ユーザーはブラウザを閉じることができます-未送信のイベントはlocalStorageに保存されます。 ただし、未送信のデータがあるため、閉じる前にライブラリはユーザーに最初にオンラインにするよう要求します。



-再び容量と重要性の問題に戻りますが、ユーザーがブラウザを強制的に閉じるとどうなりますか？



-大丈夫です。 ユーザーが再びサイトに戻るとすぐに、データが送信されます。



残りのすべての手順：



5. Loguxサーバーを作成するための特別なサーバーフレームワークがあります。 つまり、express.jsのようなものです。 あなたは、サーバーがクライアントからの特定のイベントにどのように応答するかを自分で説明します。 同時に、ロジックは少し複雑です-イベントが到着したという事実は、それが今作成されたことを意味しません。 したがって、各イベントには作成時間があります。 接続時に、クライアントとサーバーは時差を決定し、クロック（および古いイベントの作成時間）を同期します。



6. node.jsのこれまでのサーバーフレームワーク。 その後、Elixir and Goでそれを行います。 ただし、Ruby、Python、PHPを使用できます。node.jsサーバーをプロキシとして配置するだけで、ソケットを保持できます。 そして、すでにこのプロキシサーバーは古いREST要求をrubyサーバーに送信します。



7.このイベントログと正確な時間があるため、Swarm.jsのようにその上にCRDTを作成し、多くの単純なケースで競合を自動的に解決できます。



8.一般に、ほとんどの場合、ひねりを描画しないことが可能です-クライアントは、イベントが既に完了した（たとえば、コメントが送信された）ようにすぐに描画できます。Loguxは、データがサーバーに保存されていないことをユーザーに表示します。 もちろん、これがうまくいかない場合もあります-例えば、支払い。 そこで、古いロジックをひねりながら実行できます。

Loguxと代替

-ありがとうございます。それから、Loguxは既存のソリューションよりも優れていますか？



-Relay / GraphQLがあります-データを照会するときのコードの量を減らします。 ただし、データ自体の変更も非常に簡単ではありません。 ライブアップデートの解決方法は不十分です。 オフラインもうまくいきません。



同型のデータベースがあります-それらはクライアントとサーバーで動作し、相互にデータを同期します。 たとえば、CouchDBおよびFirebase。 十分に決定されたライブデータの更新があります。 現在、CRDTの準備が整っている人はほとんどいませんが、一般的には実装できます。 しかし、拡張は非常に難しく、多くの開発者はこのような奇妙な同期方法を恐れているため、このようなデータベースは業界標準にはなりませんでした。



CRDTライブラリもあります-たとえば、Swarm.js。 LoguxはSwarm.jsから多くのアイデアをコピーします。 しかし、Swarm.jsはReactやEditorsと友達になりにくいです。 非CRDT操作を転送することも困難です。



-長所と短所は何ですか？



-少ないコード、すぐに使えるデータのライブ更新、アプリケーションをオフラインで簡単に動作させることができます。 そして、これらすべては、おなじみの編集上のセマンティクスを備えています。



主な弱点は、追加のサーバーを実行する必要があることです。 しかし、そのような決定にはすべてそれがあります。 さらに、このサーバーをプロキシサーバーにして、すべてのロジックをPHPまたはRuby on Railsに格納し続けることができます。



-この強調された決定の必要性はどこから来たのですか？



-Ampliferでは、パブリケーションのライブ統計を表示し、問題が発生したときにすぐにエラーでページを更新する必要がありました。 そして、良い解決策が見つからないことに気付きました。 Swarm.jsを実装しようとしましたが、簡単にデプロイできませんでした。 だから私はSwarm.jsと編集者を友達にする方法を考え始めました。 当時、ダンアブラモフはサンクトペテルブルクにいましたが、彼との会話の中で、別の図書館というアイデアが生まれました。



-これは業界標準になる可能性がありますか？



-LoguxをすべてのWebアプリケーションのユニバーサルソリューションとして作成しようとしています。 しかし、私には、2017年にはAJAX / RESTを作り直すための多くの試みが見られるようです-今、これはWeb開発の主な問題です、私の意見では。 この戦いに勝つのは2018年だけです。

人生の例

-1-2の興味深い実用的なケースはありますか？



-はい、TODO MVCでも-接続がなくても、タスクのリストを引き続き使用したいと思います。 または、コンピューターにタスクを追加した場合は、ページをリロードせずに、電話ですぐにタスクを表示したいでしょう。



またはコメント-FacebookやVKのようなライブアップデートは、人々を引き付けるのに役立ちます。



Loguxには、どのWebサイトにももう1つの利点があります-それは「楽観的なインターフェイス」です（ 別のHolyJSスピーカーはそれについて話していました）。 現在、すべてのアクションで、ユーザーに「ねじれ」を示しています。 保存するたびにインターフェイスがブロックされ、ユーザーフローが中断されます。 Loguxを使用すると、バックグラウンドで保存が行われる楽観的なインターフェイスを簡単に作成でき、エラーが実際に発生した場合にのみユーザーの注意をそらすことができます。 たとえば、これがGoogle Inboxの仕組みです。 ユーザーは常に高速なインターフェースを好むため、どのWebアプリケーションでも楽観的なインターフェースの恩恵を受けるでしょう。



-インタビューしてくれてありがとう、そして会議で会いましょう。

---

もちろん、インタビューでは、ライブラリとその哲学の一般的な見解のみを議論することができました; HolyJS Andreiでは、 Loguxの開発と作業に関する詳細な1時間ごとのレポートを提供します。 さらに、議論されている他のテクノロジーに関するレポートをすぐに見ることができます。

• 白鳥のガンとパイク：テクノロジーがどのようにフロントエンドを下に引き寄せるか
• エルムとフロントエンドの至福に少し近づく