makedream
36:54Vercel
Log in to leave a comment
No posts yet
Движок Nitro в Nuxt кажется универсальным, но как только дело доходит до Vercel Edge Runtime, ситуация меняется. Библиотеки вроде sharp или bcrypt, которые отлично работали локально, могут мгновенно выдать ошибку 500 после деплоя, так как Vercel Edge блокирует доступ к стандартным модулям Node.js. Перед тем как нажать кнопку деплоя, я обязательно выполняю npx vercel build. Без предварительной симуляции среды на базе Linux велика вероятность, что в три часа ночи вам придется бороться с ошибками рантайма.
Для стабильной работы безопаснее явно указать пресет vercel вместо vercel-edge в nuxt.config.ts. Нет необходимости запускать все API на Edge. Также стандартизируйте работу с переменными окружения через useRuntimeConfig от Nitro, а не вызывайте process.env напрямую. Эта простая привычка устраняет 80% ошибок рантайма, возникающих после деплоя.
Главные виновники больших счетов в Vercel — это время выполнения и количество вызовов Serverless-функций. routeRules, представленные в Nitro 3, — это мощнейший инструмент для физического сокращения этих затрат. При правильном использовании стратегии stale-while-revalidate (SWR), даже если придет 10 000 запросов к API, фактическое выполнение функции произойдет всего один раз. Это умный способ обеспечить пользователям сверхбыстрый отклик в миллисекундах, сохранив при этом ваш бюджет.
Конкретные настройки для снижения затрат более чем на 40%:
routeRules файла nuxt.config.ts укажите пути, которые нужно кешировать.swr: 3600 для этих путей, чтобы включить режим фонового обновления на 1 час.cache укажите maxAge и staleMaxAge, чтобы определить время хранения кеша на CDN.После этого вы увидите на панели управления Vercel, как количество вызовов Serverless-функций резко пойдет вниз.
Ошибки гидратации, возникающие при несовпадении серверного HTML и клиентского JavaScript, делают приложение нестабильным. Nuxt 4 спроектирован так, что при вызове useAsyncData по умолчанию используется deep: false. Отказываясь от ненужного отслеживания объектов, мы экономим память и безопасно передаем состояние сервера клиенту.
Применяйте три правила, чтобы устранить несоответствия данных и уменьшить размер полезной нагрузки:
pick при вызовах API, чтобы выбрать только те ключи, которые необходимы для рендеринга шаблона. Это само по по себе может сократить размер полезной нагрузки до 50%.useId(), чтобы сопоставить идентификаторы на сервере и клиенте.<NuxtTime> для обработки на основе локали браузера.По мере роста проекта даже 8 192 МБ памяти, предоставляемых контейнером сборки Vercel, может быть недостаточно. Точнее, размер кучи (heap size) Node.js по умолчанию может быть установлен меньше доступной памяти, что приводит к частой сборке мусора и остановке билда.
Чтобы ускорить сборку и предотвратить сбои, примените следующие настройки:
NODE_OPTIONS="--max-old-space-size=4096" в проект Vercel. Простое снятие ограничений на память кучи часто устраняет узкие места при сборке.npx nuxt analyze, чтобы проверить, не подмешаны ли тяжелые серверные зависимости в клиентский бандл, и изолируйте их с помощью алиаса #server.server/middleware/, которая выполняется при каждом запросе, внутрь обработчиков событий конкретных путей, чтобы уменьшить размер серверного бандла.После завершения этой настройки время ожидания в CI/CD сократится, а процент успешных деплоев значительно вырастет.