Всем привет, пишу приложение состоящее из frontEnd (NuxtJS) и BackEnd (Asp Core) части.
В результате работы пользователя происходит редактирование данных укрупненно представленных в виде следующей модели:



Изменение модели заключается в добавлении/удалении из массива корневых элементов ({"parentID":1...}), добавление/удаление дочерних элементов внутри родительских({"childID":"4"}). Я хочу сделать теневое сохранение результатов работы пользователя на BackEnd - по таймеру будет считываться данные с клиента и отправляться на бэкэнд для сохранения.
Соответственно я столкнулся с выбором стратегии сохранения данных.
1) Каждый раз отправляем полностью объект с данными для сохранения- на бэкэнде старый стираем, поверх него записываем новый.
+:
простота
отсутствие промежуточных состояний данных
-:
передача избыточных данных- они не поменялись, но все равно их сохраняем
2)На front храним предыдущую версию отправленных данных и отправляем только в том случае, если есть хоть одно отличие в сравнении с текущей
+:
Отбрасываем отправку дублирующих запросов
-:
Появляется хранение промежуточного состояния-уязвимая точка приложения, при падении которой происходит потеря последней версии данных
3)Создание на front логики, которая будет сравнивать текущее состояние данных и предыдущее сохранение и выделять конкретные группы изменений:
*созданные корневые ({"parentID":1...}) записи
*удаленные корневые записи
*редактированные корневые записи(изменения в массиве children)
на бэкэнд отправляется что-то вроде

и на бэкэнде делается соответствующие команды для редактирования данных.
+:
минимально объем отправленных данных- отправляется только то, что действительно изменилось
-:
довольно сложная реализация
много этапов, на котором что-то может пойти не так и исказит данные
4)Дублируем каждое действие на front. То есть пользователь добавил корневой элемент- отправляем http-запрос сделать аналогичную команду с данными на бэкэнде, удалил, отредактировал- аналогично.
+:
не нужно хранить промежуточных состояний на front
несложная логика реализации
-:постоянный спам беэенда мелкими запросами, необходимость для пользовательского UI ждать, пока backend вернет ответ, что запрос прошел успешно.

Соответственно вопрос, возможно есть решение, которое лежит вне той плоскости, где выбирается между избыточностью отправляемых данных, простотой и минимально необходимым количеством http-запростов, но сложностью.
Какие есть best-practice для подобных ситуаций именно в архитектурном плане?Спасибо

skyANA,
частота редактирования в пике-1 изменение в 3 секунды.
Объем редактированной информации-1 родительский объект({"parentID":1...}) или 1 дочерний внутри какого-либо родительского("childID":"4"}).

hVostt,
все приведенные мной практики- компромиссные то есть улучшая какую-либо одну характеристику, приходится делать хуже другую.
Если кратко о задаче- то нужно чтобы на frontend и на backend был один и тот же объект данных, но редактирование этого объекта можно осуществлять только с frontend.
Сейчас рассматриваю возможность попробовать 4-й вариант, только не через http, а через webSocket соединение.

Dimitry Sibiryakov,
но судя по бенчмаркам и тестам на размер передаваемых данных сокеты лучше подходят для частой пересылки данных малыми объемами. Ну а что сюрприз, это да, я ожидал что сокеты будут пониже уровнем, чем http.

skyANA,
пользователю каждый день приходит список ориентировочно на 300 элементов( {"childID":"1"} ... {"childID":"300"}) и он начинает их drag-and-drop'ом растаскивать по группам({parentID:"1","children":'список элементов, содержащихся в этой группе'}). Растаскивает до тех пор, пока каждый элемент не будет в какой-либо группе и может элементы между группами перекидывать.
Я хочу избавиться от кнопки "Сохранить", хочу чтобы это было автоматически. Ведь как приятно, что в Visual Studio не надо жать эту кнопку сохранения. И соответственно хочу перенести этот позитивный опыт в свое приложение.