AluraFlix Backend API Rest

Este é o projeto da API Rest do Challange Back End da Alura. #alurachallengeback

Sobre o projeto

Basicamente, este projeto busca fornecer os serviços de backend de uma nova plataforma de compartilhamento de vídeos. A plataforma deve permitir ao usuário montar playlists com links para seus vídeos preferidos, separados por categorias.

As principais funcionalidades a serem implementadas são:

1. API com rotas implementadas segundo o padrão REST;
2. Validações feitas conforme as regras de negócio;
3. Implementação de base de dados para persistência das informações;
4. Serviço de autenticação para acesso às rotas GET, POST, PUT e DELETE.

O projeto terá uma duração de 4 semanas, onde a cada semana teremos atividades específicas a serem desenvolvidas. A última semana será dedicada a resolver quaisquer tarefas pendentes ou realizar ajustes.

Ambiente de desenvolvimento:

• Windows 10: o SO da máquina de desenvolvimento;
• NodeJS: Para rodar o projeto em Back End;
• Framework Serverless: para gerenciar o ciclo de vida da aplicação e deploy na nuvem;
• Amazon AWS: responsável por nossa infraestrutura na nuvem (e total integração com Serverless Framework);
• DynamoDB: o DynamoDB é o banco de dados NoSQL da Amazon AWS.

Todo este stack de desenvolvimento é novidade para mim, e até o momento a escolha de uma arquitetura serverless, junto com NodeJS, é uma tentativa de aprender novas tecnologias. O banco de dados NoSQL veio de brinde durante os estudos da arquitetura.

Lembrem-se que em situações reais a escolha das tecnologias a serem utilizadas vai requerer uma análise mais profunda do negócio e ambiente corporativo. Neste caso, a análise girou em torno do meu aprendizado!

Como o Projeto Funciona?

O projeto é feito sobre o framework Serverless Framework com NodeJS, em conjunto com o Banco de Dados NoSQL DynamoDB.

Para as rotas, o Serverless Framework utiliza os serviços da Amazon API Gateway, com nosso código (as funções) executando em instâncias da AWS Lambda.

Por enquanto não estamos realizando o deploy na nuvem, mas rodando localmente nossa API, juntamente com uma instância local do DynamoDB que é inicializada on-demand.

Para instalar as dependências do projeto:

npm install

Em seguida, a biblioteca e plugin para utilização da instância local do DynamoDB:

serverless plugin install --name serverless-dynamodb-local
sls dynamodb install

Finalmente, para subir localmente nossa API:

sls offline start

Deploy

Como mencionado no começo do README, este projeto foi feito tendo em mente o deploy da nuvem da Amazon, a AWS. Supondo que o ambiente foi configurado de acordo com as instruções aqui presentes, basta executar o seguinte comando para disponibilizar a sua API na AWS:

sls deploy --stage release

A sua API será disponibilizada no caminho:

https://<aws-id>.execute-api.<region>.amazonaws.com/<stage>

onde

• <aws-id>: identificador atribuído pela AWS ao seu API Gateway;
• <region>: a região da AWS indicada por você, ou conforme definida nas configurações do projeto (serverless.yml);
• <stage>: o estágio do seu projeto para o qual vocês deseja implantar, indicada por você ou conforme definida nas configurações do projeto (serverless.yml).

Você pode perguntar ao framework se há um release já disponibilizado com o seguinte comando:

sls info --stage release

Remoto vs. Local

Encontrei as seguintes diferenças ao realizar o deploy entre os serviços local e remoto:

1. query string: como a API é disponibilizada com o protocolo seguro HTTPS, ao enviarmos nossos parâmetros codificados via URL (ver loginHandler.js), devemos decodificar as informações via base64url. Em um ambiente não seguro, esta decodificação não é necessária. Deste modo, verificamos o protocolo da requisição via cabeçalho x-forwarded-proto;
2. cabeçalho Authorization nas reposta: o API Gateway impõe certas restrições e limitações ao lidar com métodos com a integração do Lambda (utilizado aqui) ou a integração HTTP. Dentre estas limitações, está o cabeçalho de resposta Authorization, utilizado para retornar o token JWT ao cliente, sendo remapeado para x-amzn-remapped-authorization. Este problema é do interesse de qualquer front-end que deseje consumir nossa API. Não consegui encontrar uma solução adequada para esta questão. Maiores informações podem ser encontradas aqui.

Testes

Os testes da API Rest podem ser feitos pelo utilitário de linha de comando curl ou por um aplicativo de cliente de APIs. Optamos por esta última opção, utilizando o Insomnia. Os projeto do Insomnia está configurado somente para testes de integração locais.

Segurança com JWT

A autenticação de-facto do usuário não existe, somente obrigamos o envio de parâmetros específicos pelo método de login para gerar um token válido para a API. Os tokens também podem ser gerados (e validados) em https://jwt.io/, sendo necessário fornecer somente os parâmetros já mencionados e a sua chave secreta.

Logs

Depois de disponibilizada, você pode acompanhar as chamadas à sua API remotamente via o seguinte comando:

sls logs --function <function-name> --tail --stage release

onde <function-name> é o nome do seu método. Também é possivel consultar os logs via AWS CloudWatch.

Melhorias

Algumas funcionalidades ou atividades ficaram de fora:

1. testes unitários: não tive tempo de estudar um framework de testes unitários (em compensação, estudamos testes de integração na plataforma Insomnia e o padrão OpenAPI);
2. utilizar os métodos query do DynamoDB: é necessário definir adequadamente nossos schemas no framework de modelagem Dynamoose para utilizar o método de consulta query, mais performático, em todas as consultas;
3. integrar os parâmetros page e titulo: podemos realizar consultas paginadas e consultas a partir de um termo no título dos vídeos, mas não conseguimos realizar as duas ao mesmo tempo (paginação de uma consulta por vídeos a partir do título, ver item anterior);
4. implementar mecanismo para ligar ou desligar a autenticação/autorização para utilizar a API (útil para brincar com a integração com o front-end do Aluraflix);
5. integrar a solução de autenticação ao AWS Cognito ou realizar a implementaçao de um CRUD para usuários;
6. refatorar completamente a estrutura do projeto segundo os melhores padrões.