У меня вопрос где-то между UX и API.
У меня есть компонент, похожий на график Ганта. Каждое изменение немедленно сохраняется. Пользователь видит загрузчик блокировки примерно 200-300 мс, так что это своего рода синхронное обновление, но пока это не проблема. Веб-приложение использует простые вызовы REST API, такие как POST /tasks, DELETE /categories/1/tasks/1 et c. Код клиента таким способом может быть очень простым:
- Сохранить выполнено - обновить пользовательский интерфейс
- Сохранить не удалось - ничего не делать и показать сообщение об ошибке
Теперь у меня есть требование для поддержки asyn c save. Здесь все становится намного сложнее, потому что мы должны обрабатывать сброс соединения - если у нас возникает ошибка при сохранении - мы не хотим прерывать поток, но все же хотим убедиться, что все сохранено или , которые знает пользователь что это не сохранено. Поэтому обновления должны накапливаться до тех пор, пока мы не сможем их сохранить.
Так что я имею в виду два подхода:
- Иметь очередь запросов и запускать запросы один за другим. Не запускайте их параллельно, поскольку запросы в очереди могут быть взаимозависимыми и, следовательно, зависимыми от порядка. Например, если у нас есть действия по созданию и обновлению и генерации идентификатора на сервере - мы должны обновить все полезные данные после сохранения. Если какой-либо запрос не удался - мы продолжаем повторять его.
- Создайте одно обновление мегаметод , например
/merge или /batchUpdate на стороне сервера, которое по существу принимает список обновлений или diff и применяет их. Это. Преимуществами здесь являются транзакционность, меньше запросов и меньше нагрузки на сервер, меньше обновлений БД. Но это действительно формирует API. Если я хочу, чтобы этот подход был последовательным в приложении - я получу кучу этих мегаметодов , и я боюсь, что это не очень хороший чистый API (что бы ни означало это субъективное утверждение).
Существуют ли передовые практики или стандартные решения для подобных задач?