Я заранее приношу свои извинения за любое неправильное использование терминологии распределенной системы или неправильное применение или искажение принципов распределенной системы. Пожалуйста, отзовитесь на мои ошибки.
С учетом этого, повторяя название, ваш веб-клиент является частью распределенной системы. Ниже приведено несколько моментов, которые следует помнить о роли, которую ваш веб-клиент играет в этой распределенной системе.
Кэширование
Веб-клиенты дольше хранят больше данных. Поскольку браузеры и операционные системы предоставляют веб-клиентам больше средств для сохранения данных, веб-клиенты все больше несут ответственность за управление кэшированием этих данных.
В одностраничных приложениях, поскольку время между обновлениями страниц увеличивается, важно учитывать даже кэширование данных в памяти.
Последовательность
Распределенные хранилища данных должны согласовывать потенциально конфликтующие обновления от нескольких одновременно работающих клиентов и других узлов. Веб-клиенты имеют дело с микрокосмом распределенного хранилища, нуждаясь в согласовании практически одновременных обновлений, как правило, из двух источников: сервера и пользователя.
Еще одним аспектом роли клиента в обеспечении согласованности является то, как он передает обновления серверу.
Будем надеяться, что сервер предоставляет средства для конкретных, четко определенных обновлений. Тогда клиент может быть целенаправленным и преднамеренным; т. е. запрашивать обновления только для определенных, обновленных пользователем полей, а не для всей записи.
Кроме того, клиенты часто работают с агрегированными объектными представлениями данных, а не с детализированными кортежами (записями), которые можно найти в хранилище данных. Хотя эти сложные представления, вероятно, упрощают клиентскую логику и сокращают количество сетевых запросов, они могут быть громоздкими и неудобными для передачи обновлений.
Например, если связь между записями моделируется с использованием массива, а не переопределения всего массива при каждом обновлении, вероятно, более правильным будет сделать целевой запрос на добавление и/или удаление только определенных записей из связи.
атомарность
По мере того, как веб-клиентам становится легче делать больше, иногда полезно сделать шаг назад и спросить, должны ли они это делать.
Конечно, веб-клиент может обрабатывать многоэтапные обновления, координировать запросы к нескольким конечным точкам и пытаться откатиться в случае сбоя. Но в контексте распределенной системы клиент наиболее подвержен аппаратным и сетевым сбоям, не говоря уже о капризах пользователя.
В заключении
Извините, что не предоставил более конкретные примеры или ссылки. В основном я надеюсь, что перевод некоторых мыслей, которые буквально не дают мне спать по ночам (сейчас 00:26), даст некоторую передышку.
С удовольствием вступлю в беседу, если есть какой-то конкретный момент, по поводу которого у вас есть мысли или вопросы.
