このシナリオでは、データ変換はフロントエンドとバックエンドのどちらで行う必要がありますか？
Json形式のデータがあるとします。 Json形式は次のとおりです。
{title,
resources[] }
リソース配列には、グラフに関する情報が含まれています。しかし、それは繰り返され、異なるフォーマットに変換されるべきです。
問題
リソース配列のサイズが100の場合、変換がフロントエンドで行われるためには問題がなく、妥当である必要があります。リソース配列のサイズがはるかに大きい場合はどうですか？バックエンドで反復とデータのある形式から別の形式への変換が発生するしきい値がありますか？
変換の責任をフロントエンドに移すことにはかなりの理由がありますが、これがスケーリングするかどうかは疑問です。
補足質問
この変換が存在する必要がある私の決定の主な軸は何ですか？私はいくつかの回答 here および here を見つけましたが、これらは良い回答でしたが、さらにいくつかの確かな引数を使用することができました。
フロントエンドまたはバックエンドで変換を実行するかどうかの決定は、変換に関係するアイテムの数ではなく、実行する変換の種類に大きく依存する必要があります。
answer by @Ewan で述べたように、ユーザーが低電力デバイスを使用してアプリケーションにアクセスすることがわかっている場合を除いて、ユーザーは、ほとんどすべての変換を実行するのに十分な処理能力を持っています。
一方、変換に機密データの削除が含まれる場合、それは実際にはバックエンドで行う必要があります。
また、変換によってデータ量が大幅に減少する場合は、バックエンドで実行して、必要なネットワーク帯域幅を削減することをお勧めします。
データの変換は、それ自体が本格的な機能です。実際、すべてのソフトウェアがデータを変換することだけであると主張することができます。私たちが話していることは、フロントエンドが提供するものをバックエンドが必要とするものに変換することだと思います。
フロントエンドがサイズ100の配列を処理できると言ってパフォーマンスポイントを設定します。これは知っておくと良いですが、呼び出しを行うのに十分な情報がまだ不足しています。バックエンドがサイズx（yの同時ユーザー）の配列を処理できるという別のパフォーマンスポイントが必要です。
その情報を使用して、システムの全体的な容量を増やす決定を下すことができます。それがなければ、私たちは教義を握って希望しているだけです。
もちろん、操縦するための良い目標を与える良い教義がありますが、あなたの質問はパフォーマンスがあなたの主な関心事であることを示しているので、私は何について考えることをやめ、どれだけ集中するかを勧めます。
それを答えて、パフォーマンスを追求することで設計にどのようなコストがかかったかを調べてください。理由があるので、これらの教義があります。 Ewanは、ユーザーに作業負荷をかける十分な理由があります。 yが大きいときは、それは本当に正当な理由です。しかし、コストにはさまざまな形があります。可読性と柔軟性の欠如は、開発者の時間を浪費し、データセンターのコストを簡単に上回ります。セキュリティの喪失は会社に損害を与える可能性があります。
これまでに書かれた成功したコードのすべての部分は妥協です。理想に沿うものを見たことがない。必死に理想を必要とする悪夢を見てきました。これらの理想を隠す言い訳としてパフォーマンスを使用しないでください。
どこでデータを変換しますか？
データ変換はフロントエンドで行うべきですか、それともバックエンドで行うべきですか？
質問は、少し無意味であるか、少なくとも特定の必要な検討事項については曖昧です。変換は、変換が最も適切な場所で行われます。それは簡単な答えですが、「適切」なものを検討する方法の背後に隠されている多くの情報があります。
フロントエンドは、バックエンドが公開するAPIによってバインドされます。したがって、フロントエンドがバックエンドが予期するものとは異なる構造でデータを保持している場合、フロントエンドがそのデータを変換する必要があることは避けられません。
フロントエンドとバックエンドの両方の開発者として、フロントエンドとバックエンドの間の線を濁らせ、（通常の）逆ではなくフロントエンドに合うようにバックエンドの構築を開始する傾向があります。
私はここで包括的ステートメントを作成することに抵抗がありますが、私見では、一般に、後ろから前へ作業する方が良い方法です。つまり、バックエンドに独自の考慮事項に基づいてAPIを定義させ、フロントエンドを作成します。 。
フロントエンドがバックエンドAPIのデータ構造に完全に依存しているか、追加のフロントエンドDTOを実装しているかは、状況に応じた考慮事項です。たとえば、SPAは通常、独自の抽象化レイヤーを備えていますが、単純化されたレポートツール（事前定義されたバックエンドクエリに基づく）は通常備えていません。
フロントエンドがすでに開発されていて、フロントエンドのデータ構造が実際にバックエンドで使用できる場合、同じ構造を実装するバックエンドに問題はないことに注意してください。
ただし、フロントエンドがデータ構造を変更したためにバックエンドAPIを常に書き換えている場合、それは間違っています。
データを変換する必要がありますか？
しかし、それは繰り返され、異なるフォーマットに変換されるべきです。
この変換が存在する必要がある私の決定の主な軸は何ですか？
答えを得る前に、問題を調査してください。 なぜ変換する必要があるのですか？理由によっては、変換の場所が明確になります。ポイントを証明するいくつかの例：
- "フロントエンドのデータ構造が異なるだけなので"->なぜ違うのですか？バックエンドと同じ構造を使用できないのでしょうか？可能であれば、変換はまったく必要ありません。
- "サーバーがデータを別の形式で保存しているため"->フロントエンドは、バックエンドが使用することを決定した保存方法を知る必要がないため、フロントエンドはデータを適切に変換する責任があります
- "フロントエンドのJSプラグインで使用されるデータ構造はバックエンドAPI構造と異なるため"->バックエンドは、フロントエンドが使用することを決定したプラグインについて知る必要はありません。したがって、フロントエンドはデータを適切に変換する責任があります
変換しようとしているこれらのさまざまなデータ構造を使用する原因となった現実世界の考慮事項がわからないため、これについて明確に答えることはできません。
DTO変換
理論的には、アプリケーションのすべてのレイヤーには、マップする独自のDTOが必要です。つまり、バックエンドに複数のレイヤー（Web、BLL、DAL）がある場合、DAL DTO、BLL DTO、およびWeb DTOが必要です。
実際には、この種の抽象化は理論的にはエレガントですが、多くの場合、技術的な利点がほとんどなく、コピー/貼り付けが多いDTOにコピー/貼り付けされます。 DALエンティティはその構造を変更します（たとえば、新しいプロパティ）。
ここで打つには慎重なバランスがあります。状況を観察して適切なバランスをとります。バックエンドが実際のデータエンティティを公開する純粋なREST APIである場合、つまり、バックエンドは純粋にデータベースアクセスサービスです（バックエンドAPIは本質的に常にビジネスロジックの間にない正確なデータエンティティを公開します） ）の場合、複雑さが大幅に削減されますが、バックエンドが独自のビジネスロジックを実行するため、DTOを使用してレイヤーを分離する必要性がより重要になります。
ここでの主なポイントは、投稿で説明したよりも多くの考慮事項が必要な質問であるため、レイヤーとその責任をより深く研究する必要があるということです。
スケーラビリティの懸念
リソース配列のサイズが100の場合、変換がフロントエンドで行われるためには問題がなく、妥当である必要があります。リソース配列のサイズがはるかに大きい場合はどうですか？バックエンドで反復とデータのある形式から別の形式への変換が発生するしきい値がありますか？
変換の責任をフロントエンドに移すことにはかなりの理由がありますが、これがスケーリングするかどうかは疑問です。
1000要素のフロントエンドに属さないと思われる場合は、2要素のフロントエンドにも属しません。それはそれと同じくらい簡単です。理論的には、（実際のコードの）適切な場所は、通過するデータの量ではなく、その機能的な目的によって決定されます。
そのために、「配列にさらに項目がある場合はどうなりますか？」有効な質問ではありません。配列内の項目の量に基づいて考えを変えると、配列が大きくなる前でさえ、それを間違って行っていました。
パフォーマンスの最適化
そうは言っても、実際のパフォーマンスのボトルネックでは、何かを実装する方法について理論的に完璧ではないことが必要になる場合があります。しかしそのような場合、あなたは現在あなたの質問で馬の前にカートを置いています。
パフォーマンスを時期尚早に最適化しないでください 。この問題が問題になったときに取り組む必要があるだけです。現在尋ねている質問は、特定の状況で発生する可能性のある、または発生しない可能性のある将来について起こり得ることについてです。将来起こりうるあらゆる問題から予防的に保護することは非効率的です。問題が発生したときに対処する方がはるかに効率的です。
最後に、runtimeに関する限り、フロントエンドのパフォーマンスよりもバックエンドのパフォーマンスに関心があります（バックエンドサーバーに料金を支払っているが、ユーザーのコンピュータ）。これが、フロントエンドの前にバックエンドAPI（少なくともインターフェース）を開発することをお勧めする理由の一部です。
これがフロントエンドコンバージョンにつながる場合は、それで問題ありません。
これらのフロントエンド変換がフロントエンドにとって扱いにくくなりすぎる場合、それらはユーザーエクスペリエンスを著しく損なうものであり、ユーザーのすべての変換（！）の計算作業をバックエンドサーバーに任せてもかまいません。バックエンドAPIを評価/拡張して、フロントエンドのデータ構造に対応し、変換を行います。
レイヤーを適切に分離し、最初から適切な方法を使用すれば、これらの将来の変更は最小限に抑えられ、将来必要になると思われる手順ではなく、必要な手順のみを確実に実行できます。これにより、とにかく問題になることのないような事態を防止するための多くの無駄な努力が防止されます。