Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • T taskee_wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Taskee
  • taskee_wiki
  • Wiki
  • Arquitetura

Last edited by Marina Geller Yamaguti Sep 14, 2025
Page history

Arquitetura

Arquitetura do Sistema

Descrição

Esta seção apresenta a arquitetura definida para o Taskee, contemplando tanto o Frontend quanto o Backend.
Nosso objetivo é garantir uma separação clara de responsabilidades, escalabilidade e facilidade de manutenção.

A aplicação segue um modelo Client-Server, onde o Frontend Web (React + TypeScript) se comunica com a API Backend (Python) utilisando o Firebase.


Sumário

  • Arquitetura do Sistema
    • Frontend Web
      • Definições de Tecnologias
      • Módulos
    • Frontend Mobile
      • Definições de Tecnologias
    • Backend
      • Definições de Tecnologias
      • Camadas e Fluxo
    • Integração Frontend + Backend

Frontend Web

Definições de Tecnologias

  • Linguagem: TypeScript
  • Biblioteca: React
  • Bundler: Vite ⚡
  • Estilização: TailwindCSS e Design System próprio
  • Gerenciamento de estado/queries: TanStack Query (React Query)
  • Autenticação: Firebase Auth

O Frontend é uma SPA (Single Page Application), construída em React.
A comunicação com a API é feita via TanStack Query, que gerencia o ciclo de vida das requisições, cache de dados e estados de carregamento/erro.

Diagrama em Alto Nível do Frontend

aarquitetura_front

Módulos

├── public/               # Arquivos estáticos
├── src/
│   ├── app/              # Entrypoint, router e providers
│   ├── assets/           # Imagens, ícones e mídias
│   ├── components/       # Componentes reutilizáveis de UI
│   ├── design-system/    # Tipografia, cores e tokens
│   ├── dto/              # Data Transfer Objects (DTOs)
│   ├── infra/            # Configurações e integrações
│   ├── pages/            # Páginas principais da aplicação
│   ├── services/         # Serviços e chamadas de API
│   ├── utils/            # Funções auxiliares
├── index.html            # Arquivo HTML de entrada (Vite)
├── package.json          # Dependências do projeto
├── tsconfig.json         # Configuração do TypeScript
└── README.md
└── ...                   # Outros arquivos de configuração (husky, eslint, prettier, etc.)
  • App → Ponto de entrada da aplicação, onde o Router controla as rotas.
  • Pages → Telas principais, ex.: Home, Sobre do Evento, Tarefas.
  • Components → Botões, Cards, Headers, Sidebar, etc.
  • Context → Compartilhamento de estados globais como lista de eventos.
  • Services → Comunicação com a API via hooks do TanStack Query.
  • Design System → Padronização visual (cores, espaçamentos, fontes).

Frontend Mobile


Backend

Definições de Tecnologias

  • Linguagem: Python
  • Framework: FastAPI
  • Banco de Dados: Firebase Firestore (NoSQL)
  • Armazenamento de Arquivos: Firebase Storage (imagens e mídias)
  • Autenticação: Firebase Auth
  • Containerização: Docker + Docker Compose
  • Testes: Pytest
  • Documentação de API: Swagger (disponível em /docs)

O backend foi desenvolvido em arquitetura em camadas, garantindo separação de responsabilidades, testabilidade e escalabilidade.


Camadas e Fluxo

A API segue um modelo de camadas bem definidas:

app/
├── main.py          # Ponto de entrada da aplicação
├── controllers/     # Rotas e controladores da API (camada de interface)
├── dependencies/    # Injeção de dependências e middlewares
├── models/          # Modelos de dados e integração com Firebase (Firestore/Storage/Auth)
├── schemas/         # Schemas (Pydantic) para validação e serialização
├── services/        # Regras de negócio e lógica da aplicação
└── tests/           # Testes unitários e de integração

Fluxo de uma requisição

  1. Cliente (Frontend Web/Mobile) envia uma requisição HTTP para a API.

  2. A requisição chega ao Controller, que define a rota e delega a execução.

  3. O Service aplica as regras de negócio (ex.: criar evento, associar usuário, registrar tarefa concluída).

  4. Os Models interagem com o Firebase:

    • Firestore → persistência e consulta de dados (eventos, usuários, tarefas, resultados).
    • Storage → upload/download de arquivos (imagens de eventos, avatares, certificados).
    • Auth → autenticação e autorização de usuários.
  5. O Schema (Pydantic) garante que entrada e saída de dados estão no formato correto.

  6. A resposta validada retorna ao Controller, que a envia ao Cliente.


Integração Frontend + Backend

  • O Frontend consome a API através de hooks (useQuery, useMutation) do TanStack Query, garantindo que os dados sempre estejam sincronizados.
  • O Backend valida, processa e retorna os dados para o Frontend.
  • O banco de dados armazena eventos, tarefas, usuários e resultados.

Arquitetura em Alto Nível da Aplicação

alto-nivel

De forma simplificada:

  1. Usuário acessa o sistema pelo navegador.
  2. O Router no Frontend direciona para a página correta (Home, Evento, Tarefas).
  3. Cada módulo da aplicação consome dados da API Backend.
  4. O Banco de Dados persiste todas as informações.

Essa arquitetura garante:

  • Escalabilidade → fácil adicionar novos módulos (ex.: Atividades).
  • Reuso → componentes e serviços reutilizáveis.
  • Padronização → design system + DTOs.
Clone repository
  • Arquitetura
  • Banco de Dados
  • Home