eletrotupi / tcc/ commit / 3b69074

thesis: first revision of the tech chapter

Pedro Lucas Porcellis porcellis@eletrotupi.com 14 days ago 3b690741804a817a06060ff4b4673e3b852c0c75
Parents: 3aef368
1 file(s) changed
  • monografia/chapters/tech.tex +101 -6
monografia/chapters/tech.tex
1 1 
\chapter{Tecnologias}
2 2
3 - 
\lipsum[1-2]
3 + 
Este capítulo apresenta as principais tecnologias empregadas no desenvolvimento
4 + 
do aplicativo, organizadas de acordo com a camada da arquitetura em que
5 + 
atuam: front-end, back-end e infraestrutura/persistência de dados.
6 +
7 + 
\section{Front-end}
8 +
9 + 
\subsection{React Native}
10 +
11 + 
React Native é um \textit{framework} de código aberto, mantido pela Meta, que
12 + 
permite o desenvolvimento de aplicativos móveis multiplataforma a partir de
13 + 
uma única base de código escrita em JavaScript/TypeScript, utilizando
14 + 
componentes que são traduzidos para elementos nativos tanto no iOS quanto no
15 + 
Android \citep{reactnative:2026}.
16 +
17 + 
A escolha do React Native se justifica pelo escopo reduzido da equipe de
18 + 
desenvolvimento (um único desenvolvedor) e facilidade de conhecimento e
19 + 
manutenção, sem trazer, para este projeto, benefícios que justifiquem esse
20 + 
custo adicional. Além disso, o ecossistema maduro do React Native oferece
21 + 
ampla disponibilidade de bibliotecas para funcionalidades já previstas no
22 + 
aplicativo, como notificações locais e gráficos.
23 +
24 + 
\subsection{Zustand}
25 +
26 + 
Zustand é uma biblioteca leve de gerenciamento de estado para aplicações
27 + 
React e React Native, que dispensa a estrutura verbosa de \textit{providers}
28 + 
e \textit{reducers} tipicamente associada a bibliotecas como Redux
29 + 
\citep{zustand:2026}.
30 +
31 + 
Ela foi escolhida para gerenciar o estado efêmero da aplicação (por exemplo,
32 + 
dados de formulários em preenchimento ou estados de navegação temporários)
33 + 
por sua API minimalista e baixo \textit{overhead} de configuração, adequada a um
34 + 
projeto de escopo individual em que a complexidade adicional de soluções
35 + 
mais robustas de gerenciamento de estado não se justifica.
36 +
37 + 
\section{Back-end}
38 +
39 + 
\subsection{Express.js}
40 +
41 + 
Express.js é um \textit{framework} minimalista para aplicações web em
42 + 
Node.js, amplamente utilizado para a construção de APIs \textit{REST},
43 + 
oferecendo uma camada fina de abstração sobre o roteamento de requisições HTTP e
44 + 
\textit{middlewares} \citep{express:2026}.
45 +
46 + 
Sua adoção se deve à simplicidade e à flexibilidade não opinativa do
47 + 
\textit{framework}, que permite estruturar a API de acordo com as
48 + 
necessidades específicas do projeto, sem impor convenções rígidas de
49 + 
arquitetura, além de sua ampla documentação e maturidade no ecossistema
50 + 
Node.js.
51 +
52 + 
\subsection{Zod}
53 +
54 + 
Zod é uma biblioteca de validação e definição de esquemas de dados para
55 + 
TypeScript, que permite declarar formatos esperados de entrada (como corpos
56 + 
de requisição) e inferir automaticamente os tipos estáticos correspondentes
57 + 
\citep{zod:2026}.
58 +
59 + 
Zod foi escolhido para validar os dados recebidos pela API antes de seu
60 + 
processamento, garantindo que registros de humor, sono e demais entradas do
61 + 
usuário estejam em conformidade com o formato esperado. A inferência
62 + 
automática de tipos a partir dos esquemas evita a duplicação de definições de
63 + 
tipo entre a camada de validação e o restante do código TypeScript do
64 + 
back-end.
65 +
66 + 
\subsection{Valkey e BullMQ}
67 +
68 + 
Valkey é um banco de dados em memória, do tipo chave-valor, criado como
69 + 
\textit{fork} de código aberto do Redis, mantido sob a governança da Linux
70 + 
Foundation \citep{valkey:2026}. BullMQ é uma biblioteca para gerenciamento de
71 + 
filas de tarefas em Node.js, construída sobre bancos de dados compatíveis com
72 + 
o protocolo Redis \citep{bullmq:2026}.
73 +
74 + 
A combinação das duas ferramentas foi adotada para o processamento paralelo
75 + 
e assíncrono de tarefas que não precisam bloquear a resposta imediata da API,
76 + 
como o disparo de notificações programadas e o processamento de indicadores
77 + 
a partir do histórico de registros do usuário. A escolha do Valkey em
78 + 
específico, e não do Redis diretamente, se deve à mudança de licenciamento do
79 + 
Redis em 2024, que passou a restringir certos usos comerciais; o Valkey
80 + 
mantém compatibilidade total de protocolo, permanecendo sob licença
81 + 
permissiva de código aberto.
82 +
83 + 
\section{Infraestrutura e Persistência de Dados}
4 84
5 - 
\section{API}
85 + 
\subsection{PostgreSQL}
6 86
7 - 
\lipsum[1-2]
87 + 
PostgreSQL é um sistema gerenciador de banco de dados relacional, de código
88 + 
aberto, reconhecido por sua conformidade com o padrão SQL, robustez e suporte
89 + 
a tipos de dados avançados \citep{postgresql:2026}.
8 90
9 - 
\subsection{Express}
91 + 
Sua escolha se justifica pela natureza estruturada e relacional dos dados do
92 + 
domínio da aplicação (registros de humor associados a usuários, horários,
93 + 
gatilhos e categorias), que se beneficia das garantias de integridade
94 + 
referencial e das transações ACID oferecidas por um banco relacional
95 + 
maduro, em detrimento de soluções não relacionais.
10 96
11 - 
\lipsum[1-2]
97 + 
\subsection{Prisma}
98 +
99 + 
Prisma é um \textit{Object-Relational Mapper} (ORM) para o ecossistema
100 + 
Node.js/TypeScript, que gera automaticamente um cliente de acesso ao banco de
101 + 
dados tipado a partir de um esquema declarativo, além de oferecer um sistema
102 + 
de migrações versionadas \citep{prisma:2026}.
12 103
13 - 
\section{Expo e React Native}
104 + 
O Prisma foi escolhido por permitir a manutenção do esquema do banco de dados
105 + 
de forma versionada e sincronizada com o código da aplicação, reduzindo a
106 + 
chance de divergência entre a estrutura do banco e as entidades manipuladas
107 + 
pelo back-end, além de prover checagem de tipos em tempo de compilação para
108 + 
as consultas realizadas.