jerimumhs / transparencia-api Goto Github PK

Seguir a documentação do flask para implementar os testes e fixtures

Achei a lib Flask-Testing que parece ser interessante também.

Tem a branch feature/finances que já tem alguns models criados e uma estrutura de teste iniciada

Os projetos python geralmente usam um arquivo requirements para colocar todas as suas dependências. Quando possui alguma dependência de desenvolvimento ou ferramentas para depuração, cria-se outro arquivo chamado requirements-dev.txt. Não é necessário colocar o gunicorn como dependência, é opção de cada pessoa escolher em qual servidor rodar a aplicação.

No portal de transparência deverá ter:

• #20 (gastos e arrecadações)
• consulta do saldo
• expectativa do mês
• histórico de todos os meses

Foi criado o model Ticket com os seguintes campos:

• name | String(50)
• value | Float
• date | Date
• _type | INT (choices [1, 2])

É preciso criar o CRUD desse model com os verbos HTTP de API (POST, GET, PUT e DELETE).

• Create (POST)
• Update (PUT)
• Patch (PUT) ?
• List (GET)
• Retrieve (GET)
• Delete (DELETE)
• Testes de cada verbo

Materiais:

• Ver passo 6 em diante desse tutorial
• https://realpython.com/flask-connexion-rest-api-part-2/#people-data
• https://www.codementor.io/dongido/how-to-build-restful-apis-with-python-and-flask-fh5x7zjrx
• http://akashsenta.com/blog/flask-rest-api-with-sqlalchemy-and-marshmallow/

Precisa ser criado um readme bonitinho para o projeto. (pode ser utilizado o readme do guilherme como referência).

O readme precisa ter:

• Descrição do projeto
  • Objetivo
  • Conteúdo
• Contributing
  • Padrões
  • Regras
  • Configurando ambiente de desenvolvimento
• Autores
• Licença

O docker-compose pode ser melhorado de algumas formas, a primeira delas é colocando a identação de 4 para 2 espaços (padrão indicado para arquivos .yml).
Outra indicação é remover o pgadmin. As alterações devem ser feitas diretas pelo código, para poder ficar o registro no log.
Tambem remover o diretorio chamado docker/ e incluir tudo no proprio compose. Centralizar as configurações.

Modificar o Makefile para rodar localmente (não dentro do docker). Deixar o docker para fazer o ambiente de desenvolvimento com maior compatibilidade com o ambiente de produção, ou para pessoas que não queiram configurar o ambiente para rodar o sistema.

É possivel rodar os comandos do Makefile dentro do container, já que o arquivo tambem se encontrará lá dentro. Dando liberdade para rodar os comandos onde quiser.

Desacoplar a responsabilidade das configurações do código de dentro do proprio código. Uma boa sugestão é o dynaconf.

https://dynaconf.readthedocs.io/en/latest/

https://github.com/rochacbruno/dynaconf/blob/master/docs/guides/flask.md

Estava procurando algumas documentações sobre Base Class e na doc tem essa referência:
https://docs.sqlalchemy.org/en/13/orm/extensions/declarative/mixins.html#augmenting-the-base

Esse era o intuito do Base Model?

E vamos utilizar integer como ID mesmo? Não um UUID 4?