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

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

Дополнительно:

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

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

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

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

    Ответы:

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

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

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

    • "Архитектура приложения разве может быть универсальной?" -- то есть типов нет, в зависимости от конкретной задачи пишут по разному? Если есть задача сделать автономное приложение?
    • Евгений Блинков,
      Сколько пользователей у приложения?
    • Евгений Блинков, приложение что-то делает, а не просто является автономным.
    • Иерокопус Таманский, один и много) Все, кто зарегистрируется.
    • dollar, Да, разумеется, задавая этот вопрос я предполагал, что этими путями кто-то уже ходил и существуют какие-то испытанные способы решения проблемы создания автономного веб-приложения. Я думал, что я просто по тупости своей не могу найти ответ. Вот там внизу ответили про Offline first, это похоже на то, что я хотел, но неужели это всё?
    • Да, все сильно зависит именно от концепции самого приложения.
      Если это что-то типа записной книжки - оно может и автономно работать, сеть нужна только как бекап и центральное хранилище для синхронизации с другими девайсами.
      А если это что-то связанное с деньгами или коммерческими сервисами - такое автономно работать в большинстве случаев не способно, т.к. для автономной работы потребуются закрытые данные, которые никто, в здравом уме, на клиент выгружать не будет.
      Сама по себе поддержка автономности требует серьезных дополнительных затрат: больше логики, больше кода, синхронизации, и нередко еще с наворотами. Много чего нужно продумывать: часть сущностей могут быть полностью автономны, часть только частично, а часть вообще не могут быть автономны, и приложение должно учитывать взаимосвязь таких сущностей и ситуации когда они становятся недоступны полностью или частично - это целая гора логики.
      Так что в большинстве случаев автономность не реализуют, если это не является основой функционала приложения. Максимум, так это хранят автономно какие-нибудь данные неавторизованных пользователей, короткое время, просто на случай если пользователь что-то сделает на сайте, важное для продаж, а потом зарегистрируется/авторизуется - например добавит товар в корзину или избранное/сравнение, что приближает его к моменту покупки, и потеря чего после авторизации может доставить негатива, что может стать поводом отказаться от покупки. Причем изрядная доля автономности таких сайтов обеспечивается браузерными кешами.

    + Заказать

     

    Для решения данной проблемы вы можете воспользоваться услугами фрилансеров. Мы выполним необходимую работу быстро и качественно.

     

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

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

      1. Определите требования проекта: Прежде всего, вам необходимо понять, какие функциональные и нефункциональные требования предъявляются к вашему веб-приложению. Это поможет определить, какой уровень масштабируемости, безопасности, производительности и гибкости вам необходим.

      2. Изучите различные типы архитектур: Существует несколько популярных типов архитектур для веб-приложений, таких как монолитная, микросервисная, серверless и др. Каждая из них имеет свои преимущества и недостатки, поэтому важно изучить каждый вариант и выбрать тот, который лучше всего подходит для вашего проекта.

      3. Рассмотрите масштабируемость и гибкость: Если ваше веб-приложение должно быть масштабируемым и гибким, то, возможно, стоит обратить внимание на микросервисную архитектуру. Она позволяет разбить приложение на небольшие независимые сервисы, что упрощает масштабирование и обновление.

      4. Обратите внимание на безопасность: Безопасность играет ключевую роль в разработке веб-приложений. При выборе архитектуры убедитесь, что она обеспечивает надежную защиту от угроз, таких как SQL-инъекции, XSS и CSRF атаки.

      Пример использования

       для отображения кода:
 
<pre lang="php">
function helloWorld() {
    echo "Hello, World!";
}
helloWorld();

      Следуя этим рекомендациям и учитывая особенности вашего проекта, вы сможете выбрать наиболее подходящую архитектуру для вашего автономного веб-приложения.

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