Comments 4
А если просто сделать, чтобы приложения nest и next жили по отдельности и общались по api без nest-next? Такая схема будет рабочей?
Так действительно можно сделать, но возникает ряд нюансов. Придется поднимать два сервера, что может вызвать особенные неудобства при наличии запросов серверу из браузера: страницы будут жить в сервере next, туда клиент будет ходить за страницами и статикой, а вот API уже будет на другом адресе. Будут сложности с CSP и сертификатами, естественно с ресурсами для поднятия двух серверов.
Решением, конечно, будет использовать proxy, который, например, будет отправлять запросы, начинающиеся на /api в сервер nest, а остальные в next. И так или иначе может возникнуть необходимость создавать обертку для fetch, ведь браузеру нужно будет ходить в proxy, а serverless функциям nest не мешало бы напрямую ходить в nest (например, если они живут в одном оркестре docker-compose).
В моем опыте получилось действительно с преимуществами использовать nest-next благодаря существующей инфраструктуре для nest/express. Для более общих случаев, можно сказать, что если возникает необходимость существования внутренних эндпоинтов (различные конфигурации/переводы), которые нужны исключительно чтобы делать туда запросы из serverless функций next при генерации страниц (GSSP, GIP), то следует рассмотреть переезд на nest-next. И, конечно, не следует использовать такую провязку при создании вебсайта со статичными страницами getStaticProps без ревалидации (в таком случае возникает вопрос зачем тут вообще nest тогда, но это к теме не относится).
Большое спасибо за статью, очень интересный симбиоз. Я немного не уловил одного момента. Как быть, если имеются страницы с динамическими маршрутами, собирающиеся при помощи getStaticPaths и getStaticProps, в которых происходят запросы в апи nest. Насколько я понимаю, production сервер не запустится, пока в директории не будет лежать каталог со сборкой next. Но и сборку next не удастся запустить, пока не будет запущен сервер nest. Не могли бы в разъяснить? Может я что-то недопонял?
На самом деле действительно при использовании getStaticPaths/getStaticProps в том числе с ревалидацией возникают нюансы при сборке (впрочем как и при любой сборке с использованием этих методов): в таком случае для сборки придется сначала запустить сервер nest, а потом параллельно начать сборку. Впрочем, делать это бы пришлось бы и при использовании любого другого бэкенда.
Возможной альтернативой будет указывать не только basePath, но и весь путь до API - тогда можно, например, при сборке сразу же обращаться к API уже развернутого приложения. Конечно, могут быть сложности при наличии изменений, которые требуются для сборки и которых еще нет в развернутом окружении. Правильного способа, пожалуй, нет, я бы рекомендовал действовать по первому пути.
NEST-NEXT: Best Practices — Часть 2