Как выбрать архитектуру автономного веб-приложения?
Думаю о создании полностью автономного веб-приложения. Есть идея создать полную копию бд на indexedDB и если есть связь брать данные с сервера, а если связи нет - из indexedDB. А потом, когда интернет появится, синхронизировать бд на сервере с бд на клиенте. Вопрос в том насколько это разумно, есть ли другие варианты? Может быть у такой схемы есть название (вряд ли мне в голову первому это пришло). Нагуглить не получилось.
Дополнительно:
ИМХО надо немного не так - всегда работаешь с локальной базой, а когда есть связь - синхронизируешь.
Там сплошной ад на аде.
здесь это описано: https://habr.com/ru/articles/160477/
не используй indexedDB - это неудобно
используй библиотеку localForage https://habr.com/ru/companies/nordavind/articles/2...
Ответы:
Архитектура приложения разве может быть универсальной? Она зависит от самого приложения. Автономность - это скорее отдельное свойство архитектуры, чем ее стержень, но опять же зависит от конкретной задачи.
Например, если это приложение для ресторана, то логично предположить, что в какой-то момент у юзера может не быть связи или кончились деньги на телефоне. И если до этого удалось успеть загрузить номер заказа через WiFi, которого уже нет, то с этой информацией всё равно можно работать. Как именно - вопрос уже скорее дизайна, чем архитектуры. В противовес этому можно не заморачиваться и показывать заглушку о недоступности Интернета, но это будет бесить некоторых клиентов.
С базой данной сложнее, конечно же. В идеале стоит дать пользователю контролировать, что именно он хочет хранить локально. Но если данных не так уж и много (больше 5 Мб, но не гигабайты), то можно и всю базу скопировать, а потом обновлять ее. Возможно, стоит сделать упор на то, как обновлять базу мелкими патчами, если это делается часто, либо тупо перезагружать всю базу заново, если это делается редко. В общем, повторюсь, архитектура и ее детали зависят от задачи, и автономность это, скорее всего, всего лишь одна фича из многих.
- "Архитектура приложения разве может быть универсальной?" -- то есть типов нет, в зависимости от конкретной задачи пишут по разному? Если есть задача сделать автономное приложение?
- Евгений Блинков,
Сколько пользователей у приложения? - Евгений Блинков, приложение что-то делает, а не просто является автономным.
- Иерокопус Таманский, один и много) Все, кто зарегистрируется.
- dollar, Да, разумеется, задавая этот вопрос я предполагал, что этими путями кто-то уже ходил и существуют какие-то испытанные способы решения проблемы создания автономного веб-приложения. Я думал, что я просто по тупости своей не могу найти ответ. Вот там внизу ответили про Offline first, это похоже на то, что я хотел, но неужели это всё?
- Да, все сильно зависит именно от концепции самого приложения.
Если это что-то типа записной книжки - оно может и автономно работать, сеть нужна только как бекап и центральное хранилище для синхронизации с другими девайсами.
А если это что-то связанное с деньгами или коммерческими сервисами - такое автономно работать в большинстве случаев не способно, т.к. для автономной работы потребуются закрытые данные, которые никто, в здравом уме, на клиент выгружать не будет.
Сама по себе поддержка автономности требует серьезных дополнительных затрат: больше логики, больше кода, синхронизации, и нередко еще с наворотами. Много чего нужно продумывать: часть сущностей могут быть полностью автономны, часть только частично, а часть вообще не могут быть автономны, и приложение должно учитывать взаимосвязь таких сущностей и ситуации когда они становятся недоступны полностью или частично - это целая гора логики.
Так что в большинстве случаев автономность не реализуют, если это не является основой функционала приложения. Максимум, так это хранят автономно какие-нибудь данные неавторизованных пользователей, короткое время, просто на случай если пользователь что-то сделает на сайте, важное для продаж, а потом зарегистрируется/авторизуется - например добавит товар в корзину или избранное/сравнение, что приближает его к моменту покупки, и потеря чего после авторизации может доставить негатива, что может стать поводом отказаться от покупки. Причем изрядная доля автономности таких сайтов обеспечивается браузерными кешами.
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Для выбора архитектуры автономного веб-приложения, вам следует учитывать несколько ключевых факторов, которые помогут определить наиболее подходящий вариант для вашего проекта. Вот несколько рекомендаций по выбору архитектуры:
1. Определите требования проекта: Прежде всего, вам необходимо понять, какие функциональные и нефункциональные требования предъявляются к вашему веб-приложению. Это поможет определить, какой уровень масштабируемости, безопасности, производительности и гибкости вам необходим.
2. Изучите различные типы архитектур: Существует несколько популярных типов архитектур для веб-приложений, таких как монолитная, микросервисная, серверless и др. Каждая из них имеет свои преимущества и недостатки, поэтому важно изучить каждый вариант и выбрать тот, который лучше всего подходит для вашего проекта.
3. Рассмотрите масштабируемость и гибкость: Если ваше веб-приложение должно быть масштабируемым и гибким, то, возможно, стоит обратить внимание на микросервисную архитектуру. Она позволяет разбить приложение на небольшие независимые сервисы, что упрощает масштабирование и обновление.
4. Обратите внимание на безопасность: Безопасность играет ключевую роль в разработке веб-приложений. При выборе архитектуры убедитесь, что она обеспечивает надежную защиту от угроз, таких как SQL-инъекции, XSS и CSRF атаки.
Пример использования
для отображения кода: <pre lang="php"> function helloWorld() { echo "Hello, World!"; } helloWorld();
Следуя этим рекомендациям и учитывая особенности вашего проекта, вы сможете выбрать наиболее подходящую архитектуру для вашего автономного веб-приложения.