Как стать автором
Обновить

Комментарии 7

Все это хорошо. Но например я всегда воспринимал Next.js как фреймворк для фронтенда. Это точно хорошая идея разрабатывать не нем API?

Наверное, я немного запутал Вас своим вступлением о разработке API на основном месте работы. NextJS не подходит для разработки API, но рано или поздно любому сайту понадобится пара-тройка эндпоинтов для интерактивных элементов, если это только не статичный лэндинг.

Не очень понял, а что мешает использовать NextJS и NestJS одновременно? Ту же пару-тройку эндпоинтов для интерактивных элементов реализовать в NestJS - и в getInitialProps (или как там в NextJS) делать запросы с ним.

Во-первых, Вы добавляете лишнее звено в цепочку запросов и увеличиваете общее время получения ответа. Во-вторых, Ваш API на NestJS нужно куда-то деплоить, подключать к нему мониторинг и создавать отдельный репозиторий для shared типов для избежания дублирования кода, следить за версионированием, обновлять в нескольких репозиториях и тригерить редеплой коммитами в мастер. В целом, я поддерживаю идею использования наиболее подходящих инструментов для решения разных задач, но в то же время мне кажется, что NextJS создавался как monorepo фреймворк с целью упрощения процесса создания сайтов.

А ещё не очень понял как вы реализуете автокомплит через getInitialProps?

У меня есть пет-проект, где я использую связку NestJS + NextJS. NestJS там - это API, взаимодействующее с базой данных. Это же API использует и админка для проекта. Пользовательская (публичная) часть проекта должна хорошо индексироваться поисковыми роботами, поэтому написана не просто на React, а с использованием NextJS. Только те данные, которые нужно отдавать роботам (например, текст статьи), доставляются по API (из NestJS-приложения) в getInitialProps - соответственно Google/Yandex на таких страницах видит отрендеренную готовую html-страницу.

Если данные не обязательно отдавать роботам, то делаю просто обычные ajax-запросы (не в getInitialProps). То есть если нужен автокомплит, то, конечно, это обычный ajax-запрос, который я выполняю не в getInitialProps, а просто делаю его по какому-то событию текстового автокомплит-поля (например, onChange).

Ваш API на NestJS нужно куда-то деплоить

Ну так любой бэкенд надо куда-то деплоить. Чтобы серверный рендеринг в NextJS работал, его тоже нужно куда-то деплоить, разве нет?

Вы добавляете лишнее звено в цепочку запросов

Нет, не добавляю. Когда поисковый робот запрашивает страницу, NextJS в getInitialProps делает запрос к API (NestJS), подставляет данные, полученные из API, в шаблон - и отдаёт этот html поисковому роботу. Где ж тут лишнее звено?

Мне кажется, что мы перешли от обсуждения конкретной имплементации к обсуждению инфраструктурных вопросов и решению несуществующих проблем и мне бы не хотелось углубляться в это. В NextJS предусмотрен и задокументирован механизм создания API эндпоинтов. Использовать его или нет — персональный выбор каждого отдельно взятого инженера в сложившихся для него условиях. Я в свою очередь лишь продемонстрировал один из способов упрощения взаимодействия с программным интерфейсом фреймворка для создания API эндпоинтов в пределах NextJS. Относительно Вашего решения ни в коем случае не имею ничего против.

Вы упомянули о сложностях деплоя. Все жто ничего по стравнению со сложностью тестированрия и отладки новой библиотеки.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации