https://github.com/miguelprogrammer/process-video
Projeto - Pós-graduação FIAP
https://github.com/miguelprogrammer/process-video
clean-architecture continuous-deployment continuous-integration devops docker gihub-actions junit mockito swagger-ui threads
Last synced: 10 months ago
JSON representation
Projeto - Pós-graduação FIAP
- Host: GitHub
- URL: https://github.com/miguelprogrammer/process-video
- Owner: MiguelProgrammer
- License: mit
- Created: 2025-01-15T14:37:38.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2025-02-08T15:40:10.000Z (over 1 year ago)
- Last Synced: 2025-03-13T22:12:53.592Z (over 1 year ago)
- Topics: clean-architecture, continuous-deployment, continuous-integration, devops, docker, gihub-actions, junit, mockito, swagger-ui, threads
- Language: HTML
- Homepage:
- Size: 9.68 MB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# process-video
Projeto para finalizar última entrega - Pós-graduação FIAP
## Miro - DDD
link para leitura: Doc Domain Driven Design
##
A ideia por de trás deste conceito é a de receber um vídeo ou mais, realizar o processamento dos mesmos, tirar prints de cada frame sem que nenhum se perca,
persistir os prints em base dados. Como arquiteto, a primeira questão a se pensar é a de "custos". Quão será custoso para realizar tal tarefa de processamento de tais arquivos,
mante-los em base dedados e consumi-los. A princípio, para as tarefas mais simples, pensando a baixo nível, seria uma aplicação com persistência poliglota,
será necessário um banco de dados que trabalhe com chave e valor como o MongoDB 
para persistir nossos prints e um outro banco como PostgreSql
para persistir informações referente ao tipo de arquivo enviado.
##
Após criação dos itens para persistir nossos arquivos e informações, partimos para a parte de processamento, preciso que cada video encaminhado para o processamento não interrompido,
vejo uma alternativa como um serviço reativo talvez, mensageria.
##
A arquitetura a ser adotada para este projeto sera clean architecture.
##
A arquitetura limpa coopera com o business, organização, design e manutenibilidade, sempre respeitando os adapters e gateways.
Na medida em que a construção e implementação das features, venho analisando melhor a arquitetura e me pergunto se não seria melhor para esse cenário a arquiteura event-drive,
como prentendo criar um serviço assíncrono, irei utilizar apache kafka para enfileirar meus objetos para que eu possa ter mais organização de fluxo de request e esta arquitetura coopera
bastante com esse cenário, possa ser que eu mude ao final do projeto.
##
Infelizmente, não pude adotar a arquitetura voltada a eventos event-driven. Esta arquitetura lida diretamente com filas, processos assíncronos, e para este cenário,
não pude utilza-la, a um certo limite de bytes para usar filas e o kafka não iria suportar o tamanho da stream. Então parti para serviços não blockantes.
Brinquei bastante com spring webflux 
.
Pode-se dizer que apanhei bastante para inserir uma api reativa ao meu cenário, até consegui, mas como já tinha meu usecase pronto para lidar com um certo tipo de entreda,
removi o spring webflux, tente lidar com arquivo e processa-los, persisti-los e recupera-los, é uma insana codifiação.
Ao final, fui para o simples, subi o tento do Java na aplicação, sai do Java17 e fui para Java21, assim eu posso trabalhar com threads virtuais, nos meus testes, as requisições foram bem sucedidas,
porém, minha rest-api atua blockante, é um trade-off que minha arquitetura adotada me atribuiu, o famoso Over-engineering.
Tudo isso é muito interessante, houve momentos em que parti para o que realmente interessa, yagne, mas após todo esse processo de refactoring, percebi que é necessário se pensar com clareza
na adoção das coisas simples, na medida em que você constroi a aplicação, você precisa analisar se está pensando em atender o problema ou usar tal arquitetura ou padrão de projeto.
Encontri diversas falhas durante o processo de desenvolvimento, realizaei diversas alterações, depuração, debugs, logs e outros meios mais de me esgotar ao ponto de volta ao início do problema e
partir para a adoção do simples. Este projeto cooperou bo quesito visão arquitetural.
## Tests - Unit, Integration and System
Cobertura baixa de testes, mas existe teste.
## Docker Hub
A imagem da aplicação está disponibilizada no DockerHub
ou baixe a imagem agora mesmo
```
docker push migprogrammer/process-videos:tagname
```
Observações e considerações: Ao abaixar a imagem, será necessário ter o banco NoSql MongoDb instalado, também, deixe os seus vídeos nao seguinte
diretório 'C:\videos'.
## Observabilidade - Dynatrace
Usei o Dynatrace para ver como a aplicação lidá com o processamento de videos e geração de imagens
