Size: a a a

Архитектура ИТ-решений

2020 November 29

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Вы говорите про state приложение и его кэширование. Я говорю про кэширование отдаваемого содержимого. Сравните сложность решение с (готовым) кэшем между клиентом и сервером, и подключение распределенного кэша и его нормальное использование.
Плюс кэш перед приложением экономит ресурсы приложения.
источник

SB

Sergey Bezrukov in Архитектура ИТ-решений
Leonid Vygovskiy
Вы говорите про state приложение и его кэширование. Я говорю про кэширование отдаваемого содержимого. Сравните сложность решение с (готовым) кэшем между клиентом и сервером, и подключение распределенного кэша и его нормальное использование.
Плюс кэш перед приложением экономит ресурсы приложения.
Если нужен кэш "между клиентом и сервером", то достаточно адекватно отдавать заголовки Cache-Control и любой настроенный на кэширование хттп прокси закеширует контент (например nginx - https://nginx.org/ru/docs/http/ngx_http_proxy_module.html).
Правда тут сразу возникают практические нюансы:
1. Один и тот же URL может выдавать разный контент разным пользователям (надо учитывать аутентификацию)
2. В общем случае вы не можете адекватно предсказать когда отданный контент утратит актуальность.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Насколько я понимаю REST, то как раз могу.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
В правильно разработанном приложении.
источник

SB

Sergey Bezrukov in Архитектура ИТ-решений
Ну а как вы предскажете это, практически?  Вот есть условный ФБ, есть мегапопулярный URL "моя лента".  Допустим мы даже не касаемся вопросов аутентификации, пусть этот URL у всех пользователей разный (типа /{user_id}/my) и реально аутентификацию в кэше не проверяем.
Как вы закешируете такой контент "между клиентом и сервером"?  Кто-то написал пост, это изменяет ленты у большого числа пользователей (а у ещё большего ничего не изменяет).   Вы же не можете предсказать когда это произойдёт.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Ну так вы описываете не rest приложение и спрашиваете меня, как применить rest подходы :)
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Leonid Vygovskiy
Ну так вы описываете не rest приложение и спрашиваете меня, как применить rest подходы :)
Вопрос выше не зависитот того, рест приложение или нет.
Есть кеш уровня приложения, и там есть контроль над инвалидацией этого кеша.
Например, закешировалась лента новостей для пользователя. Когда появился новый пост, приложение для этом знает и инициирует инвалидацию кеша.
А случае, если кеш вне приложения, гдето ближе к пользователю, то начинаются всякие проблемы - вопрос с доступом, вопрос с инвалидацией.
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Представим, что у меня был доступ к документу, я его запросил, и он закешировался где то перед приложением.
А потом у меня этот доступ отобрали. Но кеш не знает об этом, и я все равно смогу получить этот документ.
Неприятная ситуация.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Если у меня стоит классика и все ресурсы изменяются только через http снаружи и независимы друг от друга - то такой проблемы нет. Не для всех приложений подходит "чистый" rest. Начать с того, что там клиент stateless.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Peter Tugolukov
Представим, что у меня был доступ к документу, я его запросил, и он закешировался где то перед приложением.
А потом у меня этот доступ отобрали. Но кеш не знает об этом, и я все равно смогу получить этот документ.
Неприятная ситуация.
Ну так я хочу умный кэш. Чтобы я мог настроить сброс get entity/id по разным критериям. Которые получаем только из http
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
В чем с этим проблема?
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
В поиске такого умного кэша.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Мне только varnish в голову приходит.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Кэш - это не основа REST. Это один из необязательных компонентов реализации.

Кэш должен оправдывать своё существование. Он нужен обычно когда требуется интенсивное чтение одних и тех объектов.
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Leonid Vygovskiy
Мне только varnish в голову приходит.
Чем редис не подошел?
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Тем, что руками инвалидировать надо?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Leonid Vygovskiy
В поиске такого умного кэша.
Умным может быть агент, который отвечает за инвалидацию. То есть ваш код.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Peter Tugolukov
Тем, что руками инвалидировать надо?
Я могу его поставить между браузером и приложением?
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Я хочу не такого умного агента ))
Задача-то проста. Если пришел POST/PUT/... на /entity, то инвалидировать кэш на GET /entity.*?
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Мне казалось, что это прям где-то готовое должно быть и при опеределенных условиях сильно снижать нагрузку на приложение.
источник