Sobre arquitetura do sistema

[joepreludian]

Opa @lipe14-ops. Certinho, meu nobre? Comecei a fazer alguns testes aqui no seu projeto e me veio algumas dúvidas sobre a arquitetura que voce está utilizando na sua lib.

Eu percebi que voce está orientado por uma estrutura de dados baseado pelas rotas GET. Daí voce utilizou a estratégia de usar o método call pra montar a chamada dinamicamente.

Bom, Essa estratégia é massa pq a medida que novas requisições forem adicionadas, poderiamos apenas modificar chamada o dicionário de rotas.

O problema, entretanto, se torna interessante quando usamos uma IDE. Eu gostaria de entender bem qual é sua estratégia usando as entidades, dtos e adapters. Certamente não peguei bem a ideia. =D

Ah, e obrigado por sua atenção antemão!

[lipe14-ops]

Bom dia @joepreludian!!! Me desculpe pela a demora.

Para ser bem sincero não teve um estratégia bem definida. A idéia era a criação de rotas dinâmicas apenas adicionando a rota no dicionário. Os adapters e os DTOs tem apenas a função de tornar isso mais dinâmico e mais expandível conforme o projeto do brasilapy e o BrasilAPI cresça para que não haja muitos problemas na hora de adicionar novas rotas ou features mantendo assim um certo isolamento a cada função e classe, assim ela funcionaria totalmente indepêndende de outras partes do código.

espero que você tenha entendido haha

obrigado pelo interesse!!! : )

[joepreludian]

Então. Entendi bem, mas achei que tem um recurso que é fundamental para uma boa testagem do código que vale a pena codificar localmente, que seria o type hinting.

Quando comecei a escrever os testes eu senti uma certa dificuldade de entender o caminho por onde ia a request até o final. E quando você faz a requisição você pega o conteúdo como um dicionário e retorna para o usuário, não é?

O que eu pensei pode parecer um pouco audacioso no início, mas levaria sua lib a um patamar mais interessante. Por exemplo, nessa abordagem que estou trazendo pra discussão, pensei em usar uma abordagem em cima dos Models do pydantic. Eles são intercambiáveis com o payload json além de oferecer uma forma de servir como typed hinting pra os códigos, e uma validação do modelo em si.

Nessa minha implementação consegui 100% de coverage, mantendo a elegância que você vem fazendo no seu código.

Farei assim. Acho que hoje eu concluo as outras chamadas de API. Agora mesmo só fiz para o banco.

Terminarei as chamadas como imagino, deixo com a cobertura de testes e levando o projeto no codecov e sonarcloud (seguindo o mesmo padrão do repositório oficial) e crio uma grande PR para seu escrutínio.

Daí a gente pode pensar a partir daí uma forma de ir adicionando mais coisas. Mas em suma, tirei a questão de ser automático em prol de uma boa cobertura por typed hinting. Acho que com isso a adesão será extremamente maior.

Abraço, amigo e obrigado mais uma vez pelo contato. Ah. E não precisa pedir desculpas quanto ao tempo pra responder. Acabei me empolgando ontem construindo os testes. Rs

[lipe14-ops]

Boa noite!!!

Ótima ideia, confesso que não havia tido a ideia de fazer a tipagem do response e acho q a lib pydandic seria perfeita para isso, como dito é muito útil para a validação dos dados e tipagem.

Parabéns pela ideia, sua ajuda é sempre bem vinda!!! Caso queira um contantato mais pessoal minhas redes sociais estão no meu readme.

[joepreludian]

Claro, amigo. Irei adicioná-lo, então. :) Abraço.

[joepreludian]

Então... segue um pouco do racional da ideia que eu utilizei para fazer as coisas funcionarem no PR #3

Motivação

A ideia que eu mantive na mente ao pensar nessa variação do projeto v1 foi:

1. A API precisa prover um código que seja de fácil leitura e manutenção;
2. Possua a capacidade de previsibilidade do código, facilitando o processo de inferência dos métodos por meio de Typed Hints. Com isso IDEs serão capazes de fornecer uma forma de autocompletar o código, tornando a adesão do projeto cada vez mais forte, tanto por pequenos usuários quanto como por grandes empresas que usarão a ferramenta de maneira profissional.
3. Possua uma boa cobertura por testes. Isso fará com que o código seja previsível e possa evoluir de maneira segura e descentralizada. Voce poderia fazer a triagem com muito mais confidência.

Estratégia de implementação

Basicamente pensei na seguinte estrutura:

• brasilapy
  • client -> Contém a lógica responsável por buscar as informações e retornar usando os modelos do Pydantic
  • models -> Oferece a lista dos modelos do pydantic que representarão os dados, fazendo uma validação básica: tipo, campos que usam datas, ele já faz o parte para "date", campos booleanos, da mesma forma, assim como floats e str.
  • constants -> Possui uma série de classes com dados que podemos utilizar para fornecer informações específicas por meios de constantes. Ex: ao invés de usarmos um tipo para a tabela fipe como "carro", usamos FipeTipoVeiculo.CARROS. Isso, além de melhorar a legibilidade, nos dá controle sobre os valores que podemos colocar lá de maneira previsível.
  • exceptions -> Todas as exceptions serão concentradas aqui. atualmente ele lida apenas com aquelas chamadas incorretas, que poderão ser tratadas de maneira transparente.
  • processor -> Aqui pensei em criar um adaptador que conecta ao nosso cliente e que ficará responsável por fazer as chamadas. Pra esse eu criei um conector com a library requests, mas que depois poderemos implementar outros processadores, como por exemplo utilizar uma biblioteca mais performática, ou que suporte async ,por exemplo.
  • utils -> assim como o nome sugere, seria um eventual lugar para colocarmos algumas validações ou preparações que podem ser reutilizadas dentro do módulo.

Sobre o client.py

A classe do BrasilAPI está declarada aí dentro do client.py. Por meio dele que voce poderá adicionar métodos e fazer o meio de campo entre as chamadas de api do processor; Logo voce pode customizar o processador que vai fazer a chamada ao instanciar o objeto.

Outra coisa que eu imaginei foi que poderemos garantir a evolução de uma eventual v2 ou v3 da API mantendo as chamadas separadas. No caso do CEP, eu coloquei a V2 dentro, mas seria uma ideia para desacoplarmos, ou até mesmo decomissionar o ClientV1 inteiro com o passar do tempo.

Bom... acho que é mais ou menos isso. O que achas da Ideia? =)

[lipe14-ops]

Ótimas implementações @joepreludian!!!

a sua implementação ficou muito sólida sem muito espaço para a dinâmicidade do código ( diferente do meu rsrs ), mas ainda sim manteve o isolamento das diferentes partes do código que é um coisa que pela qual eu muito prezava.

acho que suas pontuações foram muito pertinentes batento em pontos que realmente eram deficientes. Principalmente no ponto 1 que foi comentado por você anteriormente que foi a causa da mal implementação do resto. Afinal o código foi feito sem planejamento. Gostei muito do enum e da visão de expansão não só o brasilapy mas também da API em si.

parabéns 😄 !!!

estárei revisando seu PR e em breve retornarei um feedback.

[joepreludian]

Opa meu amigo. Perfeito. Só peço que você não de merge ainda pq eu estou escrevendo uma pipeline pra teste e implementação. Se você quiser, depois, eu posso configurar no seu repo. Mas via de regra vou testar no meu repo local.

Pretendo adicionar o codecov hoje. Ontem deixei pronto o linting e Black via pre-commit. :) Só assim garantimos que o povo tenha o código saudável.

[lipe14-ops]

eita!!! Acabei de ver sua mensagem... Qualquer coisa envie um novo PR

[joepreludian]

Ahh. Sem problemas. Vou concluir hoje e já mando pra ti. Na verdade nesse pr aprovado ele roda o linting e testes, mas sem reporte nem envio dos dados. Pretendo rodar esse Flow sempre que fizerem um commit. Daí farei um específico em caso de merge na Master, que seria justamente o responsável pelo deployment.

Eu vou montar uma PR com instruções, principalmente no que tange o envio do pacote pro pypi e teste do sonar por vulnerabilidades. Vamos deixar a pipeline bem lindinha pra colocarmos todas as badges lá. :)

Tá ficando muito massa. Com isso mais e mais pessoas vão utilizar essa library. :)

Abraço, meu caro e bom sábado!