Computação sem servidor surgiu como resposta aos desafios das arquiteturas tradicionais baseadas em servidores. Com a computação sem servidor, os desenvolvedores já não precisam gerenciar ou dimensionar os servidores manualmente. Em vez disso, os fornecedores de nuvem assumem o gerenciamento da infraestrutura, permitindo que as equipes se concentrem exclusivamente na escrita e implantação de código.
As soluções sem servidor escalam automaticamente com base na demanda e oferecem um modelo de pagamento conforme uso. Isso significa que você paga apenas pelos recursos que sua aplicação realmente usa. Esta abordagem reduz significativamente os custos de operação, aumenta a flexibilidade e acelera os ciclos de desenvolvimento, tornando-a uma opção atraente para o desenvolvimento de aplicações modernas.
Ao abstrair o gerenciamento de servidores, as plataformas de computação sem servidor permitem que você se concentre na lógica de negócios e na funcionalidade da aplicação. Isto leva a implantações mais rápidas e a mais inovação. As arquiteturas sem servidor também são eventuais, o que significa que elas podem responder automaticamente a eventos em tempo real e escalar para atender às demandas do usuário sem intervenção manual.
Sumário
-
Passo 4: Configuraripelines de Implantação Multietapa para Ambientes de Dev e Prod
-
Passo 6: Testar e Validar APIs de Prod e Dev usando o Postman
Antes de mergulhar nos detalhes técnicos, vamos rever alguns conceitos-chave de fundo.
Conceitos importantes para entender
Interface de Programação de Aplicativos (API)
Uma API permite que aplicativos de software diferentes se comuniquem e interajam entre si. Ela define os métodos e formatos de dados que os aplicativos podem usar para solicitar e trocar informações para integração e partilha de dados entre sistemas diversos.
Métodos HTTP
Métodos HTTP ou métodos de solicitação são um componente crítico de serviços web e APIs. Eles indicam a ação desejada para ser executada em uma determinada URL de recurso na solicitação dada.
Os métodos mais comumente usados em APIs RESTful são:
-
GET: usado para recuperar dados de um servidor
-
POST: envia dados, incluídos no corpo da solicitação, para criar ou atualizar um recurso
-
PUT: atualiza ou substitui um recurso existente ou cria um novo recurso se ele não existir
-
DELETE: exclui os dados especificados do servidor.
Amazon API Gateway
Amazon API Gateway é um serviço gerenciado integralmente que facilita para os desenvolvedores criar, publicar, manter, monitorar esegurar APIs em escala. Ele atua como um ponto de entrada para múltiplas APIs, gerenciando e controlando as interações entre clientes (como aplicações web ou móveis) e serviços backend.
Ele também fornece várias funções, incluindo roteamento de solicitação, segurança, autenticação, cache e limitação de taxa, ajudando a simplificar o gerenciamento e implantação de APIs.
Amazon DynamoDB
DynamoDB é um serviço de banco de dados NoSQL gerenciado integralmente projetado para altas escalas, baixas latências e replicação de dados em várias regiões.
DynamoDB armazena dados em um formato sem esquema, permitindo o armazenamento e recuperação flexíveis e rápidos de dados estruturados e semi-estruturados. Ele é comumente usado para construir aplicações escaláveis e responsivas em ambientes baseados em nuvem.
Aplicação CRUD Sem Servidor
Uma aplicação CRUD sem servidor se refere à capacidade de Criar, Ler, Atualizar e Excluir dados. Mas a arquitetura e componentes envolvidos diferem de aplicações tradicionais baseadas em servidores.
Criar envolve adicionar novas entradas a uma tabela DynamoDB. A operação Ler recupera dados de uma tabela DynamoDB. Atualizar atualiza dados existentes em DynamoDB. E a operação Excluir exclui dados de DynamoDB.
O Serverless Framework
O Framework Serverless é uma ferramenta de código aberto que simplifica a implantação e gerenciamento de aplicações serverless em vários provedores de nuvem, incluindo a AWS. Ele abstrai a complexidade de provisionar e gerenciar infraestrutura, permitindo que desenvolvedores definam sua infraestrutura como código usando um arquivo YAML.
O framework cuida da implantação, escala e atualização de funções serverless, APIs e outros recursos.
GitHub Actions
GitHub Actions é uma poderosa ferramenta de automação de CI/CD que permite que desenvolvedores automatizem seus fluxos de trabalho de software diretamente do seu repositório no GitHub.
Com GitHub Actions, você pode criar pipelines personalizados acionados por eventos como envios de código, pull requests ou fusões de ramais. Esses fluxos de trabalho são definidos em arquivos YAML no repositório e podem executar tarefas como testar, compilar e implantar aplicações em vários ambientes.
Postman
Postman é uma plataforma de colaboração popular que simplifica o processo de design, teste e documentação de APIs. Oferece uma interface amigável para desenvolvedores criar e enviar requisições HTTP, testar pontos finais de API e automatizar fluxos de teste.
Então, agora que você está familiarizado com as ferramentas e tecnologias que vamos usar aqui, vamos começar.
Pré-requisitos
-
Node.js e npm instalados
-
AWS CLI configurado com acesso à sua conta AWS
-
Uma conta do Serverless Framework
-
Serverless Framework globalmente instalado no seu CLI local
Nosso Caso de Uso
Conheça Alyx, uma empreendedora que recentemente tem aprendido sobre arquitetura serverless. Ela leu sobre como é uma maneira poderosa e eficiente de construir backends para aplicações web, oferecendo uma abordagem mais moderna para o desenvolvimento de aplicações web.
Ela quer aplicar o que aprendeu até agora sobre os fundamentos da computação serverless da AWS. Ela sabe que serverless não significa que não há servidores envolvidos – na verdade, apenas abstrai a gestão e provisão de servidores. E agora ela quer focar apenas em escrever código e implementar a lógica de negócios.
Vamos ver como Alyx, a dona de uma cafeteria próspera, começa a aproveitar a arquitetura serverless para o backend de sua aplicação web.
Alyx’s Coffee Haven, uma loja de café online, oferece uma variedade de blends de café e guloseimas à venda. Inicialmente, Alyx gerenciava os pedidos e o estoque da loja com serviços de hospedagem web tradicionais, onde ela lidava com múltiplos servidores e recursos. Mas à medida que sua cafeteria crescia em popularidade, ela começou a enfrentar um número crescente de pedidos, especialmente durante horários de pico e promoções sazonais.
Gerenciar os servidores e garantir que a aplicação pudesse lidar com o aumento no tráfego se tornou um desafio para Alyx. Ela se via constantemente preocupada com a capacidade dos servidores, escalabilidade e o custo de manter a infraestrutura.
Ela também queria introduzir novos recursos como recomendações personalizadas e programas de fidelidade, mas isso se tornou uma tarefa intimidadora diante das limitações de seu setup tradicional.
Então a Alyx aprendeu sobre o conceito de serverless. Ela comparou um backend serverless a um barista que faz café em tempo real automaticamente, sem ela ter que se preocupar com os detalhes intrincados do processo de preparo do café.
Excitada com esta ideia, Alyx decidiu migrar o backend da sua cafeteria para uma plataforma serverless usando AWS Lambda, AWS API Gateway e Amazon DynamoDB. Esta configuração permitirá que ela se concentre mais em criar as melhores misturas de café e guloseimas para seus clientes.
Com o serverless, cada pedido do cliente se torna um evento que aciona uma série de funções serverless. Funções separadas do AWS Lambda processam os pedidos e gerenciam toda a lógica de negócios por trás das cenas. Por exemplo, cria o pedido de um cliente e consegue recuperar esse pedido. Também pode excluir o pedido de alguém ou atualizar o status de um pedido.
Alyx já não precisa se preocupar com a gestão de servidores, pois a plataforma serverless escala automaticamente para cima e para baixo com base nas solicitações de pedidos recebidas. Além disso, a eficiência de custo do serverless é enorme para a Alyx. Com um modelo de pagamento sob demanda, ela só paga pelo tempo de computação real que suas funções consomem, oferecendo-lhe uma solução mais econômica para seu negócio crescente.
Mas ela não para por aí! Ela também quer automatizar tudo, desde a implantação de infraestrutura até a atualização de sua aplicação sempre que houver um novo change. Utilizando Infraestrutura como Código (IaC) com o Serverless Framework, ela pode definir toda sua infraestrutura em código e gerenciá-la facilmente.
Além disso, ela configura GitHub Actions para integração e entrega contínuos (CI/CD), para que todas as mudanças que ela faz sejam implantadas automaticamente através de um pipeline, seja um novo recurso em desenvolvimento ou um hot fix para a produção.
Objetivos do Tutorial
-
Configurar o ambiente do Serverless Framework
-
Definir um API no arquivo YAML
-
Desenvolver funções AWS Lambda para processar operações CRUD
-
Configurar implantações multi-fases para Dev e Prod
-
Testar os pipelines Dev e Prod
-
Testar e validar APIs Dev e Prod usando Postman
Como começar: Clonar o Repositório Git
Acesse aqui .
Após clonar o repositório, você notará a presença de vários arquivos na sua pasta, como você pode ver na imagem abaixo. Usaremos todos esses arquivos para construir nossa API de cafeteria serverless.
Etapa 1: Configure o ambiente do Serverless Framework
Para configurar o ambiente do Serverless Framework para implantações automatizadas, você precisará autenticar sua conta do Serverless Framework via CLI.
Isso requer a criação de uma chave de acesso que habilite o pipeline CI/CD e utilize o Serverless Framework para autenticar com segurança em sua conta sem expor suas credenciais. Ao acessar sua conta do Serverless e gerar uma chave de acesso, o pipeline pode implantar sua aplicação serverless automaticamente a partir do arquivo de configuração de build.
Para fazer isso, vá para sua conta do Serverless e navegue até a seção Chaves de Acesso. Clique em “+add”, nomeie como SERVERLESS_ACCESS_KEY e depois crie a chave.
Uma vez criada sua chave de acesso, certifique-se de copiá-la e armazená-la com segurança. Você usará essa chave como uma variável secreta em seu repositório do GitHub para autenticar e autorizar seu pipeline CI/CD.
Vai fornecer acesso à sua conta do Serverless Framework durante o processo de implantação. Você adicionará esta chave aos segredos do repositório do GitHub mais tarde, para que sua pipeline possa usá-la de forma segura para implantar recursos serverless sem expor informações sensíveis em sua base de código.
Agora, vamos definir os recursos AWS como código no arquivo severless.yaml.
Etapa 2: Definir a API no arquivo YAML do Serverless
Neste arquivo, você definirá a infraestrutura e funcionalidade central da API da Loja de Café usando a configuração YAML do Serverless Framework.
Este arquivo define os serviços AWS sendo utilizados, incluindo o Gateway de API, funções Lambda para operações CRUD e DynamoDB para armazenamento de dados.
Você também configurará uma função IAM para que as funções Lambda tenham as permissões necessárias para interagir com o serviço DynamoDB.
O Gateway de API é configurado com os métodos HTTP apropriados (POST, GET, PUT e DELETE) para manipular as solicitações entrantes e acionar as funções Lambda correspondentes.
Vamos conferir o código:
service: coffee-shop-api
frameworkVersion: '4'
provider:
name: aws
runtime: nodejs20.x
region: us-east-1
stage: ${opt:stage}
iam:
role:
statements:
- Effect: Allow
Action:
- dynamodb:PutItem
- dynamodb:GetItem
- dynamodb:Scan
- dynamodb:UpdateItem
- dynamodb:DeleteItem
Resource: arn:aws:dynamodb:${self:provider.region}:*:table/CoffeeOrders-${self:provider.stage}
functions:
createCoffee:
handler: createCoffee.handler
environment:
COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage}
events:
- http:
path: coffee
method: post
getCoffee:
handler: getCoffee.handler
environment:
COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage}
events:
- http:
path: coffee
method: get
updateCoffee:
handler: updateCoffee.handler
environment:
COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage}
events:
- http:
path: coffee
method: put
deleteCoffee:
handler: deleteCoffee.handler
environment:
COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage}
events:
- http:
path: coffee
method: delete
resources:
Resources:
CoffeeTable:
Type: AWS::DynamoDB::Table
Properties:
TableName: CoffeeOrders-${self:provider.stage}
AttributeDefinitions:
- AttributeName: OrderId
AttributeType: S
- AttributeName: CustomerName
AttributeType: S
KeySchema:
- AttributeName: OrderId
KeyType: HASH
- AttributeName: CustomerName
KeyType: RANGE
BillingMode: PAY_PER_REQUEST
A configuração serverless.yml define como a API da Loja de Café da Alyx será executada em um ambiente serverless no AWS. A seção provider especifica que o aplicativo usará o AWS como provedor de nuvem, com Node.js como o ambiente de tempo de execução.
A região está definida como us-east-1 e a variável stage permite oPLOY de forma dinâmica em diferentes ambientes, como dev e prod. Isso significa que o mesmo código pode ser implantado em diferentes ambientes, com recursos nomeados de acordo para evitar conflitos.
Na seção iam, as permissões são concedidas às funções Lambda para interagir com a tabela DynamoDB. A sintaxe ${self:provider.stage} nomeia dinamicamente a tabela DynamoDB, de forma que cada ambiente tenha seus próprios recursos separados, como CoffeeOrders-dev para o ambiente de desenvolvimento e CoffeeOrders-prod para a produção. Esse nomeação dinâmica ajuda a gerenciar vários ambientes sem configurar manualmente tabelas separadas para cada um.
A seção functions define as quatro funções Lambda principais, createCoffee, getCoffee, updateCoffee e deleteCoffee. Estas lidam com as operações CRUD para a API Coffee Shop.
Cada função está conectada a um método HTTP específico no Gateway de API, como POST, GET, PUT e DELETE. Essas funções interagem com a tabela DynamoDB que é nomeada dinamicamente com base na fase atual.
A última seção resources define a própria tabela DynamoDB. Ela configura a tabela com os atributos OrderId e CustomerName, que são usados como chave primária. A tabela é configurada para usar um modo de cobrança por solicitação, tornando-se economicamente eficiente para o negócio crescente da Alyx.
Ao automatizar a implantação desses recursos usando o Framework Serverless, a Alyx pode gerenciar facilmente sua infraestrutura, livrando-a do fardo de provisionar e escalar recursos manualmente.
Etapa 3: Desenvolver as Funções Lambda para Operações CRUD
Nesta etapa, implementamos a lógica central da API da Loja de Café da Alyx criando funções Lambda com JavaScript que realizam as operações CRUD essenciais createCoffee, getCoffee, updateCoffee e deleteCoffee.
Estas funções utilizam a AWS SDK para interagir com os serviços da AWS, particularmente o DynamoDB. Cada função será responsável por lidar com solicitações de API específicas, como criar um pedido, recuperar pedidos, atualizar status de pedidos e excluir pedidos.
Função Lambda Create Coffee
Esta função cria um pedido:
const AWS = require('aws-sdk');
const dynamoDb = new AWS.DynamoDB.DocumentClient();
const { v4: uuidv4 } = require('uuid');
module.exports.handler = async (event) => {
const requestBody = JSON.parse(event.body);
const customerName = requestBody.customer_name;
const coffeeBlend = requestBody.coffee_blend;
const orderId = uuidv4();
const params = {
TableName: process.env.COFFEE_ORDERS_TABLE,
Item: {
OrderId: orderId,
CustomerName: customerName,
CoffeeBlend: coffeeBlend,
OrderStatus: 'Pending'
}
};
try {
await dynamoDb.put(params).promise();
return {
statusCode: 200,
body: JSON.stringify({ message: 'Order created successfully!', OrderId: orderId })
};
} catch (error) {
return {
statusCode: 500,
body: JSON.stringify({ error: `Could not create order: ${error.message}` })
};
}
};
Esta função Lambda trata a criação de um novo pedido de café na tabela DynamoDB. Primeiro nós importamos a AWS SDK e inicializamos um DynamoDB.DocumentClient para interagir com o DynamoDB. A biblioteca uuid também é importada para gerar IDs de pedido exclusivos.
Dentro da função handler, nós analisamos o corpo da solicitação recebida para extrair informações do cliente, como o nome do cliente e a mistura de café preferida. Um único orderId é gerado usando uuidv4() e esses dados são preparados para inserção no DynamoDB.
O objeto params define a tabela onde os dados serão armazenados, com TableName definido dinamicamente para o valor da variável de ambiente COFFEE_ORDERS_TABLE. O novo pedido inclui campos como OrderId, CustomerName, CoffeeBlend, e um status inicial de Pending.
No bloco try, o código tenta adicionar o pedido à tabela DynamoDB usando o método put(). Se bem-sucedido, a função retorna um código de status de 200 com uma mensagem de sucesso e o OrderId. Se houver um erro, o código captura-o e retorna um código de status de 500 juntamente com uma mensagem de erro.
Função Get Coffee Lambda
Esta função recupera todos os itens de café:
const AWS = require('aws-sdk');
const dynamoDb = new AWS.DynamoDB.DocumentClient();
module.exports.handler = async () => {
const params = {
TableName: process.env.COFFEE_ORDERS_TABLE
};
try {
const result = await dynamoDb.scan(params).promise();
return {
statusCode: 200,
body: JSON.stringify(result.Items)
};
} catch (error) {
return {
statusCode: 500,
body: JSON.stringify({ error: `Could not retrieve orders: ${error.message}` })
};
}
};
Esta função Lambda é responsável por recuperar todos os pedidos de café de uma tabela DynamoDB e exemplifica uma abordagem sem servidor para recuperar dados de DynamoDB de forma escalável.
Novamente, usamos o AWS SDK para inicializar uma instância de DynamoDB.DocumentClient para interagir com DynamoDB. A função handler constrói o objeto params, especificando o TableName, que é definido dinamicamente usando a variável de ambiente COFFEE_ORDERS_TABLE.
O método scan() recupera todos os itens da tabela. novamente, se a operação for bem-sucedida, a função retorna um código de status 200 junto com os itens recuperados no formato JSON. Caso ocorra um erro, é retornado um código de status 500 e uma mensagem de erro.
Atualizar função de Café Lambda
Esta função atualiza um item de café por seu ID:
const AWS = require('aws-sdk');
const dynamoDb = new AWS.DynamoDB.DocumentClient();
module.exports.handler = async (event) => {
const requestBody = JSON.parse(event.body);
const { order_id, new_status, customer_name } = requestBody;
const params = {
TableName: process.env.COFFEE_ORDERS_TABLE,
Key: {
OrderId: order_id,
CustomerName: customer_name
},
UpdateExpression: 'SET OrderStatus = :status',
ExpressionAttributeValues: {
':status': new_status
}
};
try {
await dynamoDb.update(params).promise();
return {
statusCode: 200,
body: JSON.stringify({ message: 'Order status updated successfully!', OrderId: order_id })
};
} catch (error) {
return {
statusCode: 500,
body: JSON.stringify({ error: `Could not update order: ${error.message}` })
};
}
};
Esta função Lambda trata da atualização do status de um pedido de café específico na tabela DynamoDB.
A função handler extrai o order_id, new_status e customer_name do corpo da requisição. Então, ela constrói o objeto params para especificar o nome da tabela e a chave primária para o pedido (usando OrderId e CustomerName). A UpdateExpression define o novo status do pedido.
No bloco de try, o código tenta atualizar o pedido em DynamoDB usando o método update(). Novamente, claro, se bem-sucedida, a função retorna um código de status 200 com uma mensagem de sucesso. Se ocorrer um erro, ela captura o erro e retorna um código de status 500 juntamente com uma mensagem de erro.
Excluir função de Café Lambda
Esta função exclui um item de café por seu ID:
const AWS = require('aws-sdk');
const dynamoDb = new AWS.DynamoDB.DocumentClient();
module.exports.handler = async (event) => {
const requestBody = JSON.parse(event.body);
const { order_id, customer_name } = requestBody;
const params = {
TableName: process.env.COFFEE_ORDERS_TABLE,
Key: {
OrderId: order_id,
CustomerName: customer_name
}
};
try {
await dynamoDb.delete(params).promise();
return {
statusCode: 200,
body: JSON.stringify({ message: 'Order deleted successfully!', OrderId: order_id })
};
} catch (error) {
return {
statusCode: 500,
body: JSON.stringify({ error: `Could not delete order: ${error.message}` })
};
}
};
A função Lambda exclui uma ordem específica de café da tabela DynamoDB. Na função handler, o código analisa o corpo da solicitação para extrair o order_id e o customer_name. Esses valores são usados como chave primária para identificar o item a ser excluído da tabela. O objeto params especifica o nome da tabela e a chave do item a ser excluído.
No bloco try, o código tenta excluir a ordem do DynamoDB usando o método delete(). Se for bem-sucedido, novamente retorna um código de status 200 com uma mensagem de sucesso, indicando que a ordem foi excluída. Se ocorrer um erro, o código captura-o e retorna um código de status 500 juntamente com uma mensagem de erro.
Agora que explanamos cada função Lambda, vamos configurar uma pipeline CI/CD multiestágio.
Etapa 4: Configurar Implantações de Pipeline CI/CD Multiestágio para Ambientes de Desenvolvimento e Produção
Para configurar segredos AWS em seu repositório GitHub, primeiro navegue até as configurações do repositório. Selecione Settings no canto superior direito, então vá para o canto inferior esquerdo e selecione Secrets and variables.
Em seguida, clique em Actions como mostrado na imagem abaixo:
Depois disso, selecione New repository secret para criar segredos.
São necessários três segredos para criar para sua pipeline, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY e SERVERLESS_ACCESS_KEY.
Use suas credenciais de acesso da chave do AWS para as duas primeiras variáveis e, em seguida, a chave de acesso sem servidor salva anteriormente para criar a SERVERLESS_ACCESS_KEY. Esses segredos autenticarão sua pipeline CI/CD de forma segura, como visto na imagem abaixo.
Certifique-se de que seu branch principal seja nomeado “main,” pois esse será o branch de produção. Em seguida, crie um novo branch chamado “dev” para o trabalho de desenvolvimento.
Você também pode criar branches específicos para recursos, como “dev/feature,” para um desenvolvimento mais granular. As GitHub Actions usarão esses branches para implantar mudanças automaticamente, com o dev representando o ambiente de desenvolvimento e o main representando a produção.
Essa estratégia de branching permite gerenciar a pipeline CI/CD de forma eficiente, implantando novas mudanças de código sempre que houver uma mesclagem no dev ou no ambiente prod.
Como usar o GitHub Actions para implantar o arquivo YAML
Para automatizar o processo de implantação para a API Coffee Shop, você usará o GitHub Actions, que se integra com o seu repositório do GitHub.
Essa pipeline de implantação é acionada sempre que o código é enviado para os branches main ou dev. Ao configurar implantações específicas para o ambiente, você garante que as atualizações no branch dev sejam implantadas no ambiente de desenvolvimento, enquanto as mudanças no branch main acionam implantações de produção.
Agora, vamos rever o código:
name: deploy-coffee-shop-api
on:
push:
branches:
- main
- dev
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: '20.x'
- name: Install dependencies
run: |
cd coffee-shop-api
npm install
- name: Install Serverless Framework
run: npm install -g serverless
- name: Deploy to AWS (Dev)
if: github.ref == 'refs/heads/dev'
run: |
cd coffee-shop-api
npx serverless deploy --stage dev
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
SERVERLESS_ACCESS_KEY: ${{secrets.SERVERLESS_ACCESS_KEY}}
- name: Deploy to AWS (Prod)
if: github.ref == 'refs/heads/main'
run: |
cd coffee-shop-api
npx serverless deploy --stage prod
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
SERVERLESS_ACCESS_KEY: ${{secrets.SERVERLESS_ACCESS_KEY}}
A configuração YAML do GitHub Actions é o que automatiza o processo de implantação do Coffee Shop API para o AWS usando o Serverless Framework. O workflow é disparado sempre que houver mudanças enviadas para as branches principal ou de desenvolvimento.
Ele começa verificando o código do repositório, depois configura o Node.js com a versão 20.x para coincidir com a versão de runtime usada pelas funções Lambda. Depois disso, instala as dependências do projeto navegando para o diretório coffee-shop-api e executando npm install.
O workflow também instala o Serverless Framework globalmente, permitindo que a CLI serverless seja usada para implantações. Dependendo de qual branch for atualizada, o workflow implanta condicionalmente para o ambiente apropriado.
Se as mudanças forem enviadas para a branch de desenvolvimento, elas são implantadas para a etapa de desenvolvimento. Se forem enviadas para a branch principal, são implantadas para a etapa de produção. Os comandos de implantação, npx serverless deploy --stage dev ou npx serverless deploy --stage prod são executados dentro do diretório coffee-shop-api.
Para uma implantação segura, o workflow acessa as credenciais AWS e a chave de acesso Serverless via variáveis de ambiente armazenadas em Segredos do GitHub. Isso permite que o pipeline CI/CD se autentique com AWS e o Serverless Framework sem expor informações sensíveis no repositório.
Agora, podemos prosseguir para testar o pipeline.
Passo 5: Teste o Pipeline Dev e Prod
Primeiro, você precisará verificar se a ramificação principal (prod) é chamada de “main”. Depois, crie uma ramificação de desenvolvimento chamada “dev”. Assim que você fizer quaisquer alterações válidas na ramificação de desenvolvimento, confirme-as para acionar o pipeline de GitHub Actions. Issoirá deployar automaticamente os recursos atualizados no ambiente de desenvolvimento. Após verificar tudo no desenvolvimento, você pode então mesclar a ramificação de desenvolvimento com a ramificação principal.
A mesclagem de alterações na ramificação principal também aciona automaticamente o pipeline de deploy para o ambiente de produção. Dessa forma, todas as atualizações necessárias são aplicadas e os recursos de produção são deployados sem problemas.
Você pode monitorar o processo de deploy e rever os logs detalhados de cada execução de GitHub Actions navegando até a aba Actions no seu repositório do GitHub.
Os logs fornecem visibilidade a cada etapa do pipeline, ajudando você a verificar se tudo está funcionando como esperado.
Você pode selecionar qualquer execução de build para rever logs detalhados para os deploys dos ambientes de desenvolvimento e produção, para que você possa acompanhar o progresso e garantir que tudo está ocorrendo sem problemas.
Navegue até a execução específica de build em GitHub Actions, conforme demonstrado na imagem abaixo. Lá, você pode ver os detalhes de execução e os resultados para os pipelines de desenvolvimento ou produção.
Garanta que você testa completamente ambos os ambientes de desenvolvimento e produção para confirmar a execução bem-sucedida do pipeline.
Passo 6: Teste e Valide as APIs de Prod e Dev usando o Postman.
Agora que as APIs e recursos estão implantados e configurados, precisamos localizar os pontos de extremidade de API exclusivos (URLs) gerados pelo AWS para começar a fazer solicitações para testar a funcionalidade.
Estas URLs podem testar a funcionalidade da API simplesmente colando-os em um navegador da web. As URLs da API são encontradas nos resultados de saída do seu build CI/CD.
Para recuperá-las, navegue até os registros do GitHub Actions, selecione o build bem-sucedido do ambiente mais recente e clique em deploy para verificar os detalhes do deploy dos pontos de extremidade da API gerados.
Clique na etapa Deploy to AWS para o ambiente selecionado (Prod ou Dev) em seus registros do GitHub Actions. Uma vez lá, você encontrará a URL da API gerada.
Copie e salve esta URL, pois ela será necessária ao testar a funcionalidade da sua API. Esta URL é a sua porta de entrada para verificar se a API implantada está funcionando conforme o esperado.
Agora copie uma das URLs de API geradas e cole-a no seu navegador. Você verá um array ou lista vazia exibida na resposta. Isso na verdade confirma que a API está funcionando corretamente e que você está recuperando com sucesso dados da tabela DynamoDB.
Embora a lista esteja vazia, ela indica que a API pode conectar ao banco de dados e retornar informações.
Para verificar se sua API funciona em ambos os ambientes, repita as etapas para o outro ambiente de API (Prod e Dev).
Para um teste mais abrangente, usaremos o Postman para testar todos os métodos da API, Create, Read, Update e Delete, e executaremos esses testes para os ambientes de desenvolvimento e produção.
Para testar o método GET, use o Postman para enviar uma solicitação GET para o endpoint da API usando o URL. Receberá a mesma resposta, uma lista vazia de pedidos de café, como se vê na parte inferior da imagem abaixo. Isso confirma a capacidade da API de recuperar dados com êxito, conforme mostrado na imagem abaixo.
Para realmente criar um pedido, vamos testar o método POST. Use o Postman novamente para fazer uma solicitação POST para o endpoint da API, fornecendo o nome do cliente e a mistura de café no corpo da solicitação, como mostrado abaixo :
{
"customer_name": "REXTECH",
"coffee_blend": "Black"
}
A resposta será uma mensagem de sucesso com um OrderId exclusivo do pedido feito.
Verifique se o novo pedido foi salvo na tabela do DynamoDB revisando os itens na tabela específica de ambientes :
Para testar o método PUT, faça uma solicitação PUT para o endpoint da API fornecendo o ID do pedido anterior e um novo status do pedido no corpo da solicitação, conforme mostrado abaixo :
{
"order_id": "42a81c27-1421-4025-9bef-72b14e723c34",
"new_status": "Ready",
"customer_name": "REXTECH"
}
A resposta será uma mensagem de atualização de pedido bem-sucedida com o OrderId do pedido feito.
Você também pode verificar se o status do pedido foi atualizado a partir do item da tabela DynamoDB.
Para testar o método DELETE, usando o Postman, faça uma solicitação DELETE fornecendo o ID do pedido anterior e o nome do cliente no corpo da solicitação, conforme mostrado abaixo:
{
"order_id": "42a81c27-1421-4025-9bef-72b14e723c34",
"customer_name": "REXTECH"
}
Mensagem de exclusão de pedido bem-sucedida com o ID do pedido
Novamente, você pode verificar que o pedido foi excluído na tabela DynamoDB.
Conclusão
É isso mesmo – parabéns! Você concluiu com sucesso todos os passos. Nós construímos uma API REST sem servidor que suporta funções CRUD (Criar, Ler, Atualizar, Excluir) com API Gateway, Lambda, DynamoDB, Serverless Framework e Node.js, automatizando a implantação de mudanças de código aprovadas com Github Actions.
Se você chegou até aqui, obrigado por ler! Espero que tenha sido interessante para você.
Ifeanyi Otuonye é um Engenheiro de Cloud AWS certificado 6X com habilidades em DevOps, Redação Técnica e experiência instrucional como Instrutor Técnico. Ele é motivado pela sua curiosidade e ambição e se destaca em ambientes colaborativos. Antes de se mudar para a Cloud, passou seis anos como atleta profissional de atletismo.
No início de 2022, ele iniciou uma missão estratégica para se tornar um Engenheiro de Cloud/DevOps por estudo autodidata e participando the um programa acelerado de Cloud de 6 meses.
Em maio de 2023, concluiu esse objetivo e obteve seu primeiro papel de Engenheiro de Cloud e agora definiu outro objetivo pessoal para empower outras pessoas em seu caminho para a Cloud.
Source:
https://www.freecodecamp.org/news/how-to-build-a-serverless-crud-rest-api/