S
Он не будет происходить раз в секунду сам по себе. Только после того, как пользователь будет заходить на страницу.
Size: a a a
2021 June 21
ТК
Ну типо если это новостной сайт? Где должен быть постоянно актуальный контент?
S
В любом случае пользователю будет отдаваться страница из кэша, что куда быстрее, чем генерация страницы на сервере с нуля каждый раз
S
ТК
Ох, если бы я так хорошо понимал английский)
ТК
Но все равно спасибо за ответ
S
В общем, getStaticProps + revalidate будет быстрее, кроме тех случаев, когда в getStaticPaths указан пустой массив путей и fallback: true - в этом случае для первого пользователя, который зайдёт на страницу, она будет грузиться по времени столько же, сколько и при GSSP. Но с учётом того, что сайт новостной, и пользователям всегда нужно видеть актуальную информацию, наверное есть смысл использовать GSSP. Иначе - часть пользователей будет видеть устаревшую инфу (из кэша), пока не обновит страницу
ТК
То есть revalidate, сам никогда не будет обновлять страницу после нового билда?
S
Он обновляет страницу на сервере только после того, как хотя бы один пользователь зайдёт на неё. При этом, первый пользователь получит старую страницу (из кэша), а новый уже новую
ТК
Понял, ещё раз большое спасибо)
🦜
Некоторые вообще строят в целом на этом архитектуру бекенда)
G
zeit/next.js
Pre-release v11.0.1-canary.6
### Documentation Changes
- Improve the
- add missing closing bracket: #26375
- Docs: Add Prettier section on ESLint page: #26347
- docs(router.md) Add note about page state and navigation: #26320
### Example Changes
- Update with-eslint example.: #25817
### Misc Changes
- Update create-next-app template favicons: #26289
- Remove period for ESLint
### Credits
Huge thanks to @pacocoursey, @leerob, @aksdevac, @araujogui, and @ijjk for helping!
Pre-release v11.0.1-canary.6
### Documentation Changes
- Improve the
next/script documentation.: #26325- add missing closing bracket: #26375
- Docs: Add Prettier section on ESLint page: #26347
- docs(router.md) Add note about page state and navigation: #26320
### Example Changes
- Update with-eslint example.: #25817
### Misc Changes
- Update create-next-app template favicons: #26289
- Remove period for ESLint
passHref docs link.: #26402### Credits
Huge thanks to @pacocoursey, @leerob, @aksdevac, @araujogui, and @ijjk for helping!
ОЗ
Всем привет! У меня вопрос следующего характера.
Есть проект интернет магазина. Бек на nestjs, в качестве фронта думаем использовать next.js для ssr. Сейчас думаем над конечной реализацией фронта, а именно как забирать данные с бека.
Нашел два метода:
- получать данные обращаясь к адресу бека по api, как указано в документации:
https://nextjs.org/docs/basic-features/data-fetching
- дергать сервис напрямую в методе getServerSideProps, как указано в примере из модуля "nest-next":
https://github.com/kyle-mccarthy/nest-next/blob/master/examples/basic/pages/views/blog/index.tsx
прошу поделиться опытом кто как делает и что лучше. Буду благодарен за помощь.
Есть проект интернет магазина. Бек на nestjs, в качестве фронта думаем использовать next.js для ssr. Сейчас думаем над конечной реализацией фронта, а именно как забирать данные с бека.
Нашел два метода:
- получать данные обращаясь к адресу бека по api, как указано в документации:
https://nextjs.org/docs/basic-features/data-fetching
- дергать сервис напрямую в методе getServerSideProps, как указано в примере из модуля "nest-next":
https://github.com/kyle-mccarthy/nest-next/blob/master/examples/basic/pages/views/blog/index.tsx
прошу поделиться опытом кто как делает и что лучше. Буду благодарен за помощь.
🦜
второй вариант это переезд некста в нест
🦜
я бы не советовал
ОЗ
вообще да, согласен. Но тут вопрос больше в скорости отдачи контента. Если использовать первый вариант, то время будет больше затрачено на формирование данных, т.к. нужно будет еще обработать запрос на внешний api. Или это не так?
ОЗ
или вообще это не критично?
ИК
тут нет понятия быстрее или медленнее, правильнее первый вариант с обращением в апи, потому что если ты будешь свой фронт заставлять делать запросы сначала в SSR, а потом в апи - это будет хуже, и перемешает бизнес логику. getServerSideProps нужен чтобы заранее что-то распаковать из апи, или авторизовать, или скрыть запрос, в любом случае post запросы тебе придется делать из фронта, особенно, если это передача файлов или base64, это долгая операция и никто не гарантирует, что некст ее со стороны бэка сделает быстро
ИК
и вообще я помню у меня выжирало память именно из-за зависшего getServerSideProps
ОЗ
благодарю за ответ. Изначально склонялся к тому, чтобы слать запросы на api, как это показано и в официальной документации, но потом наткнулся на несколько решений по типу модуля "nest-next". Мне показалось это неудобным в плане гибкости разработки, т.к. на фронт тащишь бековские сервайс методы
тогда в чем плюсы использования второго метода?
тогда в чем плюсы использования второго метода?