По поводу await - да, соглашусь: выглядит избыточно.
Аналоги. Признаюсь, не смотрел. Наверное, одной из идей этой статьи было желание обратить внимание читателя на возможности "залезания под капот" большим пакетам и на примере показать, как это можно сделать. Если говорить про конкретный аналог, который Вы привели, то вижу там уязвимость в том, что важная часть ключа кэша может быть потеряна, потому что автор решения не включает туда наименование операции ( count может быть спутан с find), а так же игнорируются опции запроса( например, limit), что негативно скажется на тех же пагинированных запросах.
А теперь про "самое главное" :) Инвалидация кэша - тема вообще очень холиварная. Все-таки это очень сильно упирается в особенности системы, которую Вы разрабатываете, поэтому сложно дать конкретную рекомендацию, будь то таймер или поднятие эвента на сброс. В этом случае стоит рассматривать эту статью, как некий вводный материал.
Приветствую. Рассматривается кейс, что данные меняются с течением времени. Для этого существуют различные механизмы инвалидации кэша, но это отдельная тема. По поводу пользователей. Тут зависит от того, как Вы формируете страницу. Если, например, Вы запрашиваете страницу вида profile/123, то тут все будет работать идеально - идентификатор отлично подойдет для кэширования. В иных случаях, например, в варианте /dashboard можно расширить состав ключа, до кук и иных косвенных параметров, ведь Вы имеете полный доступ к содержимому реквеста. Данный пример - лишь шаблон, по которому Вы можете строить свою систему кэширования. Если под билдом Вы подразумеваете сборку приложения, то после каждой поставки новой версии приложения необходимо будет сбрасывать кэш полностью. Если под билдом Вы понимаете фазу сборки страницы, то при изменении данных Вам необходимо будет сбросить кэш, тогда при следующем запросе страница будет пересобрана и заново закэширована.
Богдан, добрый день. Здесь речь идет больше о SSR рендеринге, а не SSG.
Во-первых, тут решается проблема горизонтального скейлинга. Все инстансы вашего приложения будут смотреть в одну точку, вместо генерации локального стейта.
Как это почувствовать? При прямом заходе на страницу весь "подкапотный" рендеринг будет проигнорирован, и пользователь получит данные напрямую из Redis.
Во-вторых, Вы получите огромный плюс при переходах за счет кэширования json файлов, которые под капотом используются ( и фетчат данные ) при навигации
Добрый день. Данное решение использует особенности JS и написанных под него пакетов, поэтому - да, применимо только в рамках NodeJS.
Добрый день.
По поводу await - да, соглашусь: выглядит избыточно.
Аналоги. Признаюсь, не смотрел. Наверное, одной из идей этой статьи было желание обратить внимание читателя на возможности "залезания под капот" большим пакетам и на примере показать, как это можно сделать. Если говорить про конкретный аналог, который Вы привели, то вижу там уязвимость в том, что важная часть ключа кэша может быть потеряна, потому что автор решения не включает туда наименование операции ( count может быть спутан с find), а так же игнорируются опции запроса( например, limit), что негативно скажется на тех же пагинированных запросах.
А теперь про "самое главное" :) Инвалидация кэша - тема вообще очень холиварная. Все-таки это очень сильно упирается в особенности системы, которую Вы разрабатываете, поэтому сложно дать конкретную рекомендацию, будь то таймер или поднятие эвента на сброс. В этом случае стоит рассматривать эту статью, как некий вводный материал.
Приветствую. Рассматривается кейс, что данные меняются с течением времени. Для этого существуют различные механизмы инвалидации кэша, но это отдельная тема. По поводу пользователей. Тут зависит от того, как Вы формируете страницу. Если, например, Вы запрашиваете страницу вида profile/123, то тут все будет работать идеально - идентификатор отлично подойдет для кэширования. В иных случаях, например, в варианте /dashboard можно расширить состав ключа, до кук и иных косвенных параметров, ведь Вы имеете полный доступ к содержимому реквеста. Данный пример - лишь шаблон, по которому Вы можете строить свою систему кэширования. Если под билдом Вы подразумеваете сборку приложения, то после каждой поставки новой версии приложения необходимо будет сбрасывать кэш полностью. Если под билдом Вы понимаете фазу сборки страницы, то при изменении данных Вам необходимо будет сбросить кэш, тогда при следующем запросе страница будет пересобрана и заново закэширована.
Богдан, добрый день. Здесь речь идет больше о SSR рендеринге, а не SSG.
Во-первых, тут решается проблема горизонтального скейлинга. Все инстансы вашего приложения будут смотреть в одну точку, вместо генерации локального стейта.
Как это почувствовать? При прямом заходе на страницу весь "подкапотный" рендеринг будет проигнорирован, и пользователь получит данные напрямую из Redis.
Во-вторых, Вы получите огромный плюс при переходах за счет кэширования json файлов, которые под капотом используются ( и фетчат данные ) при навигации