От веб-приложения, зависящего от сети, до веб-приложения, независимого от сети

Question

Я веб-разработчик с полным стеком, и в настоящее время я в основном создаю одностраничное приложение, используя внешний интерфейс, такой как angular, и внутренний интерфейс, такой как весенняя загрузка.

Обычно дизайн моего веба Приложение (допустим, это CRUD) выглядит следующим образом: допустим, я на странице обновления и обновляю сущность. Затем делается запрос к бэкэнду, который обновляет сущность в базе данных. Когда бэкэнд отвечает, что все в порядке, ваша сущность обновлена ​​(код состояния 200). Я go перехожу на следующую страницу, которая является страницей чтения с URL-адресом, таким как entityName/{id}, где я передаю идентификатор сущности следующей страница через URL. Затем на странице чтения я получаю этот идентификатор, делаю запрос к бэкэнду, извлекаю данные сущности и отображаю их.

Проблема возникает, когда пользователь теряет связь с inte rnet, поэтому запрос к бэкэнду не может быть сделано, и, следовательно, данные не могут быть отображены в пользовательском интерфейсе или обновлены.

Другой дизайн будет таким: я на странице обновления, и я обновляю свою сущность. Запрос сделан к бэкэнду, но также состояние сохраняется на стороне клиента. Допустим, соединение потеряно. Я все еще могу go прочитать страницу и отобразить обновленный объект. Более того, поскольку состояние / данные хранятся на стороне клиента, мне не нужно делать второй запрос к бэкэнду, чтобы получить сущность из идентификатора, поскольку сущность живет на стороне клиента. В течение времени, потраченного пользователем на приложение, соединение возвращается, и на сервер поступает запрос на обновление данных для синхронизации данных в БД и на стороне клиента.

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

Я очень хорошо знаю, что используется первый подход , Я развиваюсь так, и вот мой вопрос: Возможно ли go от первого проекта до второго дизайна и если да, то с какими технологиями?

Что бы я сделал для реализации Вторым вариантом будет обмен данными между компонентами с использованием сервисов (при реализации с angular). Таким образом, состояние приложения может быть сохранено на стороне клиента. Но, может быть, есть лучший способ. Я слышал о библиотеке NgRx для управления состоянием приложения. Это правильный способ go управлять состоянием приложения на стороне клиента?

Также существует вторая проблема, которая заключается в том, чтобы убедиться, что запросы, которые не могли быть сделано, когда связь была потеряна, сделана, когда связь вернулась. И вот я задаюсь вопросом: Можно ли использовать инструмент, позволяющий ставить в очередь запросы и перезапускать их при восстановлении соединения? У меня есть представление о прогрессивных веб-приложениях и сервис-работниках, но только понятие (как я знаю что работника службы можно использовать для кэширования данных, которыми обмениваются с сервером), и мне интересно, если это способ решить эту проблему?

Жду ваших комментариев к моему посту. Надеюсь, это было не слишком долго. Заранее спасибо.

Answer 1

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

Это полностью зависит от того, насколько вы можете доверять BE. Если по какой-либо причине возникает ошибка (истек срок действия / выписан? Данные обновлены на другом клиенте?), Этот подход может значительно усложниться.

Возможно ли go от первого проекта до второй дизайн и если да, то с какими технологиями?

Потенциально вы можете сделать ваше приложение PWA и использовать работников службы . Я нашел хорошее руководство для этого здесь . Если блог закрывается, он проходит через кеширование ресурсов и шрифтов в ngsw-config.json, а затем затрагивает кеширование API. Вот как может выглядеть окончательный результат:

{
  "$schema": "./node_modules/@angular/service-worker/config/schema.json",
  "index": "/index.html",
  "assetGroups": [
    {
      "name": "app",
      "installMode": "prefetch",
      "resources": {
        "files": [
          "/favicon.ico",
          "/index.html",
          "/manifest.webmanifest",
          "/*.css",
          "/*.js"
        ]
      }
    }, {
      "name": "assets",
      "installMode": "lazy",
      "updateMode": "prefetch",
      "resources": {
        "files": [
          "/assets/**",
          "/*.(eot|svg|cur|jpg|png|webp|gif|otf|ttf|woff|woff2|ani)"
        ]
      }
    }
  ],
  "dataGroups": [{
    "name": "api-freshness",
    "urls": [
      "/timeline"
    ],
    "cacheConfig": {
      "strategy": "freshness",
      "maxSize": 100,
      "maxAge": "3d",
      "timeout": "10s"
    }
  },
    {
      "name": "api-performance",
      "urls": [
        "/favorites"
      ],
      "cacheConfig": {
        "strategy": "performance",
        "maxSize": 100,
        "maxAge": "3d"
      }
    }
  ]
}

«Для стратегии, ориентированной на первую сеть, это свежесть, а для кэша - на производительность»

Это правильный способ go для управления состоянием приложения на стороне клиента?

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

Однако, если все, что вам нужно, это автономная функциональность, PWA будут чувствовать себя как путь к go.

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

Эта функция называется фоновым синхронизацией c и является функцией службы. работников. При этом, Я нашел этот открытый вопрос на нем. Вы можете попробовать это , но это похоже на взлом. Если бы это зависело от меня, я бы создал массив наблюдаемых, которые вызываются, когда соединение возвращается, пока не появится лучшая поддержка pwa для этого