Здравствуйте, Shmj, Вы писали:


S>И такой вопрос. Если выбрали вариант 2, то может возникнуть такая проблема. Допустим, установили цвет объекта и размер объекта. Сразу изменили в GUI и отправили 2 запроса. При этом первый запрос вернет что изменен цвет, но размер еще не изменен (т.е. второй запрос еще не исполнен — а размер указали во втором запросе, при этом в GUI — уже установили все). Как быть — как лучше такие ситуации обрабатывать?

Почему бы не отправить всё одним запросом? Мы ведь не отправляем каждое поле формы отдельно (если отправляем, то очень грустно за вэбдэв)

Сейчас встречается практика видимости скорости реакци пользовательского интерфейса (GUI). Как то обновил некие данные в приложении и оно сделало вид что все ОК, все обновилось. Но при этом на сервере еще не обновилось (а может и вообще запрос не дойдет).

Ну, к примеру, некий объект выделяешь цветом. Варианта два:

1. Сначала отправить запрос на сервер (цвет установлен), дождаться пока сервер скажет ОК — потом обновить цвет объекта.
2. Обновить цвет объекта локально (в GUI) и уже потом отправить запрос на сервер. И уже если НЕ ОК, тогда вернуть цвет взад и сообщить об ошибке.

Какой вариант вы выбираете и почему? Как я вижу, сейчас моден вариант 2.

И такой вопрос. Если выбрали вариант 2, то может возникнуть такая проблема. Допустим, установили цвет объекта и размер объекта. Сразу изменили в GUI и отправили 2 запроса. При этом первый запрос вернет что изменен цвет, но размер еще не изменен (т.е. второй запрос еще не исполнен — а размер указали во втором запросе, при этом в GUI — уже установили все). Как быть — как лучше такие ситуации обрабатывать?

Стараюсь выбирать первый вариант, т.к. проще для реализации.

S>Допустим, установили цвет объекта и размер объекта. Сразу изменили в GUI и отправили 2 запроса. При этом первый запрос вернет что изменен цвет, но размер еще не изменен (т.е. второй запрос еще не исполнен — а размер указали во втором запросе, при этом в GUI — уже установили все). Как быть — как лучше такие ситуации обрабатывать?

Показать пользователю ошибку с кнопкой "перезагрузить страницу". Как перезагрузит, так увидит, что там изменилось, что нет. Пускай чинит свой интернет.

Вообще мой поинт в том, что делать систему, в которой есть два состояния (клиентское и серверное) с взаимоной синхронизацией это очень нетривиально и даже сложно. Поэтому тут походя какой-то совет и не дашь. Если вдруг хочется — то нужно готовиться, что такая система потребует огромных сил для корректной во всех случаях реализации. И всё это ради того, чтобы пользователю работалось чуть-чуть комфортней? По-мне это неразумные траты сил в 90% случаев. Если это система вроде Google Docs, где совместное редактирование документа это прям главная фича, тогда без вопросов — садишься и делаешь архитектуру, возможно со всякими CQRS, кастомными БД, и тд. А если это обычная крудятина, то лучше убедить пользователя, что ему оно не надо.

А если делать такую систему "малой кровью" — там будет куча необработанных ситуаций, вплоть до потери данных из-за подобных проблем. В общем оно того не стоит.

Здравствуйте, Shmj, Вы писали:

S>1. Сначала отправить запрос на сервер (цвет установлен), дождаться пока сервер скажет ОК — потом обновить цвет объекта.
S>2. Обновить цвет объекта локально (в GUI) и уже потом отправить запрос на сервер. И уже если НЕ ОК, тогда вернуть цвет взад и сообщить об ошибке.

S>Какой вариант вы выбираете и почему? Как я вижу, сейчас моден вариант 2.

Третий вариант: обновить цвет локально, но не на тот, который "Ok", а какой-то иной. После ответа от сервера, что запрос отработан еще раз изменить цвет. Как подвариант — нарисовать рядом с выделением что-то вроде часиков, которые после ответа сервера меняются на зеленую галочку.

Правда, в этом случае может так происходить, что сервер реально обновил данные, но ответ "Ok" от сервера потерялся

Здравствуйте, Shmj, Вы писали:

Это называется leaky abstraction.

Приложение делает вид, что оно обычное, хотя его жопа располагается на сервере. Иногда эта абстракция протекает.

Так что, или п.2, или в явном виде оформление и отправка запросов на сервер (но это для ультрагиков по нынешним временам).

Здравствуйте, Shmj, Вы писали:

S>И такой вопрос. Если выбрали вариант 2, то может возникнуть такая проблема. Допустим, установили цвет объекта и размер объекта. Сразу изменили в GUI и отправили 2 запроса. При этом первый запрос вернет что изменен цвет, но размер еще не изменен (т.е. второй запрос еще не исполнен — а размер указали во втором запросе, при этом в GUI — уже установили все). Как быть — как лучше такие ситуации обрабатывать?

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

Версионирование как наиболее простое, что можно сделать.
Т.е. по сути чтобы такая система из "варианта 2" нормально работала, нужен работающий механизм транзакций и undo/redo, который будет для нее базой.

Изменения в GUI накатываются через CQRS, модель никогда не модифицируется напрямую.

Из готовых сервисов google firebase например или microsoft fluid.

Здравствуйте, Alekzander, Вы писали:

A>Приложение делает вид, что оно обычное, хотя его жопа располагается на сервере. Иногда эта абстракция протекает.

A>Так что, или п.2, или в явном виде оформление и отправка запросов на сервер (но это для ультрагиков по нынешним временам).

Тут логическая связь пропущена в духе ландафшицкого "Совершенно очевидно, что".

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

Либо, видя недостатки такой абстракции, отказываемся от неё и делаем отправку запросов явной, вынося её в UI (например, в виде кнопки синхронизации).

Поэтому п.2.

Здравствуйте, Shmj, Вы писали:

S>1. Сначала отправить запрос на сервер (цвет установлен), дождаться пока сервер скажет ОК — потом обновить цвет объекта.
S>2. Обновить цвет объекта локально (в GUI) и уже потом отправить запрос на сервер. И уже если НЕ ОК, тогда вернуть цвет взад и сообщить об ошибке.

Это ты сейчас https://www.somethinglikegames.de/en/blog/2024/pros-and-cons-of-lag-compensation/ в обычном GUI изобретаешь? А зачем?