データはバックエンドまたはフロントエンドでフォーマットする必要がありますか？
私はWebアプリケーションを持っていますが、フロントエンドとバックエンドのどちらでデータをフォーマットする方がよいのでしょうか。彼らは両方とも仕事を成し遂げますが、誰かが私にブレインストーミングを手伝ってくれるかもしれません。
例として、名前の家系図を特定の形式で返すバックエンドがあるとしますが、フロントエンドでは、ウィジェットが期待する形式に一致するように形式を調整する必要があります。この調整がバックエンドで行われる場合またはフロントエンド？
バックエンドで実行した場合、データをフロントエンドのウィジェットに直接プッシュできます。それ以外の場合は、事前にフロントエンドで解析する必要があります。誰かがこの状況の賛否両論を考えることができますか？ありがとう。
素晴らしい質問です。階層化されたMVCに触発されたアーキテクチャを実行します。
バックエンド
バックエンドのデータを「自然な」順序に従ってモデル化（フォーマット）します。言い換えれば、私はデータの内部構成に従います。これは、私のAPIが複数の変更または進化するクライアントによって頻繁に使用され、APIを複数回書き換えたり、複数のバージョンを使用したりすると、維持に時間がかかりすぎるためです。
これは、API呼び出しごとにデータベースのコンテンツを送信する必要があるという意味ではありません。呼び出しごとにデータモデルを確実に削減する必要がありますが、特定のビューに合わせてカスタマイズされたデータ構造ではなく、バックエンド（「自然」）データモデルの削減バージョンである必要があります。
フロントエンド
フロントエンドには、サーバーからデータを受け取り、特定のビューによく適合するモデルにデータを変換する密結合コントローラーがあります。クライアント側で使用されるテクノロジーによっては、これに対するライブラリサポートがある場合があります（たとえば、Javascript用のAngularJS/Java用のHTMLSwing、C＃用のWPFなど）。
このアーキテクチャにより、クリーンな分離と高い生産性が得られることがわかりました。
これは、データを使用して行う必要のある変換の性質と、特定の型の変換が必要になる頻度によって異なります。
デフォルトでバックエンドに生データを返すようにしますが、フロントエンドで必要になることが多い特定のデータ形式の場合、バックエンドエンドポイントに、データを返す形式をバックエンドに指示するリクエストパラメーターを受け入れるようにします。
私はこれを私が一緒に働いている別の開発者と扱っています。彼はSQLでの作業が大好きで、基本的にSQLでの作業、ビジネスロジック、フォーマットなどすべてを行っています。私の意見では（そして少なくとも私たちが取り組んでいるアプリでは）SQLはデータの保存と取得を処理するためのものであり、サーバーコード/クライアントコードはデータをユーザーに提示し、ユーザーのそのデータとの相互作用を処理するためのものです。
ただし、これはSQL（または他のDBエンジン）とアプリケーションコードだけに限定されません。サーバーコードがよりAPIであり、データをjavascriptの重いWebアプリケーションに渡す場合、同じことが当てはまります。 APIは、UIがデータをどのように処理するかを認識していません。APIの目的は、生データを配信し、JavaScript /プレゼンテーションコードで必要な方法でデータをフォーマットすることです。
これには例外があると確信していますが、それが私が従うのが好きな一般的なルールです。フォーマットはプレゼンテーションの領域にあり、ビジネスロジックやデータ検索ではありません。そこに保管してください。
編集：私はあなたの質問を読み直しました、そして私は微妙ですが重要なポイントを逃したと思います。特定の形式での入力を期待しているコンストラクターやモデル、または何を持っているかがある場合は、SQLでその形式化/変換を実行して、データを使用する前にデータを変換する余分な手順を回避することをお勧めします。ただし、解決しようとしている問題と、データの出所と使用場所の詳細に大きく依存します。
考慮すべきもう1つの側面は、ロケール認識（千単位の区切り文字、コンマ区切り文字、日付形式など）です。
消費するアプリケーションがロケール対応のクライアント（Webブラウザーなど）からアクセスすることを意図している場合、私は可能な限りフォーマットをフロントエンドにプッシュすることを好みます。 技術的にロケールをパラメータとしてバックエンドAPIに送信することは可能ですが、最近のフロントエンドライブラリは通常、デフォルトでロケールの処理に非常に優れているため、フロントでの処理がはるかに簡単になります-終わり。
これの例外は、オーディエンスが1つのロケールのみに制限されていることが確実にわかっている場合です。