проводить вычисление на сервере или на клиенте?

avatar Lancer.Rev.X

716

21

Lancer.Rev.X

Пользователь

Регистрация: 07.12.2014

Сообщения: 4182

Рейтинг: 2228

Lancer.Rev.X

Регистрация: 07.12.2014

Сообщения: 4182

Рейтинг: 2228

img

у моего списка мебели есть такой флажок: «можно ли собрать данный продукт?». он высчитывается в зависимости от наличия нужных материалов на складе. в МОДЕЛИ у меня есть функции «получить продукты» и «получить материалы», я вот думаю, как лучше:

  1. высчитывать флажки на сервере и передавать их вместе со всеми продуктами функцией «получить продукты»,
  2. либо посчитывать у клиента, у меня так получается, что клиент энивэй закачивает и продукты, и материалы, поэтому флажки может сам высчитать.
 

как правильнее сделать? реализацию обоих вариантов я вроде бы продумал, там все нормально сходится, проблем реализации ни в одном случае не будет.

lexani4321

Пользователь

Регистрация: 28.03.2018

Сообщения: 13019

Рейтинг: 4063

lexani4321

Регистрация: 28.03.2018

Сообщения: 13019

Рейтинг: 4063

Lancer.Rev.X сказал(а):

у моего списка мебели есть такой флажок: «можно ли собрать данный продукт?». он высчитывается в зависимости от наличия нужных материалов на складе. в МОДЕЛИ у меня есть функции «получить продукты» и «получить материалы», я вот думаю, как лучше:

  1. высчитывать флажки на сервере и передавать их вместе со всеми продуктами функцией «получить продукты»,
  2. либо посчитывать у клиента, у меня так получается, что клиент энивэй закачивает и продукты, и материалы, поэтому флажки может сам высчитать.

как правильнее сделать? реализацию обоих вариантов я вроде бы продумал, там все нормально сходится, проблем реализации ни в одном случае не будет.

Нажмите, чтобы раскрыть...

Яб если он уже получает всё что надо для вычисления считал на клиентской стороне чтобы разгрузить сервер. В теории я думаю тысяче юзеров проще сделать одно действие чем одному серверу тысячу.

Lancer.Rev.X

Пользователь

Регистрация: 07.12.2014

Сообщения: 4182

Рейтинг: 2228

Lancer.Rev.X

Регистрация: 07.12.2014

Сообщения: 4182

Рейтинг: 2228

img
lexani4321 сказал(а):

Яб если он уже получает всё что надо для вычисления считал на клиентской стороне чтобы разгрузить сервер. В теории я думаю тысяче юзеров проще сделать одно действие чем одному серверу тысячу.

Нажмите, чтобы раскрыть...

да у меня будет 3-4 юзера максимум, вопрос чисто эстетический, не правильнее ли будет логику поместить в МОДЕЛЬ ко всей остальной логике?

lexani4321

Пользователь

Регистрация: 28.03.2018

Сообщения: 13019

Рейтинг: 4063

lexani4321

Регистрация: 28.03.2018

Сообщения: 13019

Рейтинг: 4063

Lancer.Rev.X сказал(а):

да у меня будет 3-4 юзера максимум, вопрос чисто эстетический, не правильнее ли будет логику поместить в МОДЕЛЬ ко всей остальной логике?

Нажмите, чтобы раскрыть...

Ну ващет правильнее.

Если так смотреть - вряд ли на фронтенде какие-то вычисления в принципе должны быть.

Jaood

Пользователь

Регистрация: 09.09.2019

Сообщения: 3405

Рейтинг: 2051

Jaood

Регистрация: 09.09.2019

Сообщения: 3405

Рейтинг: 2051

На фронте не должно ничего вычисляться, что не касается непосредственно фронта.

Так что тут ответ очевиден.

BeerHelpsMeWin

Пользователь

Регистрация: 17.12.2015

Сообщения: 118

Рейтинг: 84

BeerHelpsMeWin

Регистрация: 17.12.2015

Сообщения: 118

Рейтинг: 84

Lancer.Rev.X сказал(а):

у моего списка мебели есть такой флажок: «можно ли собрать данный продукт?». он высчитывается в зависимости от наличия нужных материалов на складе. в МОДЕЛИ у меня есть функции «получить продукты» и «получить материалы», я вот думаю, как лучше:

  1. высчитывать флажки на сервере и передавать их вместе со всеми продуктами функцией «получить продукты»,
  2. либо посчитывать у клиента, у меня так получается, что клиент энивэй закачивает и продукты, и материалы, поэтому флажки может сам высчитать.

как правильнее сделать? реализацию обоих вариантов я вроде бы продумал, там все нормально сходится, проблем реализации ни в одном случае не будет.

Нажмите, чтобы раскрыть...

Никаких вычислений на фронтенде.

Представь, что фронт открыл форму, и сидит и думает, что делать.

А тем временем остальные не дремлют и кто-то из других пользователей тоже продает этот же продукт?

HiThere

Пользователь

Регистрация: 24.06.2016

Сообщения: 3470

Рейтинг: 2602

HiThere

Регистрация: 24.06.2016

Сообщения: 3470

Рейтинг: 2602

1) Даже если ты сделаешь проверку на клиенте, то сервер все равно должен проверить, не прислал ли клиент фигню, поэтому от проверки на клиенте пользы примерно 0

2) На клиенте вообще не должно быть никакой логики, это всего лишь вьюха, вся бизнес логика должна находиться на бэке

3) Код на клиенте находится в открытом доступе ( в браузере), поэтому даже в плане безопасности нельзя делать никаких вычислений на клиенте

Дроген

Пользователь

Регистрация: 17.08.2014

Сообщения: 5416

Рейтинг: 2202

Дроген

Регистрация: 17.08.2014

Сообщения: 5416

Рейтинг: 2202

lexani4321 сказал(а):

Яб если он уже получает всё что надо для вычисления считал на клиентской стороне чтобы разгрузить сервер. В теории я думаю тысяче юзеров проще сделать одно действие чем одному серверу тысячу.

Нажмите, чтобы раскрыть...

В теории такие расчеты можно кэшировать. 

 

 

Шрек 2

Пользователь

Регистрация: 24.03.2018

Сообщения: 4057

Рейтинг: 2052

Шрек 2

Регистрация: 24.03.2018

Сообщения: 4057

Рейтинг: 2052

img

Очевидно, что не на фронте. Разгружать от вычислений сервер и нагружать ими клиентские айфоны 5c - гениально roflanLico.png

И как уже сказал чел выше, не хочешь делать много запросов - их результаты можно кешировать

Lancer.Rev.X

Пользователь

Регистрация: 07.12.2014

Сообщения: 4182

Рейтинг: 2228

Lancer.Rev.X

Регистрация: 07.12.2014

Сообщения: 4182

Рейтинг: 2228

img
Jaood сказал(а):

На фронте не должно ничего вычисляться, что не касается непосредственно фронта.

Так что тут ответ очевиден.

Нажмите, чтобы раскрыть...

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

Jaood

Пользователь

Регистрация: 09.09.2019

Сообщения: 3405

Рейтинг: 2051

Jaood

Регистрация: 09.09.2019

Сообщения: 3405

Рейтинг: 2051

Lancer.Rev.X сказал(а):

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

Нажмите, чтобы раскрыть...

Да

Podpivasik

Пользователь

Регистрация: 14.07.2018

Сообщения: 29990

Рейтинг: 11106

Нарушения: 80

Podpivasik

Регистрация: 14.07.2018

Сообщения: 29990

Рейтинг: 11106

Нарушения: 80

Lancer.Rev.X сказал(а):

у моего списка мебели есть такой флажок: «можно ли собрать данный продукт?». он высчитывается в зависимости от наличия нужных материалов на складе. в МОДЕЛИ у меня есть функции «получить продукты» и «получить материалы», я вот думаю, как лучше:

  1. высчитывать флажки на сервере и передавать их вместе со всеми продуктами функцией «получить продукты»,
  2. либо посчитывать у клиента, у меня так получается, что клиент энивэй закачивает и продукты, и материалы, поэтому флажки может сам высчитать.

как правильнее сделать? реализацию обоих вариантов я вроде бы продумал, там все нормально сходится, проблем реализации ни в одном случае не будет.

Нажмите, чтобы раскрыть...

на фронтенде не должно быть никаких вычислений и логики.

все на беке. идеальный фронт это верстка + анимации + rest api + стейт менеджер (только для стейта, сеттеров и геттеров, никаких вычислений).

 

представь что есть единый бекенд, и есть твой фронт а есть еще 5 разработчиков со своим фронтом.

как лучше думаешь будет?

все вычислять на сервере и отдавать json файл с данными которые нужно просто вывести.

или же так же делать какие то вычисления на серваке + отдавать json + еще на клиенте дополнительные вычисления, и хрен пойми какие.

Lancer.Rev.X сказал(а):

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

Нажмите, чтобы раскрыть...

да, на фронт ты передаешь например json объект с атрибутами, где атрибут твоего флажка будет true / false. и уже в зависимости от этого отображаешь так как тебе нужно

Lancer.Rev.X

Пользователь

Регистрация: 07.12.2014

Сообщения: 4182

Рейтинг: 2228

Lancer.Rev.X

Регистрация: 07.12.2014

Сообщения: 4182

Рейтинг: 2228

img
Jaood сказал(а):

Да

Нажмите, чтобы раскрыть...

а если у меня между таблицами связи многие ко многим, я же правильно делаю, что отправляю данные с id из другой таблицы, а потом на клиенте беру данные из второй таблицы по этому id? вот я нарисовал стрелочки:

Спойлер: "картинка со стрелочками"

Jaood

Пользователь

Регистрация: 09.09.2019

Сообщения: 3405

Рейтинг: 2051

Jaood

Регистрация: 09.09.2019

Сообщения: 3405

Рейтинг: 2051

Lancer.Rev.X сказал(а):

а если у меня между таблицами связи многие ко многим, я же правильно делаю, что отправляю данные с id из другой таблицы, а потом на клиенте беру данные из второй таблицы по этому id? вот я нарисовал стрелочки:

Спойлер: "картинка со стрелочками"
Нажмите, чтобы раскрыть...

Это нарушает принципы mvc.

У тебя на фронте только вьюха. Единственное что она должна делать, что следует из названия, это отображать данные.

Абсолютно все вычисления, связи и тд, должны оставаться на беке, а на выходе на вьюху подаются уже подготовленные и обработанные данные.

 

Вьюха должна быть на столько же "глупая" в своих вычислениях как маленький ребенок.

Ты даёшь лист А3, на котором уже заполнена таблица. Всё что от ребенка ты имеешь право требовать - нарисовать красивую рамочку фломастерами.

SweetSweetLoot

Пользователь

Регистрация: 06.07.2015

Сообщения: 4739

Рейтинг: 1149

SweetSweetLoot

Регистрация: 06.07.2015

Сообщения: 4739

Рейтинг: 1149

img
Lancer.Rev.X сказал(а):

а если у меня между таблицами связи многие ко многим, я же правильно делаю, что отправляю данные с id из другой таблицы, а потом на клиенте беру данные из второй таблицы по этому id? вот я нарисовал стрелочки:

Спойлер: "картинка со стрелочками"
Нажмите, чтобы раскрыть...

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

 

Я конечно не силен в вебе, но в 1с подавляющее большинство вещей, делается фильтрами на стороне клиента, но при определенных моментах ты переспрашиваешь данные с сервера(переоткрытие страницы, нажатие некоторых кнопок вроде обновить данные и прочее)

почитай про левый и правый join с общим join в sql, мб кота потом ставить не будешь...

Lancer.Rev.X

Пользователь

Регистрация: 07.12.2014

Сообщения: 4182

Рейтинг: 2228

Lancer.Rev.X

Регистрация: 07.12.2014

Сообщения: 4182

Рейтинг: 2228

img
Zly chlopak сказал(а):

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

 

Я конечно не силен в вебе, но в 1с подавляющее большинство вещей, делается фильтрами на стороне клиента, но при определенных моментах ты переспрашиваешь данные с сервера(переоткрытие страницы, нажатие некоторых кнопок вроде обновить данные и прочее)

Нажмите, чтобы раскрыть...

я отправляю клиенту сперва список продуктов с названиями, клиент заносит их в свою таблицу, потом отправляю список заказов, у каждого из которых есть ID продукта, клиент записывает в свою таблицу заказы и вписывает названия продуктов из заполненной ранее таблицы с продуктами.

 

потом еще эти продукты, материалы и заказы могут меняться другими клиентами, например, кто нибудь переименует один из продуктов, я отправляю клиенту сообщение, что продукт переименован, клиент у себя в таблице меняет название продукта и потом еще проверяет таблицу заказов и там тоже где надо меняет название продукта.

 

либо, если не заставлять клиента ничего самостоятельно делать, придется ему отправить второе сообщение об изменении названия продукта в заказе.

SweetSweetLoot

Пользователь

Регистрация: 06.07.2015

Сообщения: 4739

Рейтинг: 1149

SweetSweetLoot

Регистрация: 06.07.2015

Сообщения: 4739

Рейтинг: 1149

img

как то у тебя слишком замудрено с этим...

 

а если кто то поменяет количество материалов на заказ, тоже ждешь подтверждения у другого человека?

если ты про эти флажки, то вполне на сервере можно посчитать

Gachi boSS

Пользователь

Регистрация: 15.05.2016

Сообщения: 6117

Рейтинг: 1207

Gachi boSS

Регистрация: 15.05.2016

Сообщения: 6117

Рейтинг: 1207

Lancer.Rev.X сказал(а):

у моего списка мебели есть такой флажок: «можно ли собрать данный продукт?». он высчитывается в зависимости от наличия нужных материалов на складе. в МОДЕЛИ у меня есть функции «получить продукты» и «получить материалы», я вот думаю, как лучше:

  1. высчитывать флажки на сервере и передавать их вместе со всеми продуктами функцией «получить продукты»,
  2. либо посчитывать у клиента, у меня так получается, что клиент энивэй закачивает и продукты, и материалы, поэтому флажки может сам высчитать.

как правильнее сделать? реализацию обоих вариантов я вроде бы продумал, там все нормально сходится, проблем реализации ни в одном случае не будет.

Нажмите, чтобы раскрыть...

только сервер

Lancer.Rev.X

Пользователь

Регистрация: 07.12.2014

Сообщения: 4182

Рейтинг: 2228

Lancer.Rev.X

Регистрация: 07.12.2014

Сообщения: 4182

Рейтинг: 2228

img
Jaood сказал(а):

Это нарушает принципы mvc.

У тебя на фронте только вьюха. Единственное что она должна делать, что следует из названия, это отображать данные.

Абсолютно все вычисления, связи и тд, должны оставаться на беке, а на выходе на вьюху подаются уже подготовленные и обработанные данные.

 

Вьюха должна быть на столько же "глупая" в своих вычислениях как маленький ребенок.

Ты даёшь лист А3, на котором уже заполнена таблица. Всё что от ребенка ты имеешь право требовать - нарисовать красивую рамочку фломастерами.

Нажмите, чтобы раскрыть...

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

Спойлер:

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

 

но код клиента получился намного проще, думаю, это точно позитивно повлияет на процесс разработки

Jaood

Пользователь

Регистрация: 09.09.2019

Сообщения: 3405

Рейтинг: 2051

Jaood

Регистрация: 09.09.2019

Сообщения: 3405

Рейтинг: 2051

Lancer.Rev.X сказал(а):

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

Спойлер:

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

 

но код клиента получился намного проще, думаю, это точно позитивно повлияет на процесс разработки

Нажмите, чтобы раскрыть...

Mvc лишь подразумевает что ты всю бизнес логику переносишь на сервер. Ты точно так же можешь запрашивать отдельные колонки на сервере.

Это никак не ограничивает функционал.

Если я правильно понял твою проблему с редактированием данных, то ты можешь выстроить такую цепочку событий.

Клиент начинает редактировать на клиенте ->

клиент завершает редактирование на клиенте ->

ты отправляешь тот кусок данных, которые клиент отредактировал ->

сервер отработал изменения в базе ->

сервер вернул тебе новую версию таблицы ->

ты обновил представления таблиц на клиенте.

Lancer.Rev.X

Пользователь

Регистрация: 07.12.2014

Сообщения: 4182

Рейтинг: 2228

Lancer.Rev.X

Регистрация: 07.12.2014

Сообщения: 4182

Рейтинг: 2228

img
Jaood сказал(а):

Mvc лишь подразумевает что ты всю бизнес логику переносишь на сервер. Ты точно так же можешь запрашивать отдельные колонки на сервере.

Это никак не ограничивает функционал.

Если я правильно понял твою проблему с редактированием данных, то ты можешь выстроить такую цепочку событий.

Клиент начинает редактировать на клиенте ->

клиент завершает редактирование на клиенте ->

ты отправляешь тот кусок данных, которые клиент отредактировал ->

сервер отработал изменения в базе ->

сервер вернул тебе новую версию таблицы ->

ты обновил представления таблиц на клиенте.

Нажмите, чтобы раскрыть...

для построения таблицы, как на первой картинке, клиент должен по сути сам соотнести рецепт продукта по айди материала с названием материала, структура данных такая:

Спойлер: "данные для картинки 1"

это же получается уже связь, а ты говоришь, что все связи должны быть на сервере

 

вот по твоему совету я отправил такие данные уже готовые к отображению

Спойлер: "данные для картинки 2"

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

 

Спойлер: "два варианта структуры данных заказов"

Jaood

Пользователь

Регистрация: 09.09.2019

Сообщения: 3405

Рейтинг: 2051

Jaood

Регистрация: 09.09.2019

Сообщения: 3405

Рейтинг: 2051

Lancer.Rev.X сказал(а):

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

Нажмите, чтобы раскрыть...

Не очень-то и большой "лишний расход". Тебе же не обязательно всю таблицу каждый раз отправлять, а только те части, которые нужно обновить.