04-Recursos Avançados

Prévia do material em texto

Recursos Avançados
Arquivos Estáticos
 
Arquivos estáticos são arquivos que não possuem dinâmica ou alteração,
como imagens, documentos, arquivos de CSS ou vetores, por exemplo.
Uma API pode prover diversos tipos de arquivos e, portanto, ao construir
uma API usando a biblioteca Express, o middleware Multer pode ser
usado como dependência de projeto para gerenciar esta seção.
 
Quando se trata da tarefa de realizar upload de arquivos, ao incluí-lo no
projeto, basta que este seja inicializado e configurado conforme desejado,
sendo definido o diretório de destino de uploads e construção de nome de
arquivo. Por fim, adicione o middleware para interceptar a requisição e
capturar as informações do(s) arquivo(s). Todos os dados são enviados
pelo corpo da requisição (observe o arquivo uploadconfig.js). A imagem
abaixo representa as demais formas de se incluir um middleware que
atenda a diversos tipos de requisições HTTP onde arquivos são enviados:
Quando se trata da tarefa de prover arquivos estáticos, basta que na API
seja configurada uma rota, juntamente com o diretório em que os arquivos
se encontram armazenados (observe a linha 9 do arquivo index.js). Dessa
forma, ao acionar a rota para busca de imagens e possuir uma
correspondência, o arquivo então será retornado.
 
Arquivos Estáticos
 
Não é uma boa prática de usabilidade/experiência de usuário emitir erros
de forma técnica, com diversos códigos e dizeres do stack trace. É uma
prática comum o desenvolvedor construir as próprias classes de erro da
aplicação para gerenciamento e controle do fluxo do programa, realizando
operações como inclusão de logs e demais outras, como o tratamento da
exceção, informando ao usuário uma mensagem coerente e que dê
direcionamentos (observe a classe ApplicationError). 
 
Independente do erro, a exceção será tratada no middleware responsável.
Devendo ser inserido como último item, após a declaração das rotas, pois
a leitura do código é realizada de forma sequencial (observe o final do
arquivo index.js). Seu diferencial é possuir quatro parâmetros de entrada:
os objetos error, request, response e next.
 
Autenticação
 
Uma das formas mais comuns de integração entre aplicações e serviços é
através de um token de acesso. Nesta disciplina, será utilizado o JWT
(JSON Web Token), token responsável por armazenar informações do
usuário e que possui uma expiração, como um voucher de acesso, um
crachá.
 
Relacionando com o cenário da API, comumente existe uma rota
específica para envio de dados para autenticação e integração com banco
de dados. Em seguida, um token é retornado para uso no cabeçalho das
demais requisições: o Authorization. Dessa forma, ao utilizar o
Authorization header com o token obtido, as requisições são identificadas,
garantindo que são provenientes de um usuário conhecido (ou não).
 
Diversas bibliotecas são utilizadas para geração do JWT. Para esta
disciplina, será utilizada a jsonwebtoken como dependência de projeto.
Este módulo possui basicamente duas funções: sign e verify,
responsáveis pela assinatura (observe a rota autenticação) e verificação
do token (observe o middleware validaToken), respectivamente.
 
Design Patterns
 
À medida que um projeto cresce ou é compartilhado com outras pessoas,
é importante que esteja estruturado seguindo boas práticas de
desenvolvimento para garantir a separação de conceitos e organização do
código-fonte. Dessa forma, dois padrões se tornam ótimos exemplos para
aplicação deste projeto. São eles:
 
● Repository pattern
•
Padrão que tem como objetivo garantir reaproveitamento de
código-fonte, abstraindo a camada de persistência de dados.
•
Assim, independente da função desejada (consulta, inserção ou
alteração do banco de dados), esta pode ser acionada não
dependendo diretamente do modo como as informações são
produzidas.
•
Esta metodologia está contida no princípio DIP (Dependency
Injection Principle), onde uma entidade deve depener apenas de
abstrações e não implementações.
● Service pattern
•
Padrão que tem como objetivo o isolamento das regras de negócio
para funções específicas para processamento de dados. Dessa
forma, se garante a separação de conceitos, uma vez que as
responsabilidades das funcionalidades são organizadas.
•
Esta metodologia está contida no princípio SSP (Single
Responsability Principle), onde uma classe deve possuir uma e
apenas uma responsabilidade.
•
Assim, evita-se a repetição de códigos padronizados na
construção de programas.
 
Todas as responsabilidades citadas estão de acordo com o SOLID: sigla
que representa os 5 princípios da programação orientada a objetos:
 
• SRP (Single Responsability Principle)
• OCP (Open–closed Principle)
• LSP (Liskov substitution Principle)
• ISP (Interface segregation Principle)
• DIP (Dependency Inversion Principle).
 
 
 
Atividade extra
 
Considerando os princípios SOLID, um bom entendimento e aplicação
destes princípios fazem com que um desenvolvedor se destaque em sua
carreira. Dessa forma, sugiro a leitura do artigo: “The S.O.L.I.D Principle in
Pictures”, traduzido e disponível no endereço:
<https://translate.google.com/translate?
sl=en&tl=pt&u=https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-
in-pictures-b34ce2f1e898>.
 
 
 
 
Referências Bibliográficas
 
•
Robert C. Martin. Principles of OOD. Disponível em:
<http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod>. Acesso
em: 13 de abr. de 2021.
•
Multer. Disponível em: <https://github.com/expressjs/multer>. Acesso
em: 13 de abr. de 2021.
•
JWT. Disponível em: <https://jwt.io>. Acesso em: 13 de abr. de 2021.
Ir para questão