Отдельные динамические и статические части сервиса REST - PullRequest
0 голосов
/ 12 ноября 2018

Представьте, что у нас есть большой список продуктов, которые взяты из базы данных, преобразованы в массив и возвращены в виде JSON.

Большинство полей продукта являются статическими - они редко меняются, поэтому мы хотим кэшировать этот JSON.

Проблема в том, что мы не можем кэшировать значения некоторых полей.

Например:

  1. Логический флаг is_favorite (который есть у каждого товара) зависит от того, какой пользователь запрашивает список товаров.
  2. views_count Номер обновляется каждый раз при просмотре продукта

Так как же нам разделить динамический и статический контент для таких случаев?

1 Ответ

0 голосов
/ 12 ноября 2018

is_favorite и views_count - это, по сути, метаданные о продукте, которые не имеют никакого отношения к реальному продукту.

Если у вас есть, скажем, продукт Book, он будет иметь title, author, isbn, no_of_pages, genre, которые присущи самой книге. Независимо от контекста, в котором используется книга, эти атрибуты не изменятся. Книга может существовать отдельно от этих атрибутов. Если они оба равны нулю, это ничего не значит для продукта. Ноль может что-то значить для кого-то другого, например, маркетолога, но существование книги не зависит от этих двух атрибутов. Атрибуты, которые свойственны существованию книги, могут быть кэшированы, как если бы они изменились, это новая книга.

is_favorite - это пользовательский контекст, а views_count - это глобальный контекст. price, например, рыночный контекст. Все эти атрибуты различаются и, возможно, не должны кэшироваться (возможно, price может кэшироваться в течение некоторого периода времени).

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

Возможной реализацией может быть кэширование локальной копии книги и управление пользовательским интерфейсом из кэшированной версии, а не вызов конечных точек при каждом запросе пользователя. Внутренние атрибуты не изменятся, поэтому вам нужно всего лишь один раз получить их и прочитать из кеша. is_favorite является частью вашего приложения, поэтому вам не нужно читать его с конечной точки после первой книги GET. Если пользователь делает книгу любимой, обновите кэшированную книгу и также PUT ту информацию, где она должна быть. Отдельное задание может запрашивать конечную точку views_count и периодически обновлять кэшированную книгу. Таким образом, приложение полагается на кэшированную книгу для выполнения своей работы. Любые обновления от пользователя, такие как превращение его в избранное, приводят к исходящим PUT запросам к API и записи в кэшированную книгу. Вам не нужно GET конечную точку для is_favorite, поскольку ваше приложение в первую очередь создает эту информацию.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...