makedream
36:54Vercel
Log in to leave a comment
No posts yet
O motor Nitro do Nuxt parece rodar bem em qualquer lugar, mas no momento em que sobe para o Vercel Edge Runtime, a história muda. O motivo pelo qual bibliotecas como sharp ou bcrypt, que funcionavam perfeitamente localmente, retornam erro 500 imediatamente após o deploy é que o Vercel Edge bloqueia o acesso aos módulos padrão do Node.js. Eu sempre executo npx vercel build antes de apertar o botão de deploy. Se você não simular o ambiente baseado em Linux antecipadamente, há uma alta probabilidade de acabar lutando contra erros de runtime às 3 da manhã.
Se você deseja uma operação estável, é mais seguro especificar explicitamente o preset como vercel em vez de vercel-edge no seu nuxt.config.ts. Não há necessidade de rodar todas as APIs no Edge. Além disso, padronize o acesso às variáveis de ambiente usando o useRuntimeConfig do Nitro em vez de chamar process.env diretamente. Este pequeno hábito elimina 80% dos erros de runtime que ocorrem após o deploy.
O principal culpado pelas faturas do Vercel é o tempo de execução e o número de chamadas das Serverless Functions. O routeRules oferecido no Nitro 3 é a ferramenta mais poderosa para reduzir fisicamente esses custos. Se você usar a estratégia stale-while-revalidate (SWR) corretamente, mesmo que receba 10.000 requisições de API, a execução real da função ocorrerá apenas uma vez. É uma maneira inteligente de oferecer respostas rápidas em milissegundos aos usuários enquanto protege sua carteira.
Aqui estão as configurações específicas para reduzir os custos em mais de 40%:
routeRules do nuxt.config.ts.swr: 3600 ao caminho correspondente para ativar o modo de atualização em segundo plano por 1 hora.maxAge e staleMaxAge dentro da opção cache.Dessa forma, você verá o número de chamadas de funções serverless cair verticalmente no dashboard do Vercel.
Erros de hidratação, que ocorrem quando o HTML gerado pelo servidor e o JavaScript do cliente se encontram, tornam o app instável. O Nuxt 4 foi projetado para usar deep: false por padrão ao chamar useAsyncData para resolver isso. Ao abrir mão do rastreamento desnecessário de objetos, economiza-se memória e transfere-se o estado do servidor para o cliente com segurança.
Aplique estas três regras para corrigir inconsistências de dados e reduzir o tamanho do payload:
pick nas chamadas de API para selecionar apenas os valores das chaves estritamente necessários para a renderização do template. Só isso pode reduzir o tamanho do payload em até 50%.useId() para alinhar os identificadores entre servidor e cliente.<NuxtTime> para processá-los com base na localidade do navegador.À medida que o projeto cresce, mesmo os 8.192 MB de memória fornecidos pelo container de build do Vercel podem ser insuficientes. Mais precisamente, o tamanho padrão do heap do Node.js é configurado para ser menor que a memória disponível, tornando a coleta de lixo frequente e, eventualmente, interrompendo o build.
Para aumentar a velocidade do build e evitar falhas de deploy, aplique estas configurações imediatamente:
NODE_OPTIONS="--max-old-space-size=4096" às variáveis de ambiente do projeto no Vercel. Apenas remover o limite de memória heap já elimina os gargalos de build.npx nuxt analyze para verificar se dependências pesadas exclusivas do servidor estão misturadas no bundle do cliente e as isole com o alias #server.server/middleware/, que rodam em todas as requisições, para dentro de event handlers de rotas específicas.Ao concluir essa configuração de ambiente, o tempo de espera no pipeline de CI/CD será reduzido e a taxa de falha no deploy diminuirá significativamente.