Gerenciador de Tarefas

Aplicação web para cadastro, autenticação e gerenciamento de tarefas.

Tecnologias

• Frontend: React com Vite (React Router)
• Backend: Python com FastAPI
• Banco/Auth: Supabase (Postgres + autenticação e-mail/senha)
• Testes: PyTest

Instalação e execução

Pré-requisitos

• Node.js (para o frontend)
• Python 3.12+
• uv (gerenciador de dependências do backend)
• Projeto Supabase configurado com tabela tasks e autenticação por e-mail/senha

Backend

1. Entre na pasta do servidor:

cd server

2. Crie o arquivo .env a partir do exemplo e preencha as variáveis:

cp .env.example .env

SUPABASE_URL=
SUPABASE_KEY=

3. Instale as dependências:

uv sync

4. Execute a API:

uv run uvicorn app.main:app --reload

A API ficará disponível em http://localhost:8000.

Frontend

1. Entre na pasta do cliente:

cd client

2. Crie o arquivo .env a partir do exemplo:

cp .env.example .env

VITE_API_URL=http://localhost:8000

3. Instale as dependências:

npm install

4. Execute o frontend:

npm run dev

Prints da interface

Página inicial

🏠 Dashboard Principal

Login

Tela de login

Cadastro de Usuário

Tela de Cadastro

Tarefas

Tarefas Cadastradas pelo Usuário

Cadastro de Tarefas

Tela Cadastro de Tarefas

Estrutura do código

Trabalho01/
├── client/                          # Frontend (React + Vite)
│   ├── app/
│   │   ├── components/
│   │   │   ├── auth/                # Componentes de autenticação
│   │   │   ├── home/                # Componentes da página inicial
│   │   │   ├── layout/              # Cabeçalho e rodapé
│   │   │   ├── tasks/               # Formulário, card e exclusão de tarefas
│   │   │   └── ui/                  # Componentes de interface (shadcn)
│   │   ├── lib/
│   │   │   ├── auth/                # Contexto, serviço e sessão de autenticação
│   │   │   ├── schemas/             # Validação com Zod
│   │   │   ├── tasks/               # Serviço e formatação de tarefas
│   │   │   └── api.ts               # Cliente HTTP da API
│   │   └── routes/                  # Páginas: home, login, register, tasks
│   ├── package.json
│   └── vite.config.ts
│
└── server/                          # Backend (FastAPI)
    ├── app/
    │   ├── core/                    # Configuração e tratamento de erros
    │   ├── database/                # Cliente Supabase
    │   ├── dependencies/            # Dependência de autenticação (JWT)
    │   ├── routers/
    │   │   ├── auth.py              # Endpoints /auth/signup e /auth/login
    │   │   └── tasks.py             # CRUD de tarefas (/tasks)
    │   ├── schemas/                 # Modelos Pydantic (auth e task)
    │   └── main.py                  # Aplicação FastAPI
    ├── tests/
    │   ├── conftest.py              # Fixtures e mocks do Supabase
    │   ├── test_auth.py             # Testes de autenticação
    │   └── test_tasks.py            # Testes de tarefas
    └── pyproject.toml

Arquitetura

O sistema é composto por três partes independentes: o frontend (React), a API (FastAPI) e o Supabase (autenticação e banco Postgres). O usuário interage só com a interface; o frontend chama a API; a API fala com o Supabase.

flowchart LR
  U[Usuário] --> FE[Frontend<br/>React + Vite]
  FE -->|HTTP JSON<br/>Bearer JWT| API[Backend<br/>FastAPI]
  API -->|signup / login / get_user| AUTH[Supabase Auth]
  API -->|CRUD tabela tasks| DB[(Supabase<br/>Postgres)]

Loading

Componentes

Partes independentes (processos/serviços distintos):

• Frontend (client/): interface web. Não acessa o banco nem o Auth do Supabase diretamente.
• Backend (server/): API REST (/auth e /tasks). Valida o JWT e encaminha as operações ao Supabase.
• Supabase Auth: cadastro e login por e-mail/senha; emissão e validação do token.
• Supabase Postgres: persistência da tabela tasks.

Cada um pode ser implantado, reiniciado ou substituído sem o código dos outros, desde que o contrato HTTP e as variáveis de ambiente (VITE_API_URL, SUPABASE_URL, SUPABASE_KEY) se mantenham.

Compartilhamento

O que é compartilhado entre os componentes:

• Contrato da API: rotas, JSON e códigos HTTP usados pelo frontend e pelo backend.
• Sessão: o JWT emitido no login/cadastro; o frontend guarda e reenvia; o backend valida no Supabase.
• Dados: usuários no Auth e tarefas no Postgres, acessíveis a qualquer cliente autenticado daquele usuário.
• Não é compartilhado: memória, processos ou arquivos locais entre frontend, API e Supabase.

Tipo da SD

Sistema de informação (com recursos distribuídos).

O objetivo é compartilhar e persistir dados (contas e tarefas), não paralelizar cálculo e não operar como sistema pervasivo (sensores, IoT, contexto físico). Há processamento na API, mas ele serve à informação, não a um cluster de computação.

Transparência

O usuário não precisa saber:

• Localização: se a API está em localhost:8000 ou em outro host; se o Auth e o Postgres estão no Supabase.
• Acesso: que o frontend usa HTTP/JSON e a API usa o SDK do Supabase (Auth + PostgREST).
• Autenticação interna: como o token é validado (get_user) ou como a chave do projeto é usada no servidor.
• Esquema do banco: nomes de tabela/colunas e o fato de o CRUD ir ao Postgres.

Ele vê telas, formulários e mensagens de erro da interface.

Escalabilidade

Como o sistema pode crescer, dado o desenho atual:

• Mais usuários/clientes: vários navegadores acessam a mesma API; o frontend é estático e escala à parte.
• Mais carga na API: novas instâncias do FastAPI, apontando para o mesmo Supabase.
• Mais dados: o crescimento de contas e de tasks fica no Postgres/Auth do Supabase.

Não há, neste projeto, balanceador, fila ou replicação implementados na aplicação.

Falha

O que acontece se um componente falhar:

• Frontend indisponível: a interface não abre; API e Supabase continuam de pé, mas o usuário não os usa por essa UI.
• FastAPI indisponível: o frontend não completa as chamadas e mostra que não foi possível conectar ao servidor. Auth e banco não são acessados por este caminho.
• Supabase Auth indisponível: cadastro, login e validação de token falham; as rotas de tarefas autenticadas deixam de funcionar.
• Postgres indisponível: login/cadastro podem ainda falar com o Auth, mas criar/listar/atualizar/excluir tarefas falha.

Não há failover automático na aplicação: a falha aparece como erro HTTP ou de rede na interface.

Testes

Instalar dependências de teste

As dependências de teste (PyTest) estão no pyproject.toml do backend. Na pasta server:

uv sync

Executar os testes

Na pasta server:

uv run pytest -v

Quantidade de testes implementados

10 testes no total:

Arquivo	Quantidade
test_auth.py	6
test_tasks.py	4

Resultado da execução dos testes

============================= test session starts =============================
platform win32 -- Python 3.12.13, pytest-9.1.1, pluggy-1.6.0
collected 10 items

tests/test_auth.py::test_cadastro_valido PASSED                          [ 10%]
tests/test_auth.py::test_cadastro_com_email_ja_usado PASSED              [ 20%]
tests/test_auth.py::test_login_valido_devolve_token_e_usuario PASSED     [ 30%]
tests/test_auth.py::test_login_com_senha_errada PASSED                   [ 40%]
tests/test_auth.py::test_autorizacao_sem_token_e_recusada PASSED         [ 50%]
tests/test_auth.py::test_autorizacao_com_token_invalido PASSED           [ 60%]
tests/test_tasks.py::test_criar_tarefa PASSED                            [ 70%]
tests/test_tasks.py::test_listar_tarefas PASSED                          [ 80%]
tests/test_tasks.py::test_atualizar_tarefa PASSED                          [ 90%]
tests/test_tasks.py::test_excluir_tarefa PASSED                          [100%]

======================== 10 passed, 1 warning in 0.15s ========================

O que cada grupo de testes valida

test_auth.py — Autenticação (6 testes)

• Cadastro válido: retorno 201 com token e dados do usuário.
• Cadastro com e-mail já usado: retorno 409 com mensagem de conflito.
• Login válido: retorno 200 com token e dados do usuário.
• Login com senha errada: retorno 401 com mensagem de credenciais inválidas.
• Autorização sem token: acesso a /tasks/ recusado (401 ou 403).
• Autorização com token inválido: retorno 401 ao enviar token inválido.

test_tasks.py — Tarefas (4 testes)

• Criar tarefa: retorno 201 com dados da tarefa e user_id correto.
• Listar tarefas: retorno 200 com a lista de tarefas do usuário.
• Atualizar tarefa: retorno 200 com status atualizado.
• Excluir tarefa: retorno 200 com mensagem de sucesso e filtro pelo ID correto.