mvc - サーバーはグローバルに必要なデータをレンダリングし、クライアントは React を使用してそれをレンダリングします。そのようなソリューションは実現可能ですか?

Question

React を使用した後、データから View をレンダリングするプロセスは比較的簡単です
しかし、より実用的なアプリケーションには、サーバーのサポート、マルチユーザー、リアルタイム同期などが必要です
既存の実践ではいくつかの問題に遭遇しました (私はバックエンド アーキテクチャにあまり精通していないので、フロントエンドの観点から考えています):

• ブラウザ側でデータをキャッシュする場合、外部データはサーバーからしかキャプチャできない場合があります、
  サーバーはブラウザがどのようなデータを必要としているかを常に知っているわけではありません

• ブラウザにはデータのバックアップがあり、手動で維持したり、サーバーで更新したりする必要があります。
  サーバーがデータをプッシュするときにも同様の操作が実行されるため、両側に重複したコードが存在します

そこで、プロセス全体をより明確かつシンプルにする解決策を考えています（小規模なアプリケーションの場合、パフォーマンスは最初に考慮されません）。

• データ操作はブラウザ側で実行され、すべての変更はサーバーによってプッシュされたデータに基づいて行われます

  つまり、ユーザーが必要とする完全なデータがサーバー上にあり、ブラウザは受動的に同期するだけです
  

• サーバーは、ブラウザがどのテーブルに移動したかなど、各ユーザーの現在のステータスをすべて保存します。

  このようにして、サーバーは現在のユーザーに必要なすべてのデータを計算できます
  

• クライアントのデータ関連アクションはすべてWebSocketを通じてサーバーに送信され、サーバーによって処理されます

  サーバーは、jsonpatch と WebSocket を通じてローカル データのバックアップを更新します
  

私はこのアイデアについて長い間考えてきましたが、まだ掘り下げ始めていません。そのような計画を考えているクラスメートはいますか?

また、私が検討しているシナリオは、数十人が同時にオンラインになる小規模なアプリケーションであることにも注意してください...

Answer 1

これが答えだと考えるべきではありません。ただ一緒に話し合ってみましょう。あなたが説明したことのいくつかを私は理解していないと思うので、私たちが同じ認識を持っているかどうかを確認するために最初に質問します:

ブラウザがデータをキャッシュする場合、外部データはサーバーからしか取得できない場合があり、サーバーはブラウザが必要とするデータを常に認識しているとは限りません

ちょっと待って、サーバーからデータを取得するときにリクエストのタイプを宣言する必要はありませんか?なぜサーバーはブラウザーが必要とするデータを「知る」必要があるのでしょうか?つまり、キャッシュされたデータに (たとえば) 「作成者情報」が欠落していると仮定すると、それは GET /author/:id はずですよね?これは、サーバーがブラウザーが必要とするデータを「常に知っているわけではない」ことをどのように意味するのでしょうか?意味を明確にするために例を挙げてもらえますか?

ブラウザにはデータのバックアップがあり、手動のメンテナンスやサーバーでの最新情報の維持などが必要です。サーバーがデータをプッシュするときにも同様の操作が実行されるため、両側に重複したコードが存在します

「プッシュ」とは、実際にはデータが更新されたことをブラウザは知らないが、サーバーは知っているので、サーバーが更新されたデータをブラウザにプッシュすることを意味すると思います。ブラウザーでデータを手動で保守するということは、データが変更されたことがわかっているため、データを手動で保守し、サーバーに送信してデータを同期する必要があることを意味します。

この二つはまさに対極であり、矛盾していないと思いませんか？コードが重複しているのはなぜですか?データの同期に使用されるコードのことを指しますか?

---

あなたが考えている解決策は次のとおりです:

データ操作はブラウザ側で実行され、すべての変更はサーバーによってプッシュされたデータに基づいて行われます
クライアントはデータをキャッシュしないということですか?データ変更操作がある限り、完全なデータがサーバーから即座に取得されます (つまり、ユーザーが操作を実行すると、データ更新が他のすべてのクライアントに即座にプッシュされます)。

...どのテーブルのどのデータ
私の理解が正しければ、あなたの言いたいことは、私がユーザー A で /author/5 のデータを見ていると仮定すると、次のことを示すカーソル メカニズムがサーバー上にあるはずです。「ユーザー A は、著者の ID 5 でデータを閲覧しています」テーブル」ですよね？言い換えれば、URL が変更されるたびに「現在の位置情報」がサーバーに送信され、サーバーが対応するデータをプッシュしてくれるということですか。

それでは...データを直接取得することとGET /author/5にはどのくらいの違いがあるのでしょうか?

---

あなたが説明したことについてあなた自身の考えがあることはわかりますが、その場面はまだ漠然としすぎていると思います。具体的なシナリオを例にして、どのような問題が解決されたのかを詳しく聞きたいのですが。

Answer 2

そしてサーバーはブラウザがどのようなデータを必要としているかを常に知っているわけではありません

サーバーとブラウザ間の通信は仕様に基づいている必要がありますバックエンドとフォントエンド間の通信はアプリケーション開発において非常に重要です

ブラウザにはデータのバックアップがあり、手動によるメンテナンスやサーバーの最新情報の維持などが必要です。

実際、ビジネスデータは最終的にサーバーに保存される必要があり、データベース（mysqlなど）はそのようなサービスを提供します。簡単に言えば、ブラウザのデータはサーバーとクライアントの間でやり取りされます。キャッシュの範囲は非常に広く、サーバーアプリケーション内のキャッシュだけでなく、last_modifiedやetagもキャッシュの1つです

繰り返されるコードに関しては、実際にはバックエンドとフォントエンドの間の明確な役割分担と技術的なアーキテクチャが原因であると考えられます。ただし、プロジェクトによっては、迅速に開始するためにコードの重複が許可される場合があります。後でゆっくりと再構築することができます。初期段階では、現在の技術レベルに基づいて選択することしかできず、技術に深入りしすぎて予定通りにプロジェクトを完了できなくなることは避けてください

データ操作はブラウザ側で実行され、すべての変更はサーバーによってプッシュされたデータに基づいて行われます
言い換えれば、ユーザーが必要とする完全なデータがサーバー上にあり、ブラウザは受動的に同期するだけです

アプリケーションはすべてこのようなもので、データは最終的にサーバーに配信されます。

サーバーは、ブラウザがどのテーブルに移動したかなど、各ユーザーの現在のステータスをすべて保存します。
このようにして、サーバーは現在のユーザーに必要なすべてのデータを計算できます

一般的に、サーバーはステートレスになるように設計されており、将来プロジェクトが開発される際にはサーバーの拡張が必要になります。ブラウザはデータが必要な場合、サーバーにアクセスしてデータを取得します。サーバーはブラウザから送信されたパラメータとインターフェイス プロトコルに従ってデータを提供し、ブラウザは現在のユーザーがどのテーブルと位置にいるかを簡単に知ることができます。たとえば、Sina Weibo Web サイトでは、ページの最後に到達すると、データが一定量に到達すると、次のページのリンクを使用してサーバーからデータを取得します。

クライアントのデータ関連アクションはすべて WebSocket 経由でサーバーに送信され、サーバーによって処理されます。 サーバーは、jsonpatch と WebSocket を通じてローカル データのバックアップを更新します

このテクノロジーの実装は主にアプリケーション シナリオに関連しており、Websocket はデータを取得するための長時間の接続に適しています。一般的にデータを更新するだけであれば、通常の http プロトコルを使用するだけで十分です。