Arquitetura do Frontend

Descrição

O frontend foi desenvolvido utilizando Next.js com React, buscando uma arquitetura componentizada, que facilite manutenção, testes e escalabilidade.
A aplicação segue um padrão de rotas baseado em pastas, aproveitando a estrutura do Next para criação automática de rotas a partir do diretório app/.

Tecnologias

• Next.js → Framework React para rotas e renderização.
• React → Biblioteca de UI, base do frontend.
• Axios → Consumo de APIs.
• Tailwind CSS → Estilização utilitária com paleta customizada.
• ESLint → Padronização de código.
• Docker → Conteinerização do ambiente.
• GitLab → Versionamento, Wiki e CI/CD.

Estrutura de Arquivos do Frontend

src/
├── app/
├── page.tsx
├── globals.css
├── layout.tsx
├── screen1/
│   ├── page.tsx
│   ├── loading.tsx
│   ├── error.tsx
│   └── components/
│       ├── component1/
│       │   ├── index.tsx
│       │   ├── skeleton.tsx
│       │   └── error.tsx
│       └── component2/
│           ├── index.tsx
│           ├── skeleton.tsx
│           └── error.tsx
├── screen2/
│   ├── page.tsx
│   ├── loading.tsx
│   └── error.tsx
└── components/
    └── lib/

Explicativo dos Diretórios

• app/ → raiz da aplicação, organiza as rotas e páginas.
• page.tsx → ponto de entrada de cada rota.
• loading.tsx → tela/estado de carregamento da rota.
• error.tsx → fallback para tratamento de erros da rota.
• components/ → componentes exclusivos da tela, cada um em sua pasta com index, skeleton e error.
• components (nível raiz) → componentes compartilhados entre várias telas.
• lib/ → utilitários gerais (funções auxiliares, hooks globais etc.).

Justificativa da Arquitetura

A arquitetura foi escolhida para:

• Facilitar debug e manutenção, isolando erros e loaders por tela e por componente.
• Seguir o padrão de componentização do React, reaproveitando blocos de UI.
• Permitir futura expansão para testes unitários e testes de integração mais claros, já que erros e estados de loading estão isolados.
• Melhorar a organização visual do projeto, facilitando a navegação pelo código.

Arquitetura do Backend

Descrição

O backend foi desenvolvido utilizando NestJS, um framework Node.js para a construção de aplicações server-side eficientes e escaláveis. A arquitetura adotada é a de Monolito Modular, onde a aplicação é dividida em módulos que representam os domínios de negócio da aplicação (ex: producers, areas, harvests).

Esta abordagem promove uma forte Separação de Responsabilidades (Separation of Concerns), com cada módulo possuindo camadas bem definidas (Controller, Service, Repository), facilitando a manutenção, testabilidade e o desenvolvimento paralelo de novas funcionalidades.

Tecnologias

• NestJS → Framework backend para a estrutura da aplicação, injeção de dependência e modularidade.
• TypeScript → Superset do JavaScript que adiciona tipagem estática, aumentando a robustez do código.
• Prisma → ORM (Object-Relational Mapper) de próxima geração para a comunicação com o banco de dados.
• PostgreSQL → Banco de dados relacional, com a extensão PostGIS para manipulação de dados geoespaciais.
• Docker → Conteinerização do ambiente de desenvolvimento e produção.
• Swagger → Geração automática de documentação da API a partir do código.
• Passport.js → Middleware para estratégias de autenticação (JWT).
• ESLint / Prettier → Padronização e formatação de código.
• GitLab → Versionamento, Wiki e CI/CD.

Estrutura de Arquivos do Backend

aiprodutor-backend/
├── prisma/
│   ├── migrations/
│   └── schema.prisma
├── src/
│   ├── main.ts
│   ├── app.module.ts
│   ├── auth/
│   │   ├── dto/
│   │   ├── guards/
│   │   ├── strategies/
│   │   ├── auth.controller.ts
│   │   ├── auth.controller.spec.ts
│   │   ├── auth.service.ts
│   │   ├── auth.service.spec.ts
│   │   └── auth.module.ts
│   └── ... (demais módulos de dominio como `producers`, `areas`, etc.)
├── shared/
│   ├── prisma/
│   └── config/
└── test/
    ├── auth.e2e-spec.ts
    └── jest-e2e.json

Diagrama de Sistema

Padrões de Projeto e Explicação das Camadas

A arquitetura se baseia em um conjunto de padrões de projeto para garantir um código limpo, desacoplado e manutenível.

Padrões Fundamentais

• Arquitetura Modular: O sistema é dividido em módulos de domínio independentes (ProducersModule, AreasModule). Cada módulo encapsula um conjunto coeso de funcionalidades.
• Injeção de Dependência (DI): Utilizada nativamente pelo NestJS, permite que as dependências de uma classe (como um Service precisando de um Repository) sejam "injetadas" externamente, em vez de serem criadas internamente. Isso desacopla o código e facilita enormemente os testes.
• Repository Pattern: A camada de Service (lógica de negócio) não se comunica diretamente com o ORM (Prisma). Em vez disso, ela depende de uma abstração (o Repository), que centraliza e encapsula todas as consultas ao banco de dados. Isso isola a lógica de negócio dos detalhes de implementação da persistência.
• DTO (Data Transfer Object): Classes que definem a estrutura de dados que trafegam nas fronteiras da aplicação (ex: corpo de uma requisição HTTP). São usadas com os ValidationPipes do NestJS para garantir a integridade dos dados que entram no sistema.

Explicativo das Camadas

• *.controller.ts (Camada de API) → Responsável por receber requisições HTTP, validar os dados de entrada através de DTOs e direcionar a chamada para a camada de serviço. Não contém regras de negócio.
• *.service.ts (Camada de Serviço) → Contém a lógica de negócio principal. Orquestra as regras, cálculos e decisões. É o "cérebro" de cada módulo e depende dos Repositories para manipular dados.
• *.repository.ts (Camada de Acesso a Dados) → Abstrai a comunicação com o banco de dados. Centraliza as queries (especialmente as mais complexas) e garante que o restante da aplicação não precise "saber" que o Prisma está sendo usado.
• *.spec.ts (Camada de Testes) → Arquivos de testes unitários que vivem ao lado do código que testam, garantindo a qualidade e o comportamento esperado de cada unidade (Service, Controller, etc.).

Justificativa da Arquitetura

A arquitetura do backend foi projetada com os seguintes objetivos:

• Manutenibilidade e Escalabilidade → A divisão em módulos por domínio permite que a equipe encontre, corrija e adicione funcionalidades de forma isolada e segura, sem impactar o resto do sistema.
• Separação de Responsabilidades (SoC) → Cada camada tem um propósito claro. Controllers não acessam o banco, e Services não lidam com HTTP. Isso torna o código mais limpo, previsível e fácil de raciocinar.
• Testabilidade → A Injeção de Dependência e o Repository Pattern facilitam a criação de testes unitários, permitindo "mockar" (simular) o acesso ao banco para testar a lógica de negócio de forma isolada.
• Robustez → O uso de DTOs com validação automática na camada de Controller garante a integridade dos dados na entrada da API, prevenindo a propagação de dados inválidos para as camadas internas.

Arquitetura AWS

Visão Geral

Esta arquitetura descreve a infraestrutura da aplicação AI Produtor, construída inteiramente sobre a AWS (Amazon Web Services).
Ela é composta por uma camada de frontend (site hospedado no Amplify), uma camada de backend (API sem servidor com AWS Lambda) e um pipeline CI/CD automatizado via GitLab Runner e Docker.

O objetivo é garantir escalabilidade, segurança, baixo custo operacional e entrega contínua.

Fluxo de Requisições

1. Cliente

Usuários acessam a aplicação via:

• https://ai-produtor.com/ → Frontend (interface web)
• https://api.ai-produtor.com/ → Backend (API REST)

2. Amazon Route 53

O Amazon Route 53 atua como o serviço DNS, responsável por rotear o tráfego:

• Frontend → AWS Amplify
• Backend (API) → Amazon API Gateway

Funções principais:

• Gerencia domínios e subdomínios.
• Redireciona requisições de forma segura e escalável.
• Suporta SSL/TLS e monitoramento de integridade.

3. AWS Amplify

O AWS Amplify hospeda o frontend da aplicação (ex: React, Vue, Angular).
Fornece:

• Deploy automático integrado ao GitLab.
• CDN global para alta performance.
• HTTPS e SSL automáticos.
• Rollback de versões e CI/CD simplificado.

4. Amazon API Gateway

O Amazon API Gateway é a porta de entrada para o backend, hospedando os endpoints da API.

Funções:

• Controle de acesso (IAM, JWT, Cognito, etc.).
• Limitação de requisições (throttling).
• Conversão e roteamento de payloads.
• Integração direta com AWS Lambda.

5. AWS Lambda

O AWS Lambda executa o código backend sob demanda, sem necessidade de gerenciar servidores.

Responsabilidades:

• Processamento de requisições recebidas pelo API Gateway.
• Consultas a dados no Amazon RDS.
• Acesso a segredos armazenados no AWS Secrets Manager.
• Execução escalável e pagamento por uso.

6. AWS Secrets Manager

Serviço responsável por armazenar com segurança:

• Credenciais do banco de dados.
• Tokens e chaves sensíveis.
• Senhas e variáveis de ambiente.

Benefícios:

• Evita exposição de segredos no código.
• Rotaciona automaticamente credenciais.
• Integração nativa com Lambda e RDS.

7. Amazon RDS

O Amazon Relational Database Service (RDS) hospeda o banco de dados relacional da aplicação.
Pode ser PostgreSQL, MySQL ou outro motor compatível.

Características:

• Backup automatizado.
• Alta disponibilidade e escalabilidade.
• Segurança via VPC e grupos de segurança.

8. CI/CD – Amazon EC2 + Docker + GitLab Runner

Pipeline de deploy automatizado, responsável pela entrega contínua do backend.

• O GitLab Runner roda em uma instância Amazon EC2.
• Usa Docker para construir e empacotar as imagens da aplicação.
• Envia as imagens para o AWS Elastic Container Service (ECS).
• Automatiza build, testes e deploy a cada commit no repositório.

9. AWS Elastic Container Service (ECS)

O ECS orquestra os containers do backend.

Funções:

• Gerenciamento de containers via Docker.
• Escalonamento automático.
• Integração com Load Balancer e CloudWatch.
• Deploy automatizado via GitLab Runner.

Segurança e Boas Práticas

• Todo o tráfego é HTTPS via Route 53 + Amplify.
• Segredos são armazenados apenas no Secrets Manager.
• Lambda utiliza políticas IAM com menor privilégio possível.
• Containers no ECS rodam em sub-redes privadas.
• Logs e métricas são enviados para CloudWatch.

Fluxo Completo

Conclusão

Esta arquitetura combina simplicidade operacional, alta disponibilidade e segurança corporativa, aproveitando o ecossistema AWS para suportar o crescimento contínuo do projeto AI Produtor.