Criar funções do Lambda com Node.js - AWS Lambda

Criar funções do Lambda com Node.js

Você pode executar o código JavaScript com Node.js noAWS Lambda. O Lambda fornece runtimes para Node.js que executam seu código para processar eventos. Seu código é executado em um ambiente que inclui o AWS SDK for JavaScript, com as credenciais de uma função do AWS Identity and Access Management (IAM) que você gerencia. Para saber mais sobre as versões do SDK incluídas nos runtimes do Node.js, consulte Versões do SDK incluídas no runtime.

O Lambda oferece suporte aos runtimes Node.js a seguir.

Node.js
Nome Identificador Sistema operacional Data da substituição Bloquear a criação de funções Bloquear a atualização de funções

Node.js 20

nodejs20.x

Amazon Linux 2023

Node.js 18

nodejs18.x

Amazon Linux 2

Node.js 16

nodejs16.x

Amazon Linux 2

12 de junho de 2024

28 de fevereiro de 2025

31 de março de 2025

nota

Os runtimes do Node.js 18 e de versões posteriores usam o AWS SDK para JavaScript v3. Para fazer a migração de uma função de um runtime anterior, siga o workshop de migração no GitHub. Para obter mais informações sobre o SDK da AWS para a versão 3 do JavaScript, consulte a postagem no blog O SDK da AWS modular para JavaScript já está disponível para o público em geral.

Para criar uma função em Node.js.
  1. Abra o console do lambda.

  2. Escolha a opção Criar função.

  3. Configure as seguintes opções:

    • Nome da função: digite um nome para a função.

    • Runtime: escolha Node.js 20.x.

  4. Escolha a opção Criar função.

  5. Para configurar um evento de teste, escolha Test (Testar).

  6. Em Nome do evento, insira test.

  7. Escolha Salvar alterações.

  8. Escolha Testar para invocar a função.

O console cria uma função do Lambda com um único arquivo de origem denominado index.js ou index.mjs. Você pode editar esse arquivo e adicionar mais arquivos no editor de códigos integrado. Para salvar suas alterações, selecione Salvar. Em seguida, para executar seu código, escolhaTeste.

nota

O console do Lambda usa o AWS Cloud9 para fornecer um ambiente de desenvolvimento integrado no navegador. Você também pode usar o AWS Cloud9 para desenvolver funções do Lambda em seu próprio ambiente. Para obter mais informações, consulte Working with AWS Lambda functions using the AWS Toolkit no Guia do usuário do AWS Cloud9.

O arquivo index.js ou index.mjs exporta uma função denominada handler que assume um objeto de evento e um objeto de contexto. Esta é a função de manipulador que o Lambda chama quando a função é invocada. O runtime da função do Node.js recebe eventos de invocação do Lambda e os transmite ao manipulador. Na configuração da função, o valor do manipulador é index.handler.

Quando você salva seu código de função, o console do Lambda cria um pacote de implantação de arquivos .zip. Quando desenvolver o código de função fora do console (usando um IDE), você precisará criar um pacote de implantação para carregar o código na função do Lambda.

nota

Para começar com o desenvolvimento de aplicativos no ambiente local, implante um dos aplicativos de exemplo disponíveis no repositório do GitHub deste guia.

Aplicações de exemplo do Lambda em Node.js
  • blank-nodejs: uma função do Node.js que mostra o uso do registro em log, variáveis de ambiente, rastreamento do AWS X-Ray, camadas, testes de unidade e do AWS SDK.

  • nodejs-apig: uma função com endpoint de API pública que processa um evento do API Gateway e retorna uma resposta HTTP.

  • rds-mysql: uma função que retransmite consultas para um banco de dados MySQL para RDS. Este exemplo inclui uma VPC privada e uma instância de banco de dados configurada com uma senha no AWS Secrets Manager.

  • efs-nodejs: uma função que usa um sistema de arquivos do Amazon EFS em uma Amazon VPC. Esse exemplo inclui uma VPC, um sistema de arquivos, destinos de montagem e ponto de acesso configurado para uso com o Lambda.

  • list-manager: uma função processa eventos de um fluxo de dados do Amazon Kinesis e atualiza listas agregadas no Amazon DynamoDB. A função armazena um registro de cada evento em um banco de dados MySQL para RDS em uma VPC privada. Este exemplo inclui uma VPC privada com um endpoint da VPC para o DynamoDB e uma instância de banco de dados.

  • error-processor: uma função do Node.js gera erros para uma porcentagem especificada de solicitações. Uma assinatura do CloudWatch Logs invoca uma segunda função quando um erro é registrado. A função do processador usa o AWS SDK para coletar detalhes sobre a solicitação e os armazena em um bucket do Amazon S3.

O runtime transmite um objeto de contexto para o manipulador, além do evento de invocação. O objeto de contexto contém informações adicionais sobre a invocação, a função e o ambiente de execução. Outras informações estão disponíveis de variáveis de ambiente.

Sua função do Lambda é fornecida com um grupo de logs do CloudWatch Logs. O runtime envia detalhes sobre cada invocação para o CloudWatch Logs. Ele retransmite quaisquer logs que sua função produz durante a invocação. Se a função retornar um erro, o Lambda formatará o erro e o retornará para o invocador.

Inicialização do Node.js

O Node.js tem um modelo de loop de eventos exclusivo que torna seu comportamento de inicialização diferente de outros runtimes. Especificamente, o Node.js utiliza um modelo de E/S sem bloqueio que oferece suporte a operações assíncronas. Esse modelo permite que o Node.js funcione de modo eficiente com a maioria das workloads. Por exemplo, se uma função Node.js fizer uma chamada de rede, a solicitação poderá ser designada como uma operação assíncrona e colocada em uma fila de retorno de chamada. A função poderá continuar processando outras operações dentro da pilha de chamadas principal sem ser bloqueada aguardando o retorno da chamada de rede. Após a chamada de rede ser concluída, o retorno de chamada é executado e, em seguida, removido da fila de retorno de chamada.

Algumas tarefas de inicialização podem ser executadas de modo assíncrono. Não há garantia de que a execução dessas tarefas assíncronas será concluída antes de uma invocação. Por exemplo, um código que faz uma chamada de rede para buscar um parâmetro do AWS Parameter Store poderá não estar concluído quando o Lambda executar a função de manipulador. Como resultado, a variável poderá ser nula durante uma invocação. Para evitar isso, certifique-se de que as variáveis ​​e outros códigos assíncronos estejam totalmente inicializados antes de continuar com o restante da lógica de negócios principal da função.

Como alternativa, é possível designar o código da função como um módulo ES, o que permite que você use await no nível superior do arquivo, fora do escopo do manipulador de função. Quando você await cada Promise, o código de inicialização assíncrona é concluído antes das invocações do manipulador, maximizando a eficácia da simultaneidade provisionada ao reduzir a latência de inicialização a frio. Para obter mais informações e um exemplo, consulte Uso de módulos ES do Node.js e do “await” em nível superior no AWS Lambda.

Designar um manipulador de funções como módulo ES

Por padrão, o Lambda trata arquivos com o sufixo .js como módulos CommonJS. Como opção, é possível designar o código como um módulo ES. Isso pode ser feito de duas maneiras: especificando o type como module no arquivo da função package.json ou usando a extensão do nome do arquivo .mjs. Na primeira abordagem, o código da função trata todos os arquivos .js como módulos ES, enquanto no segundo cenário, somente o arquivo especificado com .mjs corresponde a um módulo ES. É possível mesclar módulos ES e módulos CommonJS nomeando-os .mjs e .cjs, respectivamente, pois os arquivos .mjs serão sempre módulos ES, e os arquivos .cjs serão sempre módulos CommonJS.

Para as versões do runtime do Node.js até o Node.js 16, o runtime do Lambda carrega os módulos ES da mesma pasta que o manipulador da função, ou de uma subpasta. A partir do Node.js 18, o Lambda pesquisa pastas na variável de ambiente NODE_PATH ao carregar módulos ES. Além disso, a partir do Node.js 18, é possível carregar o AWS  SDK incluído no runtime usando as instruções import do módulo ES. Também é possível carregar módulos ES usando camadas.

Versões do SDK incluídas no runtime

A versão do AWS SDK incluída no runtime do Node.js depende da versão do runtime e da Região da AWS. Para encontrar a versão do SDK incluída no runtime que você está usando, crie uma função do Lambda com o código a seguir.

nota

O exemplo de código mostrado abaixo para o Node.js versão 18 e acima usa o formato CommonJS. Se você criar a função no console do Lambda, não se esqueça de renomear o arquivo que contém o código como index.js.

exemplo Node.js 18 e acima
const { version } = require("@aws-sdk/client-s3/package.json"); exports.handler = async () => ({ version });

Uma resposta é retornada no seguinte formato:

{ "version": "3.462.0" }
exemplo Node.js 16
const { version } = require("aws-sdk/package.json"); exports.handler = async () => ({ version });

Uma resposta é retornada no seguinte formato:

{ "version": "2.1374.0" }

Usar o keep-alive para conexões TCP

O agente Node.js HTTP/HTTPS padrão cria uma nova conexão TCP para cada nova solicitação. Para evitar o custo de estabelecer novas conexões, você pode usar keepAlive: true para reutilizar as conexões que sua função faz usando o AWS SDK para JavaScript. O Keep-alive pode reduzir os tempos de solicitação de funções do Lambda que fazem várias chamadas de API usando o SDK. O comportamento do keep-alive difere dependendo da versão do SDK que você está usando:

  • No AWS SDK para JavaScript 3.x, que está incluído no runtime do Lambda para nodejs18.x e em versões posteriores, o recurso keep-alive está habilitado por padrão. Para desativar o keep-alive, consulte Reusing connections with keep-alive in Node.js no Guia do desenvolvedor do AWS SDK para JavaScript 3.x.

  • No AWS SDK para JavaScript 2.x, que está incluído no runtime do Lambda para nodejs16.x, o recurso keep-alive está desabilitado por padrão. Para ativar o keep-alive, consulte Reusing Connections with Keep-Alive in Node.js no Guia do desenvolvedor do AWS SDK para JavaScript 2.x.

Para obter mais informações sobre como usar o keep-alive, consulte HTTP keep-alive is on by default in modular AWS SDK for JavaScript no Blog de ferramentas da AWS para o desenvolvedor.

Carregamento de certificado de CA

Até a versão do runtime do Node.js 18, o Lambda carrega automaticamente certificados de CA (autoridade de certificação) específicos da Amazon para facilitar a criação de funções que interagem com outros serviços da AWS. Por exemplo, o Lambda inclui os certificados do Amazon RDS necessários para validar o certificado de identidade do servidor instalado no banco de dados do Amazon RDS. Esse comportamento pode ter um impacto na performance durante inicializações a frio.

A partir do Node.js 20, o Lambda não carrega mais certificados de CA adicionais por padrão. O runtime do Node.js 20 contém um arquivo de certificado com todos os certificados de CA da Amazon localizado em /var/runtime/ca-cert.pem. Para restaurar o mesmo comportamento do Node.js 18 e de runtimes anteriores, defina a variável de ambiente NODE_EXTRA_CA_CERTS como /var/runtime/ca-cert.pem.

Para otimizar a performance, recomendamos que você agrupe somente os certificados de que precisa com o pacote de implantação e carregue-os usando a variável de ambiente NODE_EXTRA_CA_CERTS. O arquivo de certificados deve consistir em um ou mais certificados de CA raiz ou intermediários confiáveis no formato PEM. Por exemplo, para o RDS, inclua os certificados necessários junto com seu código como certificates/rds.pem. Em seguida, carregue os certificados configurando NODE_EXTRA_CA_CERTS como/var/task/certificates/rds.pem.