¶ Arquitetura da Plataforma BAITES
¶ 1. Componentes e Fluxo da Arquitetura
¶ Frontend: React
Descrição: O frontend é desenvolvido em React, um framework JavaScript para a criação de interfaces de usuário altamente interativas e responsivas.
Fluxo: Os usuários interagem com o sistema por meio do React, que envia solicitações ao Nginx Reverse Proxy.
¶ Reverse Proxy: Nginx
Descrição: Atua como intermediário, distribuindo requisições do cliente para os serviços backend adequados.
Fluxo: Recebe requisições GET/POST do frontend e redireciona para o Web Service apropriado.
¶ Backend: Web Service
Descrição: Implementado como um conjunto de APIs RESTful (possivelmente com Django ou Flask), processa as requisições do cliente.
Fluxo: Responde às solicitações do frontend via Nginx e publica mensagens em sistemas de mensageria ou armazena dados conforme necessário.
¶ Mensageria e Streaming: RabbitMQ e Kafka
RabbitMQ: Gerencia filas de mensagens para serviços críticos e tarefas de baixa latência, como envio de notificações ou processamento simples.
Kafka: Utilizado para processamento de dados em tempo real e sincronização com serviços externos, como MinIO e AWS.
Fluxo: O Web Service interage com ambos para processar e distribuir mensagens e eventos.
¶ Armazenamento e Persistência: PostgreSQL e MinIO
PostgreSQL: Banco de dados relacional para armazenamento estruturado, usado para dados críticos ou transacionais.
MinIO: Solução de armazenamento compatível com S3, usada para arquivos, backups ou grandes volumes de dados não estruturados.
Fluxo: Dados do Kafka ou Web Service são persistidos em PostgreSQL ou MinIO conforme o caso.
¶ Camada de Processamento: Middleware
Descrição: Processa as mensagens do RabbitMQ e Kafka, integra dados entre sistemas e interage com os casos de uso definidos.
Fluxo: Consome mensagens, aplica lógica de negócios e direciona para os casos de uso (Use Case 1, 2 e 3).
¶ Casos de Uso (Use Cases)
Descrição: Representam funcionalidades específicas da aplicação, cada uma ligada a um objetivo de negócio.
Exemplos:
◦ Use Case 1: Processamento de relatórios.
◦ Use Case 2: Integração com serviços externos.
◦ Use Case 3: Processamento de grandes volumes de dados analíticos.
¶ Camada de Segurança
Descrição: Implementa controle de acesso, autenticação e proteção contra vulnerabilidades.
Fluxo: Atua como camada final de validação antes de liberar qualquer dado ou funcionalidade sensível.
¶ 2. Importância dos Componentes
Modularidade: Cada componente tem responsabilidades bem definidas, permitindo evolução e manutenção independentes.
Escalabilidade: Componentes como Kafka e RabbitMQ permitem alta disponibilidade e capacidade de lidar com grandes volumes de dados.
Interoperabilidade: Integração entre sistemas heterogêneos (MinIO, PostgreSQL, AWS) é facilitada pela mensageria.
Resiliência: RabbitMQ e Kafka garantem processamento assíncrono, reduzindo riscos de falhas em cascata.
Desempenho: O Nginx otimiza o roteamento de requisições e melhora o desempenho do sistema.
¶ Controle de Acesso da Aplicação
Este documento descreve o modelo de dados utilizado para gerenciamento de permissões e acesso a módulos (Bioativos). Ele organiza usuários, grupos, permissões e relaciona tudo isso ao controle de endpoints (recurso e ação). Abaixo, explicamos cada tabela e sua função no sistema.
¶ Tabela: BioaAtivos
¶ O coração do modelo
- Descrição: Representa os módulos ou funcionalidades principais do sistema que os usuários podem acessar.
- Campos:
context: Nome do módulo ou funcionalidade.description: Descrição detalhada do módulo.queue: Identifica a fila de processamento associada ao módulo.task_type: Define o tipo de tarefa relacionada ao módulo.
- Função: É o núcleo do permissionamento, com o qual outros componentes como grupos e permissões estão diretamente relacionados.
¶ Tabela: Role
- Descrição: Define as permissões para acessar um endpoint específico.
- Campos:
descricao: Uma breve descrição da permissão.recurso: O endpoint ou recurso da aplicação ao qual a permissão se aplica.acao: Define o método HTTP permitido (ex.:GET,POST,PUT,DELETE).
- Função: Controla quais ações podem ser realizadas em quais recursos.
¶ Tabela: CustomUser
- Descrição: Extensão do modelo de usuário padrão do Django, adicionando campos personalizados.
- Campos:
- Informações adicionais do usuário, como
job,company,country, entre outros. - Relacionamentos:
area_interesse: Indica as áreas de interesse do usuário.uso_dos_dados: Define os usos autorizados dos dados do usuário.
- Informações adicionais do usuário, como
- Função: Representa os usuários do sistema e armazena informações relacionadas.
¶ Tabela: RoleCustomUser
- Descrição: Relaciona usuários a permissões específicas.
- Relacionamentos:
user: Referência a um usuário.role: Referência a uma permissão.
- Função: Determina quais permissões específicas estão atribuídas a cada usuário.
¶ Tabela: BioAtivosCustomUser
- Descrição: Relaciona usuários a módulos (Bioativos).
- Relacionamentos:
user: Referência a um usuário.bioativos: Referência a um módulo.
- Função: Especifica quais módulos o usuário pode acessar.
¶ Tabela: GrupoBioAtivos
- Descrição: Agrupa módulos (Bioativos) para facilitar o gerenciamento.
- Campos:
nome: Nome do grupo.sigla: Sigla identificadora do grupo.
- Relacionamentos:
bioativos: Relacionamento com os módulos pertencentes ao grupo.
- Função: Organiza módulos em grupos lógicos.
¶ Tabela: GrupoCustomUser
- Descrição: Relaciona usuários a grupos de Bioativos.
- Relacionamentos:
user: Referência a um usuário.grupo: Referência a um grupo de módulos.
- Função: Define os grupos aos quais um usuário pertence, facilitando o gerenciamento de permissões por grupos.
¶ Tabela: GrupoRole
- Descrição: Relaciona grupos de Bioativos a permissões específicas.
- Relacionamentos:
grupo: Referência a um grupo de módulos.role: Referência a uma permissão.
- Função: Controla quais ações (métodos HTTP) podem ser realizadas em recursos pertencentes ao grupo.
¶ Fluxo de Permissionamento
- Role:
- Cria permissões para acessar endpoints (recurso) com métodos específicos (ação).
- BioaAtivos:
- Define os módulos acessíveis no sistema.
- Relacionamentos:
- Usuário ↔ Módulo (BioaAtivos): Determina quais módulos um usuário pode acessar.
- Usuário ↔ Permissão (Role): Define permissões individuais do usuário.
- Grupo ↔ Módulo (BioaAtivos): Agrupa módulos logicamente.
- Grupo ↔ Permissão (Role): Controla permissões aplicadas a grupos.
¶ Benefícios do Modelo
- Centralização: BioaAtivos é o núcleo do modelo, permitindo fácil rastreabilidade e controle de acesso.
- Flexibilidade: A combinação de permissões por usuário e por grupo garante alta granularidade de controle.
- Escalabilidade: Adicionar novos módulos ou permissões requer apenas a atualização das tabelas associadas.
- Segurança: O modelo garante que ações específicas só possam ser executadas por usuários ou grupos autorizados.
¶ Exemplo de Cenário
- Um administrador define um Bioativo chamado "Detecção de Coqueiros".
- Ele cria uma Role com
recurso="/relatorios"eacao="GET". - Um usuário é vinculado ao módulo através de BioAtivosCustomUser.
- O mesmo usuário recebe a permissão para acessar o recurso através de RoleCustomUser.
Com este modelo, o acesso aos módulos e recursos é totalmente controlado e rastreável.