joaoprocopio commented 12 months ago

Seja bem-vindo!

Toda contribuição dentro dessa issue, e nesse projeto, no geral, é extremamente bem-vinda!

Qual a idéia dessa issue?

A idéia é criarmos nesse repositório um template de projeto full-stack utilizando cookiecutter.

E gostaria de deixar a seguinte questão em aberto:

Quais tipos de ferramentas devemos ter dentro de um projeto completo?

Exemplo:

Gestor de dependências;
Gerenciador de fila de tarefas;
Documentação de API com OpenAPI;
Ferramenta de gerenciamento de migração de banco de dados. Como Alembic;
ORM

Etc.

E logo após de definir o que seria interessante ter, podemos escolher as ferramentas a serem utilizadas.

huogerac commented 12 months ago

Gerenciador de dependências?

(👍) pip-tools (😃) Poetry (❤️) Pipenv

Utilize a reações abaixo para indicar sua preferência

huogerac commented 12 months ago

Linter e formatador de código?

(👍) flake8 + black (😃) ruff + black (❤️) ruff + blue (🎉) Outro

huogerac commented 12 months ago

Separar configurações do código?

(❤️) python-decouple (😃) dynaconf (👍) outro

huogerac commented 12 months ago

Qual ORM e gestor de migrações?

(👍) sqlalchemy e alembic (😃) sqlmodel e alembic (❤️) outros

huogerac commented 12 months ago

Qual forma de criar documentação das APIs?

(👍) Swagger padrão do fastapi (😃) design-first com openapi (❤️) outras

huogerac commented 12 months ago

Qual forma para manter o estado de usuários logados?

(👍) cookie de sessão (😃) JWT (❤️) alguma lib que já faz isto?

huogerac commented 12 months ago

Qual estrutura de pasta utilizar para separar em camadas?

Uma coisa que pode ser muito importante ter no template é uma estrutura e organização de pasta que seja escalável e fácil do time entender onde colocar novas funcionalidades...

Talvez seja interessante conseguir separar:

rotas / views
serviços
models
também ser possível ter o conceito de contexto, ou seja, igual o django tem as apps, como separamos as rotas, views serviços do contexto de contas (login, novo user) do contexto tasks (nova tarefa, listar tarefas)?

Qualquer sugestão ou ideia é mais que bem-vinda! deixe seu comentário e contribua para criação deste template!

huogerac commented 12 months ago

Uma sugestão é algo assim

├── api
│   ├── accounts.py
│   └── tasks.py
├── services
│   ├── accounts.py
│   └── tasks.py
├── models
│   ├── accounts.py
│   └── tasks.py
├── settings (algo como o ext do flask ou settings do django)
│   ├── db
│   ├── api
│   ├── migrations
│   └── config
..?

joaoprocopio commented 12 months ago

Estrutura de pastas

Deixando meus 5 centavos quanto à organização de pastas, acredito que seguir algo como o Domain Drive Design, traz ganhos altíssimos. Justamente quando paramos para pensar em...

O que é uma boa arquitetura?

Imagino que podemos dizer que um software tem uma boa arquitetura quando:

É barato e indolor fazer alterações ou adicionar peças aí software;

E ao termos uma construção de software robusta com uma arquitetura extremamente bem definida, o software tende a ser mais confiável e sem bugs.

Domain Drive Design

Acredito que podemos utilizar esse Pattern por conseguirmos separar nossa aplicação por domínios.

Dessa forma podemos isolar a aplicação em domínios (ou módulos, chame como quiser).

E por natureza esses domínios encapsulam toda sua lógica, como por exemplo:

Um domínio de autenticação e autorização, teria:

Entidades: usuário, sessões (caso autenticação seja baseada em sessão)

Services: encontrar usuário, criar usuário, etc.

Controller: controlar a lógica de cadastro de um novo usuário com base nos dados enviados pelo front, etc.

É um assunto do qual não sou nenhum expert, somente um entusiasta, apenas acredito que pode ser um caminho provável para desenhar uma boa arquitetura.

joaoprocopio commented 12 months ago

Como gerenciar filas de tarefas?

(👍) Celery (😃) RQ (❤️) outras

Edit 1: ty @walison17, background tasks != task queue.

walison17 commented 12 months ago

Como gerenciar filas de tarefas?

(+1) Celery (smiley) Starlette (built-in) (heart) outras

o rq seria uma alternativa ao celery, o background jobs do starlette não trabalha com filas.

Riverfount commented 12 months ago

Gerenciador de dependências?

(+1) pip-tools (smiley) Poetry (heart) Pipenv

Utilize a reações abaixo para indicar sua preferência

O Python Poetry tem a vantagem de usar o pyproject.toml, que é o novo padrão de configuração de pacotes do Python, conforme a PEP518, por esse motivo eu penso que seria o ideal!

Riverfount commented 12 months ago

Separar configurações do código?

(heart) python-decouple (smiley) dynaconf (+1) outro

O Dynaconf, na minha opinião, é atualmente a melhor opção, pois ele traz muito mais do que a simples separação do código com as configurações de ambiente. E, muito provavelmente, em breve teremos uma funcionalidade para o fastAPI, já que o Bruno Rocha, autor e mantenedor dessa lib, tem adotado fortemente o fastAPI. Assim como já tem funcionalidades para Django e Flask! Mas, é minha opinião mesmo!

Riverfount commented 12 months ago

Como gerenciar filas de tarefas?

(+1) Celery (smiley) Starlette (built-in) (heart) outras

O Kafka tem se mostrado promissor nesse quesito de gerência de filas de tarefas. Sem falar que ele é muito mais que isso!

Riverfount commented 12 months ago

Quanto à Estrutura de Pastas

Gosto de pensar no fastAPI como um framework para API`s, sei que o propósito aqui é tb ter o front no projeto, mas eu não sou tão adepto assim dessa questão! O front pode ser qq um, do Vue ao Postman ou mesmo um cUrl. Claro que, no projeto de desenvolvimento, podemos ter ambos juntos, mas eu tendo a pensar em separar isso. Não necessariamente em dois repos, podemos até pensar em monorepo, mas mantendo as responsabilidades bem desacopladas. Eu ainda não tenho uma proposta 100% fechada sobre essa estrutura, mas apontaria e direcionaria a discussão nesse sentido! Primeira coisa seria o desacoplamento entre Back e Front, e tomar cuidado para não criarmos um Django a partir do fastAPI hehehehehe como já vi muitos projetos em Flask, a ponto da galera chamar esse projetos de Flango ahahahah

Poderíamos considerar o padrão Application Factory para isso, como o Flask o implementa!

huogerac commented 12 months ago

Links que a galera da Dev Pro indicou:

Riverfount commented 12 months ago

Mais um link que pode ser útil:

https://github.com/rochacbruno/fastapi-project-template

Riverfount commented 12 months ago

Qual ORM e gestor de migrações?

(👍) sqlalchemy e alembic (😃) sqlmodel e alembic (❤️) outros

Penso que SQLModel é a melhor opção por duas razões:

É do mesmo autor e mantenedor do fastAPI,
É uma abstração em cima do SQLAlchemy usando Pydantic!

Riverfount commented 12 months ago

Qual forma de criar documentação das APIs?

(👍) Swagger padrão do fastapi (😃) design-first com openapi (❤️) outras

Usar o padrão do fastAPI e evitar retrabalho!

joaoprocopio commented 12 months ago

Como gerenciar filas de tarefas?

(+1) Celery (smiley) Starlette (built-in) (heart) outras

O Kafka tem se mostrado promissor nesse quesito de gerência de filas de tarefas. Sem falar que ele é muito mais que isso!

@Riverfount nunca trabalhei com Kafka, mas até onde sei ele é focado em event streaming. E não em gerenciamento de fila de tarefas.

Fazendo algumas pesquisas pela internet consegui encontrar os seguintes comentários sobre utilizar o Kafka como task queue:

Using Kafka for a task queue is a bad idea. Use RabbitMQ instead, it does it much better and more elegantly. Fonte

Kafka is not a message queue, but an event stream processing software. You can build queue on top of it, but you need to implement a lot of logic yourself, you can't just replace RabbitMQ with Kafka. Fonte

Posso estar errado, mas imagino que vamos reinventar a roda com essa decisão, estou com a mente aberta pra conhecer, também!

Riverfount commented 12 months ago

Como gerenciar filas de tarefas?

(+1) Celery (smiley) Starlette (built-in) (heart) outras

O Kafka tem se mostrado promissor nesse quesito de gerência de filas de tarefas. Sem falar que ele é muito mais que isso!

@Riverfount nunca trabalhei com Kafka, mas até onde sei ele é focado em event streaming. E não em gerenciamento de fila de tarefas.

Fazendo algumas pesquisas pela internet consegui encontrar os seguintes comentários sobre utilizar o Kafka como task queue:

Using Kafka for a task queue is a bad idea. Use RabbitMQ instead, it does it much better and more elegantly. Fonte

Kafka is not a message queue, but an event stream processing software. You can build queue on top of it, but you need to implement a lot of logic yourself, you can't just replace RabbitMQ with Kafka. Fonte

Posso estar errado, mas imagino que vamos reinventar a roda com essa decisão, estou com a mente aberta pra conhecer, também!

Estranho usamos o Kafka na empresa para gerenciamento de filas de tarefas e nunca tivemos qualquer problema!

Penso que as pessoas confundem o fato dele ser mais que só um gerenciador de filas, mas ter muito mais funcionalidades. Enfim, é questão de preferência, não vejo problemas em trabalhar com RQ RabitMQL ou mesmo Celery com Redis!

huogerac commented 12 months ago

Estava pesquisando uns projetos existentes para tentar ver como a galera organiza projetos fastapi...

Opção 1

source

fastapi_structure_1
├── ext
│   ├── base_class.py
│   ├── base.py
│   ├── config.py
│   ├── database.py
│   ├── optimize_image.py
│   └── spaces.py
├── domains
│   ├── domain_mail.py
│   ├── domain_order.py
│   ├── domain_payment.py
│   ├── domain_shipping.py
│   ├── domain_user.py
│   └── tests
├── endpoints
│   ├── deps.py
│   └── v1
│       ├── default.py
│       ├── direct_sales.py
│       ├── mail.py
│       ├── order.py
│       ├── payment.py
│       ├── product.py
│       ├── shipping.py
│       ├── tests
│       └── users.py
├── gateway
│   ├── payment_gateway.py
│   └── tests
├── job_service
│   ├── service.py
│   ├── service_status.py
│   └── tests
├── payment
│   ├── adapter.py
│   ├── gateway.py
│   ├── repositories.py
│   ├── schema.py
│   ├── service.py
│   └── tests
├── migrations
│   ├── env.py
│   ├── script.py.mako
│   └── versions
├── models
│   ├── commissions.py
│   ├── franchise.py
│   ├── order.py
│   ├── role.py
│   ├── tests
│   ├── transaction.py
│   ├── uploadedimage.py
│   └── users.py
├── schemas
│   ├── mail_schema.py
│   ├── order_schema.py
│   ├── payment_schema.py
│   ├── shipping_schema.py
│   └── user_schema.py
├── poetry.toml
├── pyproject.toml
├── pytest.ini
├── requirements.txt
├── main.py
├── settings.toml
├── alembic.ini
├── config.py
├── conftest.py
├── constants.py
└── Dockerfile

Opção 2

source

fastapi_structure_2
├── docs
├── dundie
│   ├── app.py
│   ├── auth.py
│   ├── cli.py
│   ├── config.py
│   ├── db.py
│   ├── default.toml
│   ├── models
│   │   ├── __init__.py
│   │   ├── transaction.py
│   │   └── user.py
│   ├── routes
│   │   ├── auth.py
│   │   ├── transaction.py
│   │   └── user.py
│   ├── security.py
│   ├── tasks
│   │   ├── transaction.py
│   │   └── user.py
│   └── VERSION.txt
├── docker-compose.yaml
├── Dockerfile.dev
├── Makefile
├── MANIFEST.in
├── postgres
│   ├── create-databases.sh
│   └── Dockerfile
├── pyproject.toml
├── requirements-dev.txt
├── requirements.in
├── requirements.txt
├── settings.toml
├── setup.py
├── start.sh
├── tests
└── test.sh

Opção 3

source

tiangolo-structure-3
├── app
│   ├── app
│   │   ├── api
│   │   │   ├── api_v1
│   │   │   │   ├── api.py
│   │   │   │   ├── endpoints
│   │   │   │   │   ├── __init__.py
│   │   │   │   │   ├── items.py
│   │   │   │   │   ├── login.py
│   │   │   │   │   ├── users.py
│   │   │   │   │   └── utils.py
│   │   │   │   └── __init__.py
│   │   │   └── deps.py
│   │   ├── backend_pre_start.py
│   │   ├── celeryworker_pre_start.py
│   │   ├── core
│   │   │   ├── celery_app.py
│   │   │   ├── config.py
│   │   │   └── security.py
│   │   ├── crud
│   │   │   ├── base.py
│   │   │   ├── crud_item.py
│   │   │   ├── crud_user.py
│   │   ├── db
│   │   │   ├── base_class.py
│   │   │   ├── base.py
│   │   │   ├── init_db.py
│   │   │   └── session.py
│   │   ├── email-templates
│   │   │   ├── build
│   │   │   └── src
│   │   ├── initial_data.py
│   │   ├── main.py
│   │   ├── models
│   │   │   ├── item.py
│   │   │   └── user.py
│   │   ├── schemas
│   │   │   ├── item.py
│   │   │   ├── msg.py
│   │   │   ├── token.py
│   │   │   └── user.py
│   │   ├── tests
│   │   │   ├── api
│   │   │   ├── conftest.py
│   │   │   ├── crud
│   │   │   ├── __init__.py
│   │   │   └── utils
│   │   ├── tests_pre_start.py
│   │   ├── utils.py
│   │   └── worker.py
│   ├── alembic.ini
│   ├── alembic
│   │   ├── env.py
│   │   ├── script.py.mako
│   │   └── versions
│   ├── mypy.ini
│   ├── prestart.sh
│   ├── pyproject.toml
│   ├── scripts
│   │   ├── format-imports.sh
│   │   ├── format.sh
│   │   ├── lint.sh
│   │   ├── test-cov-html.sh
│   │   └── test.sh
│   ├── tests-start.sh
│   └── worker-start.sh
├── backend.dockerfile
└── celeryworker.dockerfile

joaoprocopio commented 12 months ago

Peguei esse Serviço da Netflix que usa FastAPI, e adaptei um pouco a estrutura de pastas junto desse outro guia, e me digam o que vocês acham.

@Riverfount @huogerac

Eu acho essa organização dessa forma interessante por que a gente mantém o que é global na raiz do projeto, e separa os domínios em diretórios diferentes, tendo uma organização padrão, dá pra manter um monolito de forma mais organizada.

fastapi-monolith-template
├── src
│   └── monolith
│       ├── project
│       │   ├── middlewares.py
│       │   ├── database.py
│       │   └── config.py
│       ├── modules
│       │   ├── posts
│       │   │   ├── views.py
│       │   │   ├── tests
│       │   │   ├── services.py
│       │   │   ├── schemas.py
│       │   │   ├── models.py
│       │   │   ├── exceptions.py
│       │   │   ├── dependencies.py
│       │   │   └── constants.py
│       │   └── auth
│       │       ├── views.py
│       │       ├── tests
│       │       ├── services.py
│       │       ├── schemas.py
│       │       ├── models.py
│       │       ├── exceptions.py
│       │       ├── dependencies.py
│       │       └── constants.py
│       ├── main.py
│       ├── __init__.py
│       └── alembic.ini
├── README.md
├── pyproject.toml
├── poetry.lock
├── LICENSE
├── ESTRUTURA.md
├── dockerfile
└── compose.yaml

jonatasoli commented 11 months ago

Chegou a ver a estrutura do cosmic python? Eu to migrando pra ela no meu projeto de ecommerce, tem alguns desafios principalmente de conceitos. Mas, segue o DDD.

jonatasoli commented 11 months ago

já que vai usar uma ferramenta de fila, pensa em usar uma arquitetura baseada em eventos? assim poderia ter um command que injeta todos os adapters no service.

joaoprocopio commented 11 months ago

Chegou a ver a estrutura do cosmic python? Eu to migrando pra ela no meu projeto de ecommerce, tem alguns desafios principalmente de conceitos. Mas, segue o DDD.

Seria algo parecido com isso? @jonatasoli

.
├── Dockerfile  (1)
├── Makefile  (2)
├── README.md
├── docker-compose.yml  (1)
├── license.txt
├── mypy.ini
├── requirements.txt
├── src  (3)
│   ├── allocation
│   │   ├── __init__.py
│   │   ├── adapters
│   │   │   ├── __init__.py
│   │   │   ├── orm.py
│   │   │   └── repository.py
│   │   ├── config.py
│   │   ├── domain
│   │   │   ├── __init__.py
│   │   │   └── model.py
│   │   ├── entrypoints
│   │   │   ├── __init__.py
│   │   │   └── flask_app.py
│   │   └── service_layer
│   │       ├── __init__.py
│   │       └── services.py
│   └── setup.py  (3)
└── tests  (4)
    ├── conftest.py  (4)
    ├── e2e
    │   └── test_api.py
    ├── integration
    │   ├── test_orm.py
    │   └── test_repository.py
    ├── pytest.ini  (4)
    └── unit
        ├── test_allocate.py
        ├── test_batches.py
        └── test_services.py

joaoprocopio commented 11 months ago

já que vai usar uma ferramenta de fila, pensa em usar uma arquitetura baseada em eventos? assim poderia ter um command que injeta todos os adapters no service.

Opa, se possível, você pode elaborar mais um pouco dessa ideia?

Riverfount commented 11 months ago

@joaoprocopio e @huogerac eu penso que deixar a estrutura de pastas já pré definida seria um boilerplate que, assim como o Django, pode inchar o projeto. O que acham de termos algo bem mais simples, e conforme o projeto vai demandando vai se desacoplando as coisas e deixando cada uma em seu devido lugar! Sei lá, achei um tanto exagerada algumas estruturas de pastas que foram colocadas aqui!

huogerac commented 11 months ago

@Riverfount acredito que a ideia é esta, fizemos uma call nesta última quinta e pensamos em começar simples. Mas ao mesmo tempo, voltar nesta thread quando chegar a hora... Falamos da opção 2, e do repo que vimos no seu repositŕio ser mais simples! Inclusive nem ter fila .... mas ao mesmo tempo tentar descobri como os projetos escalam em termos de estrutura... Acredito que o @joaoprocopio está tentando entender DDD, mas não irá começar com esta estrutura não! não é joão!

@joaoprocopio acredito que podemos ir neste sentido, não acha?

uma estrutura minimamente organizada para acomodar o contexto inicial para "listar tarefas"

Riverfount commented 11 months ago

@huogerac poxa, se eu soubesse da call teria tentado participar!

Penso que uma coisa importante é pensarmos em REST. Em REST o principal componente é o Resource, este deve ser desacoplado ao máximo de outros. Assim, se o sistema em questão tiver digamos dois componentes, como USER e TODO, numa TodoList, estes deveriam estar o mais desacoplados possível, mas eu mesmo ainda não sei ao certo como fazer.

No trabalho que venho fazendo com o pessoal às quartas-feiras, ao qual convido vc e o @joaoprocopio caso possam participar, estamos fazendo sem muito pensar na arquitetura final, deixando o sistema ganhar forma para depois, num processo de refaotração, elaborarmos melhor. Mas, algo que está me norteando é a questão de deixar ambos os Resources desacoplados ... a ponto de poderem ser utilizados independentemente um do outro, em outros projetos.

huogerac commented 11 months ago

Legal! foi de última que iniciamos a conversa, não tinha dúvida na monitoria e iniciamos este assunto!

@joaoprocopio, te passo o link e vamos entrar ver as aulas do River de FastApi na próxima quarta!

Valeu River! Sua ajuda está sendo bem legal!

jonatasoli commented 11 months ago

Chegou a ver a estrutura do cosmic python? Eu to migrando pra ela no meu projeto de ecommerce, tem alguns desafios principalmente de conceitos. Mas, segue o DDD.

Seria algo parecido com isso? @jonatasoli

.
├── Dockerfile  (1)
├── Makefile  (2)
├── README.md
├── docker-compose.yml  (1)
├── license.txt
├── mypy.ini
├── requirements.txt
├── src  (3)
│   ├── allocation
│   │   ├── __init__.py
│   │   ├── adapters
│   │   │   ├── __init__.py
│   │   │   ├── orm.py
│   │   │   └── repository.py
│   │   ├── config.py
│   │   ├── domain
│   │   │   ├── __init__.py
│   │   │   └── model.py
│   │   ├── entrypoints
│   │   │   ├── __init__.py
│   │   │   └── flask_app.py
│   │   └── service_layer
│   │       ├── __init__.py
│   │       └── services.py
│   └── setup.py  (3)
└── tests  (4)
    ├── conftest.py  (4)
    ├── e2e
    │   └── test_api.py
    ├── integration
    │   ├── test_orm.py
    │   └── test_repository.py
    ├── pytest.ini  (4)
    └── unit
        ├── test_allocate.py
        ├── test_batches.py
        └── test_services.py

Sim eu uso um pouco diferente só pegando na aba do curso do Branas de clean code e etc.

├── Dockerfile (1) ├── Makefile (2) ├── README.md ├── docker-compose.yml (1) ├── license.txt ├── mypy.ini ├── requirements.txt ├── src (3) | |------- infra | | |------init.py | | |------ endpoints | | | | ------ endpoint.py | | | ├── models_db.py │ ├── allocation │ │ ├── init.py │ │ └── repository.py │ │ ├── config.py │ │ ├── entities │ │ │ ├── init.py │ │ │ └── entity.py │ │ └── service_layer │ │ ├── init.py │ │ └── services.py │ └── setup.py (3) │ └── flask_app.py └── tests (4) ├── conftest.py (4) ├── e2e │ └── test_api.py ├── integration │ ├── test_orm.py │ └── test_repository.py ├── pytest.ini (4) └── unit ├── test_allocate.py ├── test_batches.py └── test_services.py

    To usando isso num projeto aqui de ecommerce, o unico ponto que ta sendo um desafio é os teste e2e que nao to conseguindo debugar no vim.

jonatasoli commented 11 months ago

já que vai usar uma ferramenta de fila, pensa em usar uma arquitetura baseada em eventos? assim poderia ter um command que injeta todos os adapters no service.

Opa, se possível, você pode elaborar mais um pouco dessa ideia?

Posso sim,

O ponto é ter um objeto de boostrap ou qualquer outro nome ele vai ter tudo que é enquadrado como adapter e vai ser injetado no endpoint eu particulamente to usando uma injeção de função ao inves de usar o depends mas, nos dois casos funcionaria um exemplo aqui do meu projeto, ta bem tosco ainda precisa dar uma refinada: https://github.com/jonatasoli/fast-ecommerce-back/blob/master/app/infra/bootstrap.py

o formato do cosmic python https://github.com/cosmicpython/code/blob/chapter_13_dependency_injection/src/allocation/bootstrap.py

o do cosmic python ta usando o padrão de message bus no meu caso eu fiz esse intermediário até eu conseguir migrar o projeto100% pra essa arquitetura e melhorar a cobertura, mas a ideia é deixar igual ao do cosmic python.

jonatasoli commented 11 months ago

@joaoprocopio e @huogerac eu penso que deixar a estrutura de pastas já pré definida seria um boilerplate que, assim como o Django, pode inchar o projeto. O que acham de termos algo bem mais simples, e conforme o projeto vai demandando vai se desacoplando as coisas e deixando cada uma em seu devido lugar! Sei lá, achei um tanto exagerada algumas estruturas de pastas que foram colocadas aqui!

nesse caminho talvez fosse interessante trabalhar com vários app e dentro do app ter a sua estrutura de router assim tu teria cada um auto contido. De começar simples acho que esse é o caminho talvez monstar um app de todo simples de exemplo e a partir dele montar as estruturas do cookiecutter eu fiz assim na primeira vez que montei um template. https://github.com/jonatasoli/fastapi-template-cookiecutter

jonatasoli commented 11 months ago

@huogerac poxa, se eu soubesse da call teria tentado participar!

Penso que uma coisa importante é pensarmos em REST. Em REST o principal componente é o Resource, este deve ser desacoplado ao máximo de outros. Assim, se o sistema em questão tiver digamos dois componentes, como USER e TODO, numa TodoList, estes deveriam estar o mais desacoplados possível, mas eu mesmo ainda não sei ao certo como fazer.

No trabalho que venho fazendo com o pessoal às quartas-feiras, ao qual convido vc e o @joaoprocopio caso possam participar, estamos fazendo sem muito pensar na arquitetura final, deixando o sistema ganhar forma para depois, num processo de refaotração, elaborarmos melhor. Mas, algo que está me norteando é a questão de deixar ambos os Resources desacoplados ... a ponto de poderem ser utilizados independentemente um do outro, em outros projetos.

cara to refatorando meu projeto assim: https://github.com/jonatasoli/fast-ecommerce-back/tree/master/app/infra

ta bem desacoplado mas, ainda preciso resolver algumas coisas ali como vou montar o decorator de autenticação/permissão para anotar no endpoint e se quando fizer isso não vou acoplar o sistema :p

Riverfount commented 11 months ago

@huogerac poxa, se eu soubesse da call teria tentado participar! Penso que uma coisa importante é pensarmos em REST. Em REST o principal componente é o Resource, este deve ser desacoplado ao máximo de outros. Assim, se o sistema em questão tiver digamos dois componentes, como USER e TODO, numa TodoList, estes deveriam estar o mais desacoplados possível, mas eu mesmo ainda não sei ao certo como fazer. No trabalho que venho fazendo com o pessoal às quartas-feiras, ao qual convido vc e o @joaoprocopio caso possam participar, estamos fazendo sem muito pensar na arquitetura final, deixando o sistema ganhar forma para depois, num processo de refaotração, elaborarmos melhor. Mas, algo que está me norteando é a questão de deixar ambos os Resources desacoplados ... a ponto de poderem ser utilizados independentemente um do outro, em outros projetos.

cara to refatorando meu projeto assim: https://github.com/jonatasoli/fast-ecommerce-back/tree/master/app/infra

ta bem desacoplado mas, ainda preciso resolver algumas coisas ali como vou montar o decorator de autenticação/permissão para anotar no endpoint e se quando fizer isso não vou acoplar o sistema :p

Uma sugestão é usar a questão de Autenticação/Permissão com injeção de dependências do fastAPI e não com decorators! ;-)

jonatasoli commented 11 months ago

@huogerac poxa, se eu soubesse da call teria tentado participar! Penso que uma coisa importante é pensarmos em REST. Em REST o principal componente é o Resource, este deve ser desacoplado ao máximo de outros. Assim, se o sistema em questão tiver digamos dois componentes, como USER e TODO, numa TodoList, estes deveriam estar o mais desacoplados possível, mas eu mesmo ainda não sei ao certo como fazer. No trabalho que venho fazendo com o pessoal às quartas-feiras, ao qual convido vc e o @joaoprocopio caso possam participar, estamos fazendo sem muito pensar na arquitetura final, deixando o sistema ganhar forma para depois, num processo de refaotração, elaborarmos melhor. Mas, algo que está me norteando é a questão de deixar ambos os Resources desacoplados ... a ponto de poderem ser utilizados independentemente um do outro, em outros projetos.

cara to refatorando meu projeto assim: https://github.com/jonatasoli/fast-ecommerce-back/tree/master/app/infra ta bem desacoplado mas, ainda preciso resolver algumas coisas ali como vou montar o decorator de autenticação/permissão para anotar no endpoint e se quando fizer isso não vou acoplar o sistema :p

Uma sugestão é usar a questão de Autenticação/Permissão com injeção de dependências do fastAPI e não com decorators! ;-)

Pensei nisso seria uma forma de não ferir, mas por outro lado não vou acabar fazendo DRY na camada de serviço? Na verdade pensando aqui poderia usar o decorator pegando o bootstrap que foi passado na função ai se conseguir colocar no endpoint acho que funciona e não deve atrapalhar nenhum teste, já que o do endpoint eu faço e2e.

huogerac commented 8 months ago

Olha Este projeto relacionado https://github.com/PythonNest/PyNest

joaoprocopio commented 8 months ago

queria voltar a olhar pra esse projeto.

Jajá eu entro de férias na faculdade e eu vou ter tempo livre de volta.

huogerac commented 2 months ago

Faaala pessoal,

Eu usei esta thread aqui e tentei aplicar uma organização em um projeto FastAPI. Se quiserem dar um olhada:

Repo: https://github.com/huogerac/fastapifromzero/
O que foi feito: https://github.com/huogerac/fastapifromzero/issues/1
Qualquer sugestão é bem-vinda!
Obs: Tem os mesmos endpoints do backend do Djàvue, assim se conectar o frontend do djavue neste fastapi vai funfar! @joaoprocopio @jonatasoli @Riverfount
River vai adorar como o Taskpy foi feito neste projeto! kkk

jonatasoli commented 2 months ago

Bacana @huogerac pensa em usar o cookiecutter?

huogerac commented 2 months ago

Hey! Sim, vou converter para um template sim!

joaoprocopio / monolith

Como seria uma stack ideal? #1

Seja bem-vindo!

Qual a idéia dessa issue?

Gerenciador de dependências?

Linter e formatador de código?

Separar configurações do código?

Qual ORM e gestor de migrações?

Qual forma de criar documentação das APIs?

Qual forma para manter o estado de usuários logados?

Qual estrutura de pasta utilizar para separar em camadas?

Estrutura de pastas

O que é uma boa arquitetura?

Domain Drive Design

Como gerenciar filas de tarefas?

Como gerenciar filas de tarefas?

Gerenciador de dependências?

Separar configurações do código?

Como gerenciar filas de tarefas?

Quanto à Estrutura de Pastas

Qual ORM e gestor de migrações?

Qual forma de criar documentação das APIs?

Como gerenciar filas de tarefas?

Como gerenciar filas de tarefas?

Opção 1

Opção 2

Opção 3