Как выбрать архитектуру автономного веб-приложения?

Question

[Евгений Блинков]

Думаю о создании полностью автономного веб-приложения. Есть идея создать полную копию бд на indexedDB и если есть связь брать данные с сервера, а если связи нет - из indexedDB. А потом, когда интернет появится, синхронизировать бд на сервере с бд на клиенте. Вопрос в том насколько это разумно, есть ли другие варианты? Может быть у такой схемы есть название (вряд ли мне в голову первому это пришло). Нагуглить не получилось.

Comments

[Refguser]

ИМХО надо немного не так - всегда работаешь с локальной базой, а когда есть связь - синхронизируешь.

[Mikhail Osher]

Не смог найти статью на Хабре, и думаю, их немало. Почитайте про подводные камни service workers и pwa в целом.
Там сплошной ад на аде.

[Евгений Блинков]

Mikhail Osher, Да, я, таки, читал, со многими проблемами сталкивался, я потому и задал этот вопрос, что на деле все эти статьи - вершина айсберга. Но несмотря на это тема очень интересная, буду копать дальше

Answer 1

[tyxeo]

здесь это описано: https://habr.com/ru/articles/160477/

не используй indexedDB - это неудобно
используй библиотеку localForage https://habr.com/ru/companies/nordavind/articles/2...

Answer 2

[dollar]

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

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

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

Comments

[Евгений Блинков]

"Архитектура приложения разве может быть универсальной?" -- то есть типов нет, в зависимости от конкретной задачи пишут по разному? Если есть задача сделать автономное приложение?

[Everything_is_not_so_bad]

Евгений Блинков,
Сколько пользователей у приложения?

[dollar]

Евгений Блинков, приложение что-то делает, а не просто является автономным.

[Евгений Блинков]

Иерокопус Таманский, один и много) Все, кто зарегистрируется.

[Евгений Блинков]

dollar, Да, разумеется, задавая этот вопрос я предполагал, что этими путями кто-то уже ходил и существуют какие-то испытанные способы решения проблемы создания автономного веб-приложения. Я думал, что я просто по тупости своей не могу найти ответ. Вот там внизу ответили про Offline first, это похоже на то, что я хотел, но неужели это всё?

[0x131315]

Да, все сильно зависит именно от концепции самого приложения.
Если это что-то типа записной книжки - оно может и автономно работать, сеть нужна только как бекап и центральное хранилище для синхронизации с другими девайсами.
А если это что-то связанное с деньгами или коммерческими сервисами - такое автономно работать в большинстве случаев не способно, т.к. для автономной работы потребуются закрытые данные, которые никто, в здравом уме, на клиент выгружать не будет.
Сама по себе поддержка автономности требует серьезных дополнительных затрат: больше логики, больше кода, синхронизации, и нередко еще с наворотами. Много чего нужно продумывать: часть сущностей могут быть полностью автономны, часть только частично, а часть вообще не могут быть автономны, и приложение должно учитывать взаимосвязь таких сущностей и ситуации когда они становятся недоступны полностью или частично - это целая гора логики.
Так что в большинстве случаев автономность не реализуют, если это не является основой функционала приложения. Максимум, так это хранят автономно какие-нибудь данные неавторизованных пользователей, короткое время, просто на случай если пользователь что-то сделает на сайте, важное для продаж, а потом зарегистрируется/авторизуется - например добавит товар в корзину или избранное/сравнение, что приближает его к моменту покупки, и потеря чего после авторизации может доставить негатива, что может стать поводом отказаться от покупки. Причем изрядная доля автономности таких сайтов обеспечивается браузерными кешами.