要素の配置の責任-フロントエンドまたはバックエンド？
私たちの会社では、最近、アプリケーションのどの部分がリストの項目の（再）配置に責任があるかについて話し合いました。
リストは、生産で行われるステップの視覚的表現です。バックエンドはそれを「通常の」順序（1、2、3、4）で提供します。フロントエンドの最上部は4番目の要素、下は3番目、2番目の下にある必要があります...これはWebサイトなので、フロントエンドは上から下にレンダリングする必要があるため、Webサイトの順序が間違っています。彼はそれを正しい方法でレンダリングするために、4.、3.、2.、1。である必要があります。
これらは最大10項目で、毎回すべて表示されます。したがって、ページングやフィルターは必要ありません。
基本的に、フロントエンドは、バックエンドがアイテムを返すのとは逆の順序でアイテムを必要とします。私の同僚、フロントエンド開発者は、それがバックエンドの仕事だと言っています。私の意見では（バックエンド開発者として）、それはフロントエンドの一部です。
彼のポイント：
- フロントエンドは「変更不可」です。プレゼンテーションに変更がある場合、フロントエンドで何も変更する必要はありませんが、
- フロントエンドはそれが必要とするものを言い、バックエンドは適応しなければなりません、
- フロントエンドは馬鹿げている-そこにロジックがあってはならない。
私のポイント：
- それは表現の問題です。バックエンドはそれについてまったく心配する必要はありません。それは彼がアイテムを必要とする順序を気にしません（そして知りません）。
- 間違った責任。タイヤを交換したいのであれば車のエンジンで作業したくないので、UIに変更がある場合（つまり、他の配置）、変更はUIで行われるはずです。
- 1つのUIに限定したくありません。 If他のフロントエンドを追加することを選択し（おそらく実行しないことになります）、同じ方法でリストを表示しないので、別の方法を用意する必要がありますか？
あなたは私たちの見解のポイントを理解していると思います。おそらく1行のコードであるため、実装の問題ではありません。システムの新しい部分を計画しているので、これはアーキテクチャ上の問題です。たぶん、その間に別のレイヤーが必要なだけかもしれません。しかし、フロントエンドとバックエンドのどちら側ですか？
最終編集：回答ありがとうございました。予想よりも詳細で詳細でした。興味のある方のために、これが私たちのやり方です。大多数はバックエンドに配置することをお勧めしますが、ロジックはフロントエンドに配置します。どうして？主に私がそれをあまりにも大まかに説明し、答えが私が遅すぎて説明した事実と要件に基づいていたからです。定義により、この最大のリスト。 10個の要素が正しい順序で並べられます。そして、フロントエンドは他の順序でそれを必要とするので、これはこの方法でWebにレンダリングする方が簡単であるという理由だけのためです、それは純粋にプレゼンテーションのものです。誤解しないでください。すべての回答は非常に役に立ち、私たちはそこから多くの情報を得ました。オーバーエンジニアリングは、このAPIでフィルターやページングなどが一切必要ないことを認識するために必要なキーワードだったと思います。しかし、地獄、私たちは予想以上に多くを学びました！
適切なバックエンドAPIは、クライアントに返す結果のカスタマイズまたはフィルタリングを可能にするパラメーターを受け取る必要があります。リストを返すものの場合、通常は以下を提供するのが一般的です。
- 一部のフィールド基準に基づいて順序付けするためのパラメーター（ASCまたはDESC）。
- ページネーションのパラメーター。
- 検索クエリのパラメータ（つまり、リストをフィルタリングしてレコードのサブセットのみをリクエストする）。
これは常にルールというわけではありませんが、多くの場合、これら3つの項目すべてが組み合わされています。
バックエンドAPIに結果のリストだけを返し、「それがフロントエンドの問題となる」のは、ほとんどの場合悪い考えです。これにより、UIがより複雑になり、バックエンドで非常に簡単に、パフォーマンスに影響を与えることなく実行できる処理が実行されます。
ディスカッションを1秒間切り替えて、リストをUI内でページ分割するユースケースについて考えてみましょう。フロントエンドにリスト全体を強制的に取得させ、それをメモリに保持し、クライアント側でページ付けを実行しますか？ユーザーが次のページをクリックするたびに完全なリストをリクエストする場合はどうなりますか？
私が言っているのは、それはトレードオフだということです。バックエンドで実行する必要があるものと、フロントエンドで実行する必要があるものがあります。 「バックエンドのすべて」や「フロントエンドのすべて」ではありません。あなたとそれについて話し合い、APIが返すものと受け取るパラメータについて合意してください。基本的に、柔軟性のあるAPIではなく、柔軟性のあるAPIを作成します。
そして、私が完全に正直であることを気にしないのであれば、これはアーキテクチャ上の問題ではありません。 アーキテクチャは重要です 。画面上のアイテムの順序は重要ではないため、アーキテクチャではありません。
シンクライアント
あなたの同僚がクライアントが愚かであると言うとき、彼はシンクライアントのアイデアを意味します。 APIを記述的に設計し、単純なCRUD（作成、読み取り、更新、削除）操作だけでなく、APIを使用してその結果を表示するだけのダムクライアントを簡単に作成できます。このアプローチにより、フロントエンドとバックエンドの両方が比較的シンプルに保たれます。
クライアントに委任
ここで、ユースケースがより複雑な大きなアプリケーションを設計する場合、CPUに集中する作業をクライアントに委任するという考えを利用することができます。サーバーが多くのクライアントで使用されている場合、個々の計算をクライアントに移動してシステムを高速化することは理にかなっています。
ビッグデータ
クライアントへの委任の問題は、ほとんどのアプリケーション設計で、データレイヤーがパフォーマンスを最適化するのが最も難しいものの1つです。膨大なデータのリストをクエリしてクライアントに送信し、そこに表示してからフィルタリングするだけでは意味がありません。特定のデータ量がある場合は、高度に最適化されたデータベースアルゴリズムを使用して、データの並べ替え、フィルター処理、ページ付けを行うことをお勧めします。帯域幅も安全です。
結論
何をしても、それを最もシンプルに保ち、パフォーマンス要件を追加します。
編集のアドレス指定
正しい順序が1つしかなく、視覚化を改善するためにデータを並べ替える必要がない場合、順序付けを行うのはバックエンドの仕事です。
編集により、IMOが重要なコンテキストが追加されます。これは、任意の順序で表示できる、またはさまざまな属性によって順序付けされる抽象的なデータソースではありません。これは明確なシーケンスを持つ物理的なプロセスです。
つまり、プロセスについて最もよく知っているはずのバックエンドが、正しい順序で情報を提供している必要があります。フロントエンドは、バックエンドが逆またはランダムな順序でプロセスステップを提供することを心配する必要はありません。
フロントエンドは、受け取った順序でステップを表示する必要があります。そのために何をするか（意図的なしゃれはありません）、それは自由です。
あなたとあなたの同僚はどちらも「あなたが考えていること」に関して本質的に正しいです。見逃したのは、最新のプログラミングの3番目のコアコンポーネントであるモデルです。 Model-View-Controller（MVC）アーキテクチャでは、モデルは一連のデータファイル、データベーステーブル、またはフィールド、それらのレイアウト方法、選択値の順序などを説明する他の何らかの「データ」です。 。
ビューは、あなたが「フロントエンド」と呼んだものであり、実際、同僚が主張するように、ビューには最小限のロジックが含まれている必要があります。実際、元々、メインフレームへの接続は「ダム端末」を介して行われていました。これらは、実質的にロジックがなく、サーバーが変更せずに表示したものを表示するだけだったために呼び出されました。ただし、ここで例外が発生する可能性があります。おそらく、1つのビューがリストの一番上に「デフォルト」オプションを持っているかもしれませんが、それはケースごとにあるはずです。
コントローラは、あなたが「バックエンド」と呼んだものであり、必須フィールドの検証、ビジネスルールの適用などを担当する必要があります。選択値の順序を具体的に指示するものでもありません。それはモデルを参照し、モデルが定義するものは何でも返す必要があります。この場合、モデルが「逆」の順序で返されるため、コントローラーは正しくありません。
3番目のコンポーネントを追加することにより、システム管理者は、ビジネスルールに影響を与えたり、フロントエンドロジックを更新したりすることなく、選択値を変更できます。実際、SAは、この状況ではプログラマーである必要さえありません。通常、変更が必要なファイルは、なんらかの形式の管理アプリを通じて公開されます。今、この種の柔軟性が必要だとは思わない。後で何かをコーディングするのは、通常、最小限の労力で済むため、後でオプションを選択できる。
最終的には、フロントエンドとバックエンドの両方が一貫したエクスペリエンスを提供するために活用できるモデルを開発することで、システムにメリットがもたらされます。コードを変更せずにシステムの動作に影響を与える可能性のある場所にあるデータファイルである必要があるため、フロントエンド開発者もバックエンド開発者も選択値の順序を気にする必要はありません。確かに、あなたにとってはもっと手間がかかります今ですが、最終的には、効果的なモデルを導入することで誰もがより生産的になります。
出典：テクニカルサポート、コンサルタント、管理者、開発者としてのsalesforce.comでの約15年の経験（2019年現在）。