Next.js Архитектура - PullRequest
Новая
       24

Next.js Архитектура

2 голосов
/ 31 октября 2019

Я ищу несколько советов по архитектуре Next.js, пожалуйста. 100

Я нахожусь в процессе миграции очень большого экспресс-приложения NodeJS с настраиваемой настройкой SSR на настройку Next.js.

Для текущего сайта NodeJS у меня есть:

  • Куча маршрутов (которые подключают контроллеры / apis, выполняют перенаправления и т. Д.)
  • Имеют тонну промежуточного программного обеспечения
  • Тонны логики в куче экспресс-контроллеров (эти контроллеры выполняют такие функции, как вызовы API, преобразование данных, проверка и SSR некоторых компонентов React для формирования приложения)
  • В большинстве случаевСервер NodeJS вызывает другие API-интерфейсы Microservice (на том же VPC) для извлечения данных внутри этих контроллеров (например: API поиска, API аутентификации, API местоположения и т. Д., Которые все являются отдельными серверами API REST) ​​ Примечание: при получениииз этих API это делается только по внутреннему адресу API
  • Сайт React сам вызывает тот же сервер NodeJS для получения данных через JS на стороне клиента, когдаесть изменение маршрута eg: URL-адрес веб-интерфейса будет: www.mywebsite.com.au И любой вызов API, выполняемый из веб-интерфейса, выполняется с маршрутом: www.mywebsite.com.au/api/*

На основе всех документов, которые я прочиталдо сих пор я считаю, что лучшая настройка:

  1. Чтобы сохранить мои существующие экспресс-настройки для маршрутов / промежуточного программного обеспечения (для которого у меня есть тонна), это включает в себя /api/* из них
  2. Перенос логики выборки контроллера в общедоступный экспресс-интерфейс apis /api/* (который у меня вроде уже есть, но мне нужно его очистить)
  3. Для существующих маршрутов экспресс-контроллера вместо этого перенаправьте их в Next.js и используйте nextApp.render на следующие конкретные страницы
  4. Используйте getInitialProps на страницах Next.js для извлечения данных из тех API-интерфейсов, которые я упомянул в 2.
  5. Также добавьте старую логику преобразования проп, которая была вэкспресс-контроллеры на getInitialProps

Это так, что сервер и клиент имеют одинаковую логику, что и в getInitialProps - и это сделает архитектуру чистой и даст мне возможность плавноТребование использовать Link.

Я борюсь с ним с шагом 4.

Это означает, что теперь при SSR запроса страницы необходимо вызвать общедоступный API (www.mywebsite.com.au/api/*) на getInitialProps для извлечения данных.

Мне кажется, что это приводит к снижению производительности, так как требует сетевого прыжка для публичного домена mywebsite.com.au для извлечения данных, которые он мог получить локально на том же самомзапрос (позвонив, например, localhost:3000/api/*)

Любой совет, как избежать сетевого прыжка снаружи для рендеринга сервера? Могу ли я определить, выполняет ли сервер рендеринг, а затем использовать внутренний URL-адрес (например, использовать localhost:3000/api/* при запросе к тому же веб-серверу) или это не лучший метод при использовании Next.js?

Ответы [ 2 ]

0 голосов
/ 31 октября 2019

Я считаю listing-page.jsx и обработчик для api/listing маршрута одинаковыми. Возможно, вам понадобится написать 2 небольшие функции, чтобы извлечь параметры, переданные в запрос, и передать их функции вашего сервисного модуля, например ListingService.getSingleListisng(id)

0 голосов
/ 31 октября 2019

Сервер должен вызывать сам себя для извлечения своих данных, много накладных расходов, связанных с извлечением данных, связано с задержкой (IE между клиентом и ближайшим центром обработки данных), это будет меньше беспокоить, когда его (центр данных ->datacenter).

Если производительность по-прежнему остается проблемой, ваша следующая лучшая ставка будет заключаться в кэшировании SSR, из которых есть много различных методов, которые вы можете найти в быстром поиске в Google, однако это будет зависеть от вашего хостинга/setup.

...