next.js — env против serverRuntimeConfig

#environment-variables #next.js

#переменные среды #next.js

Вопрос:

Я читал об serverRuntimeConfig этом здесь: https://nextjs.org/docs/api-reference/next.config.js/runtime-configuration

Теперь мой next.config.js :

 module.exports = withCSS({
  target: 'serverless',
  reactStrictMode: false,
  env: {
     SECRET: 'SECRET'
  }
});
  

Мне интересно, должен ли я использовать serverRuntimeConfig для своего секретного env var вместо env ?
Каковы плюсы / минусы?

Ответ №1:

 Generally you'll want to use build-time environment variables to provide your configuration. The reason for this is that runtime configuration adds rendering / initialization overhead and is incompatible with Automatic Static Optimization.

# https://nextjs.org/docs/api-reference/next.config.js/runtime-configuration
  

Как они сказали, конфигурация среды выполнения в next.config.js может вызвать накладные расходы.

Поэтому я предлагаю использовать env in next.config.js или использовать .env* файлы в этом новом методе (https://nextjs.org/docs/basic-features/environment-variables )

Код, использующий ваши секретные переменные env, должен находиться на стороне сервера (маршруты API, getStaticProps, getServerSideProps), а не на стороне клиента (компоненты …). Если вы ссылаетесь на них на стороне клиента, они могут быть открыты!

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

1. Но я использую эти переменные env только в коде на стороне сервера, так как они могут быть раскрыты? Я не понимаю. Если я вас правильно понял, хотя переменные среды выполнения имеют некоторые накладные расходы, я должен использовать их, чтобы убедиться, что секретные переменные не будут отправлены в браузер.

2. Возможно, вы меня неправильно поняли. Я имею в виду, что если вы ранее предоставляли значения переменных env next build , они могут быть представлены в пакете и отправлены в браузер. Я советую вам указывать значения переменных env при запуске вашего приложения next start . И вы знаете, что ваш код использует env на стороне сервера, так что не волнуйтесь, они не будут раскрыты. Другой способ — использовать файлы .env, поддерживаемые последней версией Next.js . Они направляют нас: если мы хотим предоставить доступ к переменной env в браузере, пожалуйста, добавьте префикс в свой env var, например NEXT_PUBLIC_env_name, другой env var без этого префикса, они не будут доступны

3. Итак, просто чтобы убедиться, что то, что я сделал (использовал env в next.config.js ), в порядке, верно?

4. Но ясно, что если я напишу в клиентском коде что-то подобное console.log(process.env.SECRET) , оно будет открыто и напечатано на консоли, потому что секрет будет заменен во время сборки (?). Но если я использую process.env.SECRET только код на стороне сервера (и не отправляю его клиенту), он не будет открыт. Таким образом, мы можем сказать, что это не обязательно использовать serverRuntimeConfig , но это может спасти нас от случайного раскрытия секретов клиенту. я правильно понял?

5. Спасибо 🙂 это именно то, что я подумал