Комментарии 5
Неплохо было бы обозначить, для чего это надо, поскольку в nextjs из коробки есть сразу несколько решений, которые делают практически то же самое:
- static html export - для получения полностью статической версии сайта
- automatic static optimization - для генерирования статических страниц с возможностью подгрузки новых данных после загрузки страницы.
Конечно, они работают без Redis, но я не понимаю, для чего необходимо делать лишний round-trip по сети для отображения статических ресурсов.
Богдан, добрый день. Здесь речь идет больше о SSR рендеринге, а не SSG.
Во-первых, тут решается проблема горизонтального скейлинга. Все инстансы вашего приложения будут смотреть в одну точку, вместо генерации локального стейта.
Как это почувствовать? При прямом заходе на страницу весь "подкапотный" рендеринг будет проигнорирован, и пользователь получит данные напрямую из Redis.
Во-вторых, Вы получите огромный плюс при переходах за счет кэширования json файлов, которые под капотом используются ( и фетчат данные ) при навигации
Добрый день,
Немного не улавливаю решение. Если данные не зависят от того, кто их запрашивают и не меняются с течением времени, почему не использовать SSG? А если все же данные зависят от пользователя, который их запрашивает, то будет ли такое решение работать верно?
Так же будет ли это решение работать верно, после очередного билда? Когда содержимое страницы обновится, но в качестве ключа кэша мы используем лишь ссылку к странице, не учитывая версию билда?
Приветствую. Рассматривается кейс, что данные меняются с течением времени. Для этого существуют различные механизмы инвалидации кэша, но это отдельная тема. По поводу пользователей. Тут зависит от того, как Вы формируете страницу. Если, например, Вы запрашиваете страницу вида profile/123, то тут все будет работать идеально - идентификатор отлично подойдет для кэширования. В иных случаях, например, в варианте /dashboard можно расширить состав ключа, до кук и иных косвенных параметров, ведь Вы имеете полный доступ к содержимому реквеста. Данный пример - лишь шаблон, по которому Вы можете строить свою систему кэширования. Если под билдом Вы подразумеваете сборку приложения, то после каждой поставки новой версии приложения необходимо будет сбрасывать кэш полностью. Если под билдом Вы понимаете фазу сборки страницы, то при изменении данных Вам необходимо будет сбросить кэш, тогда при следующем запросе страница будет пересобрана и заново закэширована.
если запустить в cluster, или multi-worker, без базы никак. cache будет разница.
Как сконфигурировать NextJS сервер с полной поддержкой кэширования в Redis