Желательно ли выполнять дополнительную логику для данных во внешнем интерфейсе?

Question

При получении данных для отображения во внешнем интерфейсе рекомендуется выполнить дополнительную логику для этих данных во внешнем интерфейсе - например, проверка столбцов, если они содержат определенные значения, затем скрытие столбцов, или это должно быть сделано в бэкэнде, который должен возвращать во внешний интерфейс только логическое значение?

Меня беспокоит то, что когда данные растут, это сильно повлияет на производительность приложения в браузере. Если да, какие аргументы следует использовать при обсуждении с людьми, которые не согласны / не хотят находить время для этого?

Я использую Angular ngFor для отображения данных, но, очевидно, мне нужно выполнить эту логику перед построением DOM.

Answer 1

Да, желательно сделать это. Но есть несколько случаев, чтобы рассмотреть:

Сценарий 1: есть ~ миллион клиентов, и каждый клиент хранит данные ~ 1000 строк. В этом сценарии лучше выполнять большую часть фильтрации на стороне клиента, что снижает нагрузку на сервер и позволяет обслуживать больше запросов.

Сценарий 2. Любое количество клиентов и каждого клиента содержит данные в ~ 10000 или ~ миллион строк. В этом сценарии мы должны использовать нумерацию страниц на стороне сервера, поскольку мы не должны передавать целые данные. Каждый фильтр, применяемый на стороне клиента, потенциально может инициировать вызов сервера для извлечения данных.

В целом, фильтрация на стороне клиента не должна влиять на производительность приложений, поскольку ноутбуки / ПК / платформы в наши дни могут легко справиться с нагрузкой. Но мы не должны рассматривать отправку данных из ~ миллиона строк и пытаться выполнять действия на стороне клиента. Это повлияет на производительность как клиента, так и сервера.

Answer 2

Есть несколько разных подходов к этому. Первое, что я всегда рекомендую, - это обращаться с вашим бэкэндом как с каким-то общедоступным API, который ничего не знает о вашем интерфейсе. Этот вид отвечает уже для многих случаев использования. Если ваш API построен правильно (и не делает странных / смешанных / противоречивых возвратов), возвращение «всего» обычно нормально.

Второе, что вам нужно иметь в виду, это объем данных, о которых вы говорите. Хорошо, если это набор данных с 1000 записями массива для объектов с 20 свойствами, не беспокойтесь - Angular (и JS) чертовски быстр, и вы даже не заметите разницу между массивом с 10 записями или 1.000 или 10.000 (запрос Размер может сыграть в этом важную роль. Но при обычном возврате текста мы все еще говорим только о килобайтах, и с сегодняшней скоростью Интернета это не проблема).

Следующее, что важно, есть разница между обработкой больших массивов / объектов в JS и в DOM. Регулярное отображение ngFor и одновременное отображение 10.000 записей определенно замедлит работу вашего браузера. Но для этого случая вы можете использовать своего рода виртуальное повторение, при котором отображается только 10-50 записей (которые в настоящее время видны в DOM), и при прокрутке они просто используются повторно вместо создания новых.

Последний пункт - попытаться написать проверку производительности. Вы сказали, что хотите скрыть / показать столбцы на основе результата. Хорошо, если это нужно просто оценить один раз, попробуйте поместить его в переменную / «одноразовое связывание» вместо проверки того же условия в каждом цикле дайджеста. Если проверка занимает много времени, потому что она довольно сложная, попробуйте отреагировать на событие, которое может изменить значения, вместо проверки каждого цикла дайджеста.

Так что же взять из этого краткого описания:

• Проверьте размер выборки и решите, стоит ли что-то делать (это помогает провести некоторый бенчмаркинг для бизнес-логики, такой как итерация / анализ данных)
• Делайте как можно больше в самом JS. Это быстрее, чем делать это позже в DOM. Также это помогает сохранить ваш код чистым / читабельным, если шаблон «глупый» и просто отображает данные вместо бизнес-логики
• Если ваши данные становятся слишком большими для обработки в браузере, подумайте, как улучшить ваш API, например, введите пейджинг
• И последнее, но не менее важное: проводите сравнительный анализ и проверку производительности. Во многих случаях вам просто нужно повысить производительность и написать более качественный / быстрый код вместо изменения всей структуры данных