Универсален ли такой объект для сохранения/чтения данных на сервере?

Question

[true]

взяв идею из этой статьи на хабре - https://habr.com/ru/post/160477/
я сделал такой обьект и вот что получилось:

две основные функции:
отправить_данные_на_сервер( функция_обрабатывающая_ответ )
получить_данные_от_сервера( функция_обрабатывающая_ответ )



обе функции возвращают ответ сервера в функция_обрабатывающая_ответ

если не получилось отправить данные на сервер то они сохраняются в очередь заданий и отправляются позднее автоматически при document.ononline или при перезагрузке приложения

полученные от сервера данные сохраняются в локальном хранилище
при оффлайне производится попытка получить ранее полученные и сохраненные в хранилище данные

- это краткое описание API этого объекта

Comments

[Dmitry Bay]

по статьям 2012 года учитесь?)

[true]

Dmitry Bay, ты заметил дату!?

[Dmitry Bay]

true, а там еще комментарии есть.
Да и с тех пор столько вещей приятных случилось в мире js.

[true]

Dmitry Bay, при чем здесь js?
тут об архитектуре речь
любое приложение работающее с сервером может работать так

[Dmitry Bay]

true,

при чем здесь js?

При том, что вы его указали как тег к вопросу)))

Вы сейчас тут react с redux изобретете. Я вам говорю - посмотрите дату статьи.

p.s. Блядство, видел ваши посты ранее, вы просто троль.

[true]

Dmitry Bay, просто не отвечай в моих вопросах
твое мнение мне не интересно

[Модератор]

true, Можно просто игнорировать неинтересные вам вопросы, ответы и комментарии. Если они нарушают правила, используйте функционал жалоб. Грубить и заниматься самомодераторством не стоит.

[DevMan]

Модератор, игнорировать неинтересные вам вопросы ответы.

Answer 1

[Saboteur]

Нет, не универсален.
Тут слишком невнятный и грубый каркас, а ведь все зависит от реализации функций.

Чтобы не выглядеть голословным, вместо того, чтобы реализовывать очередь в своей фунции, возможно вместо сервера по ту сторону должен стоять брокер сообщений, который возьмет это на себя.
А с другой стороны, может быть вам нужна именно локальная очередь для длительных даунтаймов.

Зависит от того, что нужно приложению.

Comments

[true]

мне нужно то что в этой статье

при этом на сервере достаточно простое api получается

[Saboteur]

Ну опять таки - что ты подразумеваешь под универсальностью.

Вот смотри если у тебя приложение не на телефоне или десктопе пользователя, а какой-то бэкенд сервис на твоем сервере. В этом случае ты можешь на том же сервере рядом запустить брокер сообщений и работать через него.
А брокер сообщений уже и возьмет на себя заботу о том, чтобы связаться с удаленным сервисом, а пока нет связи, хранить все сообщения персистемно.
И при этом функционал брокера мягко говоря мощнее, надежнее и функциональнее, чем ты можешь накидать даже за месяц работы.

[true]

Saboteur, нет у меня другой принцип

как в этой статье
у меня клиент толстый
а сервер очень тонкий

у меня там тупейшие функции короткие

сервер исполняет только одну роль - хранение и чтение данных

но к тому что я сделал надо еще добавить сокеты и sse