Comandos que você deveria estar usando em produção

Quando se trata do Serverless Framework, pode haver uma curva de aprendizado. No entanto, com alguns comandos úteis, você pode simplificar seu desenvolvimento serverless e manter seu foco na construção vs depuração.

O objetivo deste artigo é mostrar uma série de comandos que usamos constantemente no Serverless Guru para acelerar a depuração e fornecer resultados mais rápidos aos nossos clientes.

Lista de Comandos

Na seção a seguir, mostraremos os comandos e daremos uma breve descrição de como os usamos no Serverless Guru.

Empacotando

Quando se trata de empacotar suas funções AWS Lambda, você ficará tentado a simplesmente executar o comando sls deploy, que irá fazer um zip das suas lambdas, node_modules, e quaisquer outros arquivos que você disse ao Serverless Framework para incluir. No entanto, a execução sls deploy também inicia a provisão no AWS e, caso desejarmos simplesmente inspecionar o tamanho e o conteúdo do arquivo zip, podemos executar o seguinte comando:

$ sls package -v

Nota: Você ainda pode passar opções (por exemplo, --stage <> ou --region <>) se você estiver usando essas variáveis no seu arquivo serverless.yml.

Testes Locais

Desenvolver aplicativos serverless e ter qualquer reflexo de velocidade requer testes locais da sua lógica do AWS Lambda. Ou seja, você não quer esperar que uma provisão seja concluída toda vez que seu nome de variável estiver sem um caractere.

Para começar com testes locais, há um comando útil que você pode usar:

$ sls invoke local -f [function_name] -d "{ ... }" -v

A documentação inclui algumas "opções", como as quais você viu acima -d. É importante investir tempo lendo as opções disponíveis para este comando para entender o que faz mais sentido para o seu projeto.

Recomendamos o uso de sls invoke local -f [] -p ./test-events/create-user.json o -p informa ao comando para fazer referência a um arquivo em seu projeto ao invés do -d que requer um objeto de evento codificado na hora. Utilizar -p escala significativamente melhor, pois você pode acompanhar e documentar todos os seus eventos.

À medida que você se aprofunda, recomendamos o uso de alternativas ao sls invoke local, que seria o sls-offline, um plugin do Serverless Framework que ajuda a simular o AWS Lambda e o API Gateway localmente. Isso permitirá que você faça solicitações às suas funções lambda diretamente pelo seu navegador, caso suas funções do AWS Lambda estiverem configuradas como APIs.

Deploy de uma única função

À medida que seus aplicativos serverless crescem em tamanho e complexidade. Será ainda mais importante evitar o sls deploy para todas as mudanças de código. Com isso, teremos algumas etapas adicionais, como a verificação de alterações em nossa infraestrutura no serverless.yml e verificar as alterações realizadas nas funções da AWS Lambda em nosso projeto, algumas das quais não nos importamos muito quando simplesmente mudamos um pequeno código em uma única função:

$ sls deploy function -f [function_name] -v

A documentação tem algumas opções e até mostra uma maneira de atualizar apenas a configuração da sua função lambda (por exemplo, tempo limite, memória, etc).

Instalando plugins como um mestre Serverless Framework

Quando você estiver pronto para começar a trabalhar com plugins do Serverless Framework. Você precisará instalá-los seguindo estas etapas:

Instale o plugin, npm install --save-dev <>
Crie uma seção plugins no seuserverless.yml

Você pode estar se perguntando, bem, se são apenas dois passos, por que eu preciso de um comando específico? Evitar erros humanos, deve estar na linha de frente das nossas preocupações, podemos lidar com as duas etapas acima, fazendo o seguinte:

$ sls plugin install --name [plugin-name] -v

Na documentação, você também pode ver que é possível passar um número de versão para o comando:

$ sls plugin install --name [plugin-name]@[version] -v

Grandes coisas são feitas por uma série de pequenas coisas reunidas - Vincent Van Gogh

Depuração de variáveis do Serverless Framework

Quando você está desenvolvendo aplicativos serverless, um obstáculo comum é esse sentimento que você está desenvolvendo dentro de uma caixa preta. Isso significa que há tanta abstração acontecendo sob seus pés, que isso pode fazer você se sentir impotente diante de pequenos problemas, como uma variável que não resolve corretamente dentro do seu arquivo serverless.yml.

Bem, felizmente, existe um comando do Serverless Framework que ajuda você a superar esse obstáculo imprimindo o arquivo serverless.yml com todas as variáveis resolvidas:

$ sls print

Com o comando sls print, podemos ver o seguinte resultado do serverless.yml original:

service: real-time-weather
provider:
  name: aws
  stage: ${opt:stage, "dev"}
  region: ${opt:region, "us-west-2"}
  profile: ${opt:profile, "serverlessguru"}
custom:
  base: ${self:service}-${self:provider.stage}
  dyanmoDBUsersTable: ${self:custom.base}-users-table

Para o resolvido:

service: real-time-weather
provider:
  name: aws
  stage: dev
  region: us-west-2
  profile: serverlessguru
custom:
  base: real-time-weather-dev
  dyanmoDBUsersTable: real-time-weather-dev-users-table

E assim, somos capazes de encontrar facilmente que, nossa variável dynamoDBUsersTable usa o stage anexado ao nome e que, neste hipotético cenário, era o nosso problema.

Conteúdo adicional

O que faz o Serverless Guru?

No Serverless Guru, trabalhamos com empresas que querem acelerar sua migração para o desenvolvimento orientado a eventos em Serverless / Cloud Native. Ajudamos clientes com desenvolvimento em nuvem, desenvolvimento backend, desenvolvimento frontend, automação, melhores práticas e treinamento para equipes. Focamos em engenheiros primeiro.