Оффлайн брокер на JavaScript

[@bulavin]

Хочу картинки

[@RuGrof]

Возможно где-то должен появится axios-retry. И странно, почему часть с «пропажей интернета»,

не в рамках данной статьи

.

[@dastanaron_dev]

Не совсем понял о чем речь, но если это про обработчик ошибки, то он не относится к самому «Брокеру», ошибки мы можем обрабатывать как угодно, а я делаю упор на описание функционала именно брокера. Но если интересно, есть такой вариант. Можно передать в качестве аргумента, обхект текущего контекста в котором мы работаем, например VueObject или подобное. Тогда в нем будет работать все то, что работает в конкретном Vue-компоненте, и можно сделать что-то подобное:

VueObject.$store.commit('AlertError', 'Ошибка получения данных с сервера');

Я проверял такое работает, но как то архитектурно не красиво, имхо. В своем проекте пока сам не придумал, как сделать лучше. Но нужно учитывать, что у меня есть компоненты Vue, есть Vuex (Vue-store) и т.п. поэтому это подходит моему проекту, а другому уже не пойдет, поэтому и не подходит в рамках общей статьи об идее создания такого брокера, который должен работать не зависимо от библиотеки или фреймворка. Я привожу лишь примеры использования в рамках Vue, потому что очень схоже будет и в React и возможно в Angular( это не точно, я не знаю ангуляр)

[@Hacksli]

Работаю с проектом облачной кассы, там используем синхронизацию продаж (чеков). Сначала на этапе зарождения был написан простой скрипт который каждую секунду проверяет наличие данных в хранилище и если есть то отправляет, единственное что отличается от Вашего варианта так это то что все чеки сразу попадают этому брокеру, а не как Вы описали что только не успешные. Далее спустя некоторое время начали замечать что данные теряются, сначала не могли понять почему, и этот комментарий я поэтому и пишу чтобы Вы учли эти моменты. 1) и очень важный момент это не отправлять повторный запрос не дождавшись ответа предыдущего так как при подвисании интернета иногда запросы подвисают на долго и это плодит целую кучу новых запросов, в идеальных условиях отдела разработки конечно такого не было. 2) каждый чек должен иметь свой идентификатор и сервер должен вернуть список который он принял только после этого удалять задания и только те которые принял сервер.

Очень тонкий момент происходил при затупе интернета. Допустим есть 2 чека в заданиях — они уходят на сервер, запрос подвис, в это время совершилась третья продажа и она допустим тоже сразу в догонку пошла на сервер не дождавшись ответа предыдущего и эта третья не смогла синхронизироваться, а первая смогла и затёрла из хранилища все задания. Вот так и происходила потеря данных.

[@dastanaron_dev]

Спасибо, это очень дельное замечание. У меня не так уж и страшно конечно, что что то пойдёт не так, но для такого проекта как кассы это действительно критично. Подумаю, что можно сделать

[@Taraflex]

Не смотрели в сторону pouchdb.com?

[@dastanaron_dev]

Слышал про него. Но что-то не подумал. Изучу подробнее, спасибо!

[@1x1]

Отсутствует самое важное — решение конфликтов. Слишком легко можно переписать обновившиеся данные старыми.

[@dastanaron_dev]

Не обязательно. Я не показываю, что у меня в дата. А там может быть отметка времени например. Это уже от реализации. И если на беке данные по метке новее, чем в присылаешь запросе, значит даём положительный ответ на запрос, Т. Е. Код 200, можно даже с сообщением, о том, что на сервере данные новее и не перезаписываем их.

[@kellas]

Можно еще хранить данные в indexedDB, т.к. к ней есть доступ из service-worker, как обертка идеально подходит Dexie.
Записывать действия юзера не сразу в БД, а в виде «тасков» на отправку, при наличии соединения отсылать их на сервер.