Aplicação web de gerenciamento de tarefas com autenticação, categorias, compartilhamento entre usuários, notificações por e-mail, testes automatizados e CI.
- Visão Geral
- Funcionalidades
- Stack
- Estrutura Do Projeto
- Pré-Requisitos
- Instalação Com Docker
- Instalação Local Sem Docker
- Arquivos De Ambiente
- Como Rodar Os Testes
- Arquitetura E Decisões De Design
- Rotas Da API
- CI E Automação
Este projeto foi construído como uma aplicação full stack para organizar tarefas pessoais e colaborativas. O objetivo não foi apenas criar um CRUD simples, mas entregar um fluxo completo com autenticação, categorias, compartilhamento com permissões, notificações por e-mail, testes e automação de CI.
- cadastro e login de usuários
- edição de perfil
- criação, edição, exclusão e conclusão de tarefas
- categorização de tarefas
- compartilhamento com permissão de leitura ou edição
- listagem de tarefas compartilhadas comigo
- filtros e paginação de tarefas na API
- organização visual em quadro Kanban
- notificações por e-mail via SMTP
- testes automatizados no backend e E2E no frontend
| Camada | Tecnologia |
|---|---|
| Frontend | React, TypeScript, Vite, Tailwind CSS |
| Backend | Django, Django REST Framework, JWT |
| Banco de dados | PostgreSQL |
| SMTP | |
| Testes backend | pytest, pytest-django |
| Testes E2E | Selenium |
| Infraestrutura local | Docker Compose |
| CI | GitHub Actions |
O repositório segue uma estrutura de monorepo, centralizando frontend, backend, testes E2E e automações no mesmo lugar.
to-do-list/
├── backend/ # API Django REST, regras de negócio e integração SMTP
├── frontend/ # Aplicação React
├── e2e/ # Testes end-to-end com Selenium
├── .github/ # Workflows do GitHub Actions
└── docker-compose.yml
Pastas principais:
- backend: autenticação, tarefas, categorias, compartilhamento, notificações e testes
- frontend: interface, componentes, hooks, services e tipos
- e2e: cenários automatizados pela interface web
- .github/workflows: CI e release
- Docker
- Docker Compose
- Python
3.12+ - Node.js
22+ pnpm- PostgreSQL
Esta é a forma mais simples de subir o projeto.
Use como base:
Exemplo mínimo:
DEBUG=True
SECRET_KEY=change-me-in-development
FRONTEND_URL=http://localhost:3000
DB_NAME=todo_db
DB_USER=todo_user
DB_PASSWORD=2004
DB_HOST=db
DB_PORT=5432
EMAIL_HOST=smtp.gmail.com
EMAIL_PORT=587
EMAIL_USE_TLS=True
EMAIL_HOST_USER=seu_email@gmail.com
EMAIL_HOST_PASSWORD=sua_senha_de_app
DEFAULT_FROM_EMAIL=seu_email@gmail.com
EMAIL_REPLY_TO=seu_email@gmail.comCrie o arquivo real:
cp backend/.env.example backend/.envNa raiz do projeto:
docker compose up --build| Serviço | URL |
|---|---|
| Frontend | http://localhost:3000 |
| Backend | http://localhost:8000 |
| PostgreSQL | localhost:5433 |
- o backend executa
migrateao iniciar - no Docker, o banco deve ser acessado pelo host
db - o frontend em container é servido via Nginx
Se você preferir rodar cada parte manualmente, siga a ordem abaixo.
Entre na pasta:
cd backendCrie e ative a virtualenv:
python3 -m venv .venv
source .venv/bin/activateInstale as dependências:
pip install -r requirements.txtCrie o arquivo de ambiente:
cp .env.example .envEdite o backend/.env com seus dados locais. Exemplo:
DEBUG=True
SECRET_KEY=sua-chave-local
FRONTEND_URL=http://localhost:3000
DB_NAME=todo_db
DB_USER=todo_user
DB_PASSWORD=2004
DB_HOST=localhost
DB_PORT=5432
EMAIL_HOST=smtp.gmail.com
EMAIL_PORT=587
EMAIL_USE_TLS=True
EMAIL_HOST_USER=seu_email@gmail.com
EMAIL_HOST_PASSWORD=sua_senha_de_app
DEFAULT_FROM_EMAIL=seu_email@gmail.com
EMAIL_REPLY_TO=seu_email@gmail.comAplique as migrations:
python manage.py migrateInicie a API:
python manage.py runserverEm outro terminal:
cd frontend
pnpm install
cp .env.example .env.localArquivo esperado:
VITE_API_URL=http://localhost:8000/apiInicie o frontend:
pnpm devSe quiser rodar os testes Selenium localmente:
pip install -r e2e/requirements.txt
cp e2e/.env.example e2e/.envArquivo esperado:
E2E_FRONTEND_URL=http://127.0.0.1:3000
E2E_API_URL=http://127.0.0.1:8000/api
E2E_WAIT_SECONDS=15Pré-requisitos adicionais:
- backend rodando
- frontend rodando
- Chrome ou Chromium instalado
- WebDriver compatível disponível no sistema
Cada parte do projeto possui seu próprio contexto de configuração.
Arquivo de exemplo:
Variáveis principais:
| Variável | Finalidade |
|---|---|
SECRET_KEY |
chave interna do Django |
DEBUG |
modo de desenvolvimento |
FRONTEND_URL |
base usada em links e e-mails |
DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, DB_PORT |
conexão com o PostgreSQL |
EMAIL_HOST, EMAIL_PORT, EMAIL_USE_TLS |
configuração SMTP |
EMAIL_HOST_USER, EMAIL_HOST_PASSWORD |
autenticação SMTP |
DEFAULT_FROM_EMAIL, EMAIL_REPLY_TO |
remetente e resposta dos e-mails |
Arquivo de exemplo:
Variável principal:
| Variável | Finalidade |
|---|---|
VITE_API_URL |
URL base da API usada pelo React |
Arquivo de exemplo:
Variáveis principais:
| Variável | Finalidade |
|---|---|
E2E_FRONTEND_URL |
endereço aberto pelo navegador automatizado |
E2E_API_URL |
API auxiliar usada pelos testes |
E2E_WAIT_SECONDS |
timeout máximo de espera |
- arquivos reais de ambiente não devem ser versionados
- o frontend só deve usar variáveis com prefixo
VITE_ - segredos e credenciais ficam apenas no backend
- para Gmail, use senha de app em vez da senha normal da conta
Na pasta backend:
./.venv/bin/python -m pytestCom cobertura:
./.venv/bin/python -m pytest --cov=users --cov=tasks --cov=categories --cov-report=term-missing --cov-report=xmlNa pasta frontend:
pnpm exec tsc --noEmit
pnpm exec eslint src --ext .ts,.tsx
pnpm buildNa raiz do projeto:
python -m pytest e2e/selenium -vO backend foi separado em apps com responsabilidades claras:
users: cadastro, login, perfil e preferências de notificaçãotasks: regras de tarefas, compartilhamento, permissões e notificaçõescategories: organização das tarefas por categoria
O frontend foi dividido em camadas para reduzir acoplamento:
features: páginas e fluxos principaiscomponents: componentes visuais e reutilizáveishooks: estado compartilhado e regras de usoservices: consumo da APItypes: contratos tipados
DRF + JWT: autenticação stateless simples para SPATaskSharecom permissãoread/edit: compartilhamento sem duplicar tarefaSMTP no backend: protege credenciais e centraliza o enviosettings_test.py: separa ambiente de teste do ambiente localpytest + Selenium: cobre backend e fluxo real de interface
KISS: fluxo direto para autenticação, tarefas e categoriasDRY: reaproveitamento de serviços, helpers e serializersSOLID: separação entre camada visual, serviço e regra de negócio
Base local:
http://localhost:8000/api
| Método | Rota | Descrição |
|---|---|---|
POST |
/auth/signup/ |
cria conta |
POST |
/auth/signin/ |
autentica usuário |
POST |
/auth/refresh/ |
renova token |
GET |
/auth/profile/ |
retorna perfil autenticado |
PATCH |
/auth/profile/ |
atualiza parcialmente o perfil |
PUT |
/auth/profile/ |
atualiza completamente o perfil |
POST |
/auth/profile/test-notification/ |
envia e-mail de teste |
| Método | Rota | Descrição |
|---|---|---|
GET |
/categories/ |
lista categorias do usuário |
POST |
/categories/ |
cria categoria |
GET |
/categories/{id}/ |
detalha categoria |
PUT |
/categories/{id}/ |
atualiza categoria |
PATCH |
/categories/{id}/ |
atualiza parcialmente |
DELETE |
/categories/{id}/ |
remove categoria |
| Método | Rota | Descrição |
|---|---|---|
GET |
/tasks/ |
lista tarefas do usuário |
POST |
/tasks/ |
cria tarefa |
GET |
/tasks/{id}/ |
detalha tarefa |
PUT |
/tasks/{id}/ |
atualiza tarefa |
PATCH |
/tasks/{id}/ |
atualiza parcialmente |
DELETE |
/tasks/{id}/ |
remove tarefa |
PATCH |
/tasks/{id}/toggle/ |
alterna concluída / não concluída |
Filtros suportados em /tasks/:
searchcategoryis_doneordering
| Método | Rota | Descrição |
|---|---|---|
GET |
/tasks/{id}/shares/ |
lista compartilhamentos da tarefa |
POST |
/tasks/{id}/shares/ |
compartilha tarefa com outro usuário |
DELETE |
/tasks/{id}/shares/{share_id}/ |
remove compartilhamento |
GET |
/tasks/shared-with-me/ |
lista tarefas compartilhadas comigo |
PATCH |
/tasks/{id}/shared-edit/ |
edita tarefa compartilhada quando permitido |
Workflows disponíveis:
- ci.yml: pytest, cobertura e Selenium
- release.yml: release por tag e publicação de imagens no GHCR
Fluxo de CI:
- sobe PostgreSQL no GitHub Actions
- instala dependências
- aplica migrations
- roda
pytestcom cobertura - sobe backend e frontend no job E2E
- roda Selenium
Fluxo de release:
- criar uma tag como
v1.0.0 - enviar a tag para o GitHub
- a workflow cria a release
- as imagens Docker são publicadas no GitHub Packages (
ghcr.io)