search

joaoprocopio / monolith

MIT License
4 stars 0 forks source link

Bootstrap do projeto #2

Open joaoprocopio opened 1 year ago

joaoprocopio commented 1 year ago

V0.0.1

V0.0.2

V0.0.3

V0.0.4

huogerac commented 1 year ago

Precisamos discutir o padrão pasta para poder iniciar

joaoprocopio commented 1 year ago

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 commented 1 year ago

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

joaoprocopio commented 1 year ago

@Riverfount @huogerac

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

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

huogerac commented 1 year ago

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

Riverfount commented 1 year ago

Darei uma olhada, e palpito ok?

joaoprocopio commented 1 year ago

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

Riverfount commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 11 months ago

@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!

ArquiteturaAPI

huogerac commented 11 months ago

@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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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

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...