Funções Serverless em JavaScript: AWS Lambda e alternativas para desenvolvedores

Serverless em JavaScript: Como parar de pensar em servidores e começar a escrever código

Imagine: você criou um serviço incrível, o lançou e, um mês depois, ninguém o usa. Você paga por um servidor que fica ocioso. Ou o contrário — você sofre um pico de tráfego, o servidor cai e você está às 3 da manhã ajustando o nginx. Familiar? Existe uma maneira de se livrar dessa dor de cabeça — funções serverless em JavaScript.

Serverless (ou computação sem servidor) não é mágica, é um modelo onde você escreve apenas o código, e o provedor (AWS, Google, Yandex) decide quando, onde e quantos recursos alocar. Você paga apenas pelo tempo de execução e pelo número de requisições. Nada de máquinas virtuais "sempre ligadas". Para o desenvolvedor JavaScript, isso é especialmente conveniente: Node.js é o ambiente nativo para AWS Lambda, Google Cloud Functions e Yandex Cloud Functions.

Neste artigo, não vamos apenas falar teoria. Vamos escrever funções reais, comparar provedores e dar uma checklist para você não pisar na bola. Vamos lá!

O que é uma função serverless e por que ela é útil para um desenvolvedor JS?

Uma função serverless é um pedaço de código (geralmente uma única função) que é executado em resposta a um evento. O evento pode ser uma requisição HTTP, upload de arquivo para S3, gravação em banco de dados ou até mesmo um sinal de temporizador (cron).

Por que isso é conveniente para JavaScript:

\n
• Início rápido — não precisa configurar servidor, basta enviar o código.
\n
• Escalonamento automático — a função se replica sozinha sob demanda.
\n
• Economia — enquanto ninguém chama a função, você não paga nada.
\n
• Ecossistema — Node.js é suportado por todos os grandes provedores.
\n

Cenários típicos: processamento de webhooks, geração de miniaturas de imagens, envio de e-mails, validação de formulários, parsing de dados, criação de microsserviços. Tudo que pode ser executado sob demanda.

AWS Lambda — o rei do serverless JavaScript

Amazon Web Services Lambda é o serviço mais popular. Ele surgiu primeiro e ainda define os padrões. Vamos escrever uma função simples que recebe JSON e retorna uma resposta.

Código para AWS Lambda em Node.js 20:

export const handler = async (event) => {\n  try {\n    const { name } = JSON.parse(event.body || '{}');\n    const message = `Olá, ${name || 'convidado'}! Você chamou com sucesso uma função serverless.`;\n    \n    return {\n      statusCode: 200,\n      headers: {\n        'Content-Type': 'application/json',\n        'Access-Control-Allow-Origin': '*',\n      },\n      body: JSON.stringify({ message, timestamp: Date.now() }),\n    };\n  } catch (error) {\n    return {\n      statusCode: 400,\n      body: JSON.stringify({ error: 'JSON inválido' }),\n    };\n  }\n};

Observe: a função se chama handler. Este é o nome padrão para o ponto de entrada. O parâmetro event contém tudo que veio do API Gateway — cabeçalhos, corpo, parâmetros da requisição. Você retorna um objeto com statusCode e body.

Como funciona: você cria uma função no console da AWS, envia o código (ou usa SAM/Serverless Framework), configura um gatilho — por exemplo, um endpoint HTTP via API Gateway. Pronto. O mundo ficou mais simples.

Cold start e como lidar com ele

A principal desvantagem do Lambda é o cold start. Se a função não for chamada por um tempo, na primeira requisição o ambiente é carregado novamente. Isso pode levar de 200 a 500 ms. Para APIs de alta carga, isso é crítico. Soluções:

\n
• Mantenha a função "aquecida" com CloudWatch Events (ping a cada 5 minutos).
\n
• Reduza o tamanho do pacote — não inclua pacotes npm desnecessários.
\n
• Use Provisioned Concurrency (mas é mais caro).
\n

Para a maioria dos microsserviços, o cold start não é um problema. Mas se você está escrevendo um chatbot onde a velocidade é importante, leve isso em consideração.

Google Cloud Functions — simplicidade e integração com Firebase

Go