#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. Спасибо 🙂 это именно то, что я подумал