Atlantis

TCC do curso de Análise e Desenvolvimento de Sistemas na UFPR (defendido em março de 2023). O produto está no ar na Vercel; o banco no Supabase está pausado, então a demo roda em modo degradado.

O problema

Montar um aquário doméstico saudável é mais difícil do que parece. À medida que o ecossistema cresce, as restrições ficam mais específicas — parâmetros de água (pH, temperatura, dGH, salinidade), capacidade de filtragem, substrato, e espécies que viram territoriais nas condições erradas. Errar significa peixe morto ou peixes se agredindo.

As opções pra um hobbysta hoje são:

1. Fóruns e blogs — abundantes mas contraditórios. Três sites dão três faixas diferentes de temperatura pra mesma espécie.
2. Pet shops — incentivos desalinhados. Vender a próxima garrafinha importa mais do que te avisar que o ciclídeo raro que você quer vai comer seus tetras.
3. Ferramentas existentes — usáveis mas limitadas. Pesquisei três:
   • AqAdvisor: matemática de compatibilidade sólida, UI hostil soterrada de propaganda, sem atribuição de fonte.
   • Aqua-Fish: páginas de espécie boas, mas sem checagem de compatibilidade no nível do aquário.
   • The Aquarium Wiki: colaborativa, mas qualquer um edita e você não sabe quem.

Comparando a mesma espécie (Betta splendens) nos três, voltei com volumes mínimos, temperaturas, pH e dGH diferentes. O problema de fundo não é UI — é que ninguém é responsável pelo dado.

A abordagem

Atlantis trata qualidade de dados como o produto central, não como detalhe colateral. Três escolhas de design saem disso:

1. Modelo de usuário em duas camadas: hobbystas ("aquaristas") consomem o dado; especialistas credenciados o curam. Cada registro de espécie é assinado pelo especialista que editou por último, com link pro perfil público dele (bio, e-mail, link profissional).
2. Compatibilidade como feedback ao vivo, não relatório final. Conforme o usuário adiciona peixes, o card do aquário recalcula faixas de parâmetro, volume mínimo, vazão de filtro, watts de termostato. Conflitos ficam vermelhos no card do aquário e na espécie problemática — você vê por que uma combinação quebra, não só que ela quebrou.
3. Planos persistidos, não consulta única. Aquaristas salvam aquários na conta e editam ao longo do tempo. O plano é documento vivo, não sessão de calculadora.

Arquitetura

Três papéis com permissões: aquarista planeja aquários e lê o banco; especialista também escreve espécies, substratos e alimentos; admin também gerencia papéis de usuário. Checagens de permissão moram nas API routes; o schema é normalizado em torno do n:n peixe ↔ aquário via tabela aquarium_fish que carrega a quantidade por espécie.

Decisões técnicas & trade-offs

Por que pivotar de MongoDB pra Supabase no meio? O plano original era MongoDB. Quando meu colega de projeto saiu e fiquei sozinho, reavaliei: o domínio é inerentemente relacional (peixe ↔ substrato ↔ alimento ↔ aquário ↔ usuário), as queries são filtros por faixa de parâmetro que SQL faz limpo, e Supabase empacota auth + Postgres + storage — então entregaria mais rápido sozinho. Stack mais simples me poupou semanas que eu não tinha.

Por que Next.js pra front e API? Um único alvo de deploy (Vercel), tipos compartilhados entre cliente e route handlers, nenhum segundo runtime pra manter. Pra um TCC solo o multiplicador de produtividade era o ponto.

Por que mostrar o especialista que editou cada espécie por último? A tese inteira do produto é que qualidade de dado importa. Se o dado não é confiável, você só reconstruiu o The Aquarium Wiki com CSS bonito. Atribuição é o sinal mais barato de accountability, e dá ao especialista incentivo de portfólio pra manter o registro correto.

O que ele faz

O fluxo de planejamento de aquário é a parte que dá pra demonstrar:

• Agregação de parâmetros ao vivo — faixas de temperatura, pH, salinidade e dGH se estreitam conforme espécies são adicionadas, calculadas como interseção das tolerâncias de cada uma.
• Dimensionamento de volume e equipamento — volume mínimo do tanque, vazão do filtro (l/h) e watts do termostato atualizam conforme peixes entram no plano.
• Alertas de compatibilidade — avisos de temperamento (territorialista, agressivo com maiores/menores) renderizam inline no card da espécie pro usuário ver antes de adicionar.
• Planos salvos — Meus Aquários lista os planos do aquarista; reabrir um rehidrata o editor com as espécies selecionadas.

O que eu faria diferente

• Validar o flywheel de curadoria primeiro. Construí o app inteiro de três papéis antes de testar se especialistas realmente preencheriam 19 campos por espécie. O movimento certo era uma planilha do Google primeiro, e só construir o app depois do dado estar real.
• Não fazer CRUD público de substratos e alimentos. O catálogo é pequeno e muda devagar — não precisava de admin UI. Um arquivo seed teria resolvido e poupado várias telas de trabalho.
• Planejar a pausa do banco. O free tier do Supabase pausa projetos inativos. A demo viva sobreviveria melhor a uma pausa com fallback estático; hoje banco pausado significa catálogo de espécies vazio até eu despausar.

Status & links

• Demo ao vivo: atlantis-aquarium.vercel.app — front roda; banco pode estar pausado.
• GitHub: MarcosNespolo/atlantis
• Monografia (PT): TCC completo com requisitos, diagramas UML, especificações de caso de uso e avaliação por critérios ergonômicos — disponível sob solicitação.