SSR: когда, зачем и для чего. На примере Vue

Доброго.

Если я правильно понял вопрос, то есть возможность использовать nuxtServerInit action. В документации, как раз похожий пример есть:

actions: {
  async nuxtServerInit({ dispatch }) {
    await dispatch('core/load')
  }

  // ...
}

Действие nuxtServerInit вызывается только на сервере. В свою очередь в нем мы можем
вызвать другие необходимые нам события, содержащие обращения к API, и вызывающие мутация нашего store.

Данные, соответственно будут лежать в store, а не локально в компоненте.

SSR: когда, зачем и для чего. На примере Vue

СтрадатьНа самом деле зависит от многих факторов и от того, чего вы хотите добиться. В простейшем случае, можно оставить серверный рендеринг на PHP, а также выставить дублирующие API ендпоинты. Страница отрендерилась, клиентский фреймворк дальше работает как SPA, обращаясь к API. Но в этом случае придется дублировать как контроллеры на сервере, ведь нужно возвращать как сырые данные, так и полностью отрендеренную страницу, а также поддерживать клиентское приложение.
В целом, если нет понимания что делать, лучше оставить как есть.

SSR: когда, зачем и для чего. На примере Vue

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

Админка, в которой происходит редактирование контента, на основе этих ключей производила сброс кеша.

Например, пост мог быть помечен `post/425053 posts channel/vuejs tag/ssr tag/vue`. Разные ключи необходимы, потому что один и тот же пост может быть показан как на детальной странице, так и в списке постов на главной, в списке канала или по тегу.