3

私が遭遇するほとんどの例は、常に URL からデータを取得しているようです。

しかし、サーバー側では、データベースから直接データをフェッチするのは意味がありませんか?

したがって、アクション作成者では次のようになります。

if(typeof document !== 'undefined')
  fetch("url/posts").then(response => dispatch(receivedPosts(response))
else
  db.select("posts").then(response => dispatch(receivedPosts(response))

他のデータ取得方法と比較して、この方法の長所と短所は何ですか?

4

1 に答える 1

2

ほとんどの React/Redux アプリケーションは、API 開発と UI 開発が分離された環境で構築されています。多くの場合、これらの同じ API は他のデスクトップ アプリと同様にモバイル アプリにも使用されます。そのため、サーバー側のレンダリングでは、お見せしたような直接の db クエリを使用できません。

あなたの場合、単一のコードベースでフルスタックアプリを構築しているようです。それは必ずしも悪いことではありませんが、おそらく考慮すべき点がいくつかあります。最初に、アプリケーションのライフサイクルを確立します。スタックの詳細を学ぶために行われる楽しい小さなサイド プロジェクト、市場への MVP を獲得するために競争するスタートアップ、およびゲートをスケールアウトする必要があるプラットフォームを構築する大企業の間には大きな違いがあります。これらのシナリオごとに、アプリの層を設計する方法についてさまざまな考慮事項が生じる可能性があります。作業内容に固有の重要な質問の 1 つは、他のアプリ/プラットフォームがこの同じデータにアクセスする必要があるかどうか、および別のチームが最終的にバックエンドとフロントエンドを維持する可能性があるかどうかです。node と mongo で 最初はReactアプリにサービスを提供するAPIエンドポイントを作成するのは非常に簡単ですが、後でネイティブIOSアプリで使用できます. また、アプリのメンテナンスと機能強化における関心の分離の利点も得られます。多くの場合、データ アクセスと UI ロジックが完全に分離されていると、API を postman などで直接呼び出して、API が正しいデータを提供しているかどうかを識別できるため、デバッグが容易になります。

あなたの場合、既に /posts から API データを提供しているように見えるので、私が言及したすべての利点を潜在的に得ることができますが、コード スニペットが示唆するように API をバイパスすることでネットワーク ホップをスキップすることもできます。これにより、サーバー レンダリングの障害点が 1 つ少なくなり、速度が少し速くなりますが、おそらく速度はあまり向上せず、API にネットワークの問題がある場合、API のクライアント側にすぐに表示されます。アプリなので、メリットはあまりありません。

個人的には、React アプリでフェッチ呼び出しを行い、すべてのデータ アクセス/API ロジックを分離して、バックエンドとフロントエンドを 2 つの個別のリポジトリに移動しても、将来的にそれほど苦痛にならないようにします。これにより、アプリは将来の潜在的な成長に適した場所に置かれます。懸念事項の分離の利点は、わずかなパフォーマンスの低下よりも重要です。ページの読み込みが遅い場合は、多くの場合、db クエリ自体から始めて、調整する場所が多数ある可能性があります。

于 2016-08-08T05:18:38.253 に答える