Bootstrap do projeto

[joaoprocopio]

V0.0.1

• Gerenciador dependencias Poetry
• Bootstrap fastapi zerado
• Padrões de pastas* (Precisamos discutir o padrão pasta para poder iniciar)
• Status
• Da pau
• Subir Postgres com docker compose
• Linter & Formatador de código (Flake8 + black)
• Configuração de código (python-decouple)
• Listar tarefas
  • ORM e Gestor de migrações (SQLAlchemy & Alembic)
  • pytest envolve criar banco de teste

V0.0.2

• Login
• proteger rota listar
• Login e manter estado (Pesquisar** - ver alternativas)
  • https://fastapi.tiangolo.com/tutorial/security/simple-oauth2/
  • tem algo como flask-login?

V0.0.3

• converter para cookiecutter

V0.0.4

• permitir escolher sqlmodel
• permitir escolher dynaconf

[huogerac]

Precisamos discutir o padrão pasta para poder iniciar

[joaoprocopio]

O River enviou um link muito interessante na #1 issue.

Application factory

É muito parecido com o manage.py, seria pra gente fazer um desse pra rodar a aplicação

[huogerac]

https://github.com/mjhea0/awesome-fastapi

[joaoprocopio]

@Riverfount @huogerac

fiz o bootstrap fastapi zerado e queria pedir a ajuda de vocês para os próximos passos que seriam:

• padrões de pastas
• views iniciais

tava com o tempo meio apertado pq tinha acabado de começar a faculdade, mais agora to com a rotina mais bem definida.

[huogerac]

Vou dar uma olhada até o final de semana. Legal joão

[Riverfount]

Darei uma olhada, e palpito ok?

[joaoprocopio]

@Riverfount beleza! por enquanto só as dependências estão instaladas acho que por agora é só puxar mais tarefas

[Riverfount]

@joaoprocopio e @huogerac esse repo tem o mesmo propósito que o que temos aqui: https://github.com/vndmtrx/poetry-fastapi-container vale a pena acompanhar!

[Riverfount]

@joaoprocopio e @huogerac vi esse documento que parece interessante para estudarmos em vistas a uma estrutura de projetos: https://devdocs.io/fastapi/tutorial/bigger-applications/index#an-example-file-structure

[joaoprocopio]

A Netflix tem um repo de um serviço chamado Dispatch, é um monolito em FastAPI, e eu achei o código de altíssima qualidade, é uma estrutura que me brilhou os olhos. Deem uma olhada logo depois!

https://github.com/netflix/dispatch

FYI @Riverfount @huogerac

[Riverfount]

@joaoprocopio e @huogerac acabei por desenhar um modelo, que adotaremos no desenvolvimento aqui na empresa, dêem uma olhada e palpitem. NO caso, esse projeto é uma API que terá mais de um recurso, no bom e velho estilo de monolito mesmo!

[huogerac]

@Riverfount

1)

a pasta api/player é um agrupador de contexto?
ou seja, se eu precisar agrupar os endopints de relatórios ou pagamentos, vamos precisar de:
api/player
api/report
api/payment

E dentro de cada uma (que funciona como uma app do django) temos a estrutura model, serializer, endpoint e task?
É isto? Como seu exemplo apenas tem o contexto de player, fiquei na dúvida!

2)

├── pyproject.toml            👍
├── docker-compose.yaml        👍  
├── Dockerfile             👍  
├── tests             👍     imagino que dentro desta pasta, teremos player/endpoint/teste1 e player/task/inserir_jogador
├── api                           🤔   it seems there more than api inside this 
│   ├── auth.py           👍  talvez auth é um service (task) dentro do contexto (app) accounts
│   ├── log.py              👍 
│   ├── database.py    👍  talvez isto é uma configuração e poderia estar agrupado com o config.py (mas okay aqui)
│   ├── config.py         👍
│   ├── player             👍
│   │      ├── model          👍    good
│   │      ├── serializer       👍   gooooood
│   │      ├── endpoint       👍 endpoint ou api fica legal aqui, só o api da raiz que talvez pode ter outro nome
│   │      ├── task         🤔  esta pasta é referente a 'service layer'**?, eu prefiro service pq task pode ser necessário qdo colocar celery

'service layer'**

Uma coisa que organiza bem, deixa mais fácil criar testes e desacopla regras de negócio do código do framework (por isto não gosto de regras dentro das views e dos models no django).

Se a ideia desta pasta for isto, perfeito! Geralmente esta camada não tem dependencia para o request, context e outras coisas do framework web, são mais puras possívels (a.k.a. DDD), É claro, podemos decidir depender dos models que é a lib de ORM. Na prática não acontece, mas se trocarmos o framework web, esta camada será pouca afetada!
Isto também vai contribuir para não ter lógica de negócio dentro da pasta endpoint.

@Riverfount acredito que um bom exercício é tentar colocar mais coisas ai! celery, mas classes de serviço, mas "apps"

@joaoprocopio e você, como acabaram organizando as coisas ai com fastapi?

Valeu galera

[Riverfount]

Oi @huogerac a ideia do player é ser um resource, seria, como vc disse, algo similar às apps do Django sim! E sim, se precisar de outros vamos criando como vc deu de exemplo para report e payment.

A pasta de tests é para separar o código dos testes do código que vai para produção. Não precisaria ser tão específico em colocar cada camada testada em pastas separas, mas player, report e payment sim seriam pacotes python dentro do pacote tests e dentro desses pacotes módulos para testar cada parte do Resource.

Eu estou pensando numa API, mais monolítica do que microsserviços, até porque se fossem microsserviçoes teríamos uma estrutura dessas para cada Resource, totalmente separada e desacoplada, fazendo uma comunicação entre si, mas eu particularmente acho isso mais complexo de gerenciar do que ter um pouco de acoplamento e tals. Mas, é só minha modesta opinião.

[Riverfount]

Depois desse desenho, pq eu to implementando um projeto de API usando esse modelo, eu criei um novo pacote python, o middleware e usando o padrão de App Factory (copiadásso do Flask) para inicializá-los. Tá ficando show ... não posso compartilhar links do código, mas se quiserem, eu posso numa call mostrar como tá ficando ehhehe

[huogerac]

Seria legal se você pudesse criar um cookiecutter desta organização com as funcionalidades que o dejavue tem:

• login (app accounts)
• listar tarefas (app core)
• criar tarefas (app core)

Simples, mas da para ter uma ideia...note que no Djangão eu não implementei o criar usuário (está no plano), mas dá para quebrar galho com o admin ou com o manage.py! Já no minimalista, vai ter que ter uma apizinha de inserir user eu acho...