ATIVIDADES · UM PRODUTO, CINCO ENTREGAS

Do problema ao aplicativo publicado

A turma evoluirá o mesmo produto: pesquisa e protótipo, implementação com Node e Express, adoção de framework, arquitetura e segurança, publicação em cloud e apresentação final.

PROJETO EVOLUTIVO

Cada etapa reutiliza a anterior e acrescenta uma decisão nova.

Não são cinco aplicativos independentes. O objetivo é observar como um produto amadurece: primeiro entendemos o problema; depois entregamos uma versão simples; em seguida introduzimos abstrações, segurança, arquitetura e infraestrutura justificadas pelas necessidades do projeto.

1
Descobrirpesquisa · produto · protótipo
 2
ConstruirGit · Docker · Express · front próprio
 3
EvoluirAngular · Vue · React/Next
 4
Fortalecersegurança · slices · cloud
 5
Apresentarproduto · código · evidências
Modelo preenchível. Use o arquivo modelo-projeto-integrador.md para registrar pesquisa, plano de negócios, funcionalidades, decisões técnicas, testes, segurança, deploy e roteiro da apresentação.
1

DESCOBERTA E PROTÓTIPO

Invente um aplicativo e demonstre que existe um problema real para resolver.

Antes de escolher tecnologia, explique quem sofre o problema, em qual contexto e qual resultado o aplicativo pretende produzir. Nome, logo, telas e funcionalidades devem nascer dessa proposta de valor.

A pesquisa preliminar faz parte desta etapa. Pesquise 10 bibliotecas e 3 frameworks que poderiam ser usados no projeto. Não basta listar nomes: compare finalidade, licença, manutenção, documentação, comunidade, tamanho/impacto e adequação ao problema.

Pesquisa tecnológica

  • 10 bibliotecas candidatas;
  • 3 frameworks candidatos;
  • fonte oficial e data da consulta;
  • vantagens, limitações e licença;
  • escolha inicial justificada.

Conceito do produto

  • nome e frase curta;
  • problema e público-alvo;
  • proposta de valor;
  • diferencial;
  • hipóteses que precisam ser validadas.

Identidade visual

  • logo criada com apoio de um chat ou ferramenta gráfica;
  • prompt e versões preservados;
  • paleta, tipografia e aplicação;
  • verificação de contraste;
  • origem e licença dos recursos.

Plano de negócios enxuto

  • segmentos de clientes;
  • canais e relacionamento;
  • fontes de receita ou sustentabilidade;
  • custos principais;
  • métricas de sucesso e riscos.

Funcionalidades

  • personas ou perfis;
  • jornada principal;
  • requisitos funcionais;
  • requisitos não funcionais;
  • MVP priorizado em deve, deveria e poderia.

Protótipo navegável

  • Figma ou programa equivalente;
  • fluxo feliz completo;
  • estados vazio, carregando e erro;
  • versões desktop e mobile;
  • link com permissão de visualização.

Como diferenciar biblioteca e framework na pesquisa

CritérioBibliotecaFramework
EscopoResolve uma capacidade delimitada: validação, datas, gráficos, testes, HTTP ou componentes.Organiza uma parte ampla da aplicação e oferece convenções, ciclo de vida e estrutura.
ControleSeu código chama a biblioteca quando precisa.O framework normalmente conduz o fluxo e chama o código da aplicação em pontos definidos.
Exemplo de cuidadoUma biblioteca popular pode ser desnecessária para uma operação pequena.Um framework reduz decisões locais, mas aumenta compromisso, aprendizagem e custo de migração.
Classifique com a terminologia do próprio projeto. React se apresenta como biblioteca; Next.js se apresenta como framework React; Angular e Vue se apresentam como frameworks. Registre a fonte usada em vez de decidir apenas pela popularidade.

Pronto quando

Outra pessoa consegue entender o problema, o público, a proposta de valor e o fluxo principal sem receber explicação oral; o protótipo é navegável; e cada escolha tecnológica possui evidência e justificativa.

2

PRIMEIRA VERSÃO FUNCIONAL

Construa com Git, Docker, Node, Express e front-end próprio.

Implemente o MVP sem framework de interface: HTML semântico, CSS e JavaScript do navegador consomem uma API Express. Essa restrição torna visíveis DOM, eventos, HTTP, estado e integração antes das abstrações da etapa seguinte.

Front próprioHTML · CSS · JavaScript
HTTP / JSONfetch · status · erros
Node + Expressrotas · regras · dados
Dockerexecução reproduzível

Entregáveis técnicos

  • repositório Git com histórico de commits compreensível;
  • README.md com instalação, execução e decisões;
  • API Express com GET /health e ao menos um recurso do domínio;
  • front-end próprio consumindo a API com fetch;
  • Dockerfile, .dockerignore e compose.yaml;
  • .env.example sem qualquer segredo real.

Comportamentos obrigatórios

  • fluxo principal do MVP funcionando;
  • validação de entrada no servidor;
  • status HTTP coerentes;
  • feedback de carregamento, sucesso, vazio e erro no front;
  • dados persistidos ou estratégia de persistência explicada;
  • execução completa por comando documentado.

Estrutura-base sugerida

meu-app/
├─ apps/
│  ├─ api/                 # Node + Express
│  │  ├─ src/
│  │  ├─ package.json
│  │  └─ Dockerfile
│  └─ web/                 # HTML + CSS + JavaScript próprio
├─ docs/                       # pesquisa, negócio, UX e arquitetura
├─ design/                     # logo, exportações e link do protótipo
├─ compose.yaml
├─ .env.example
├─ .gitignore
└─ README.md

Pronto quando

Uma pessoa que acabou de clonar o repositório consegue iniciar a aplicação pelos comandos documentados, acessar o front-end, executar o fluxo principal e verificar a comunicação com a API sem corrigir arquivos manualmente.

3

FRONT-END COM FRAMEWORK

Mantenha a API Express e evolua a interface com Angular, Vue ou React/Next.

A etapa anterior já usa Express. Agora o desafio é preservar o contrato HTTP e reconstruir o front-end com uma das opções estudadas. Compare a implementação nova com a versão feita diretamente com APIs do navegador.

Angular

Estrutura abrangente com componentes, injeção de dependência, roteamento e ferramentas integradas.

Vue

Framework progressivo, baseado em componentes, que pode crescer da melhoria incremental para uma SPA completa.

React ou Next.js

React organiza a interface como componentes; Next.js acrescenta roteamento, renderização e convenções de framework.

A aplicação deve demonstrar

  • componentes reutilizáveis;
  • roteamento com URLs navegáveis;
  • formulários e validação;
  • consumo da API Express;
  • estado de carregamento, sucesso e erro;
  • configuração por ambiente;
  • layout responsivo e navegação por teclado.

O relatório deve comparar

  • quantidade e organização do código;
  • experiência de desenvolvimento;
  • tamanho e processo de build;
  • gerenciamento de estado;
  • testabilidade;
  • acessibilidade;
  • custos e benefícios reais para este aplicativo.

Pronto quando

O fluxo principal funciona no framework escolhido, recarregar uma rota válida não produz erro, falhas da API geram feedback útil e a decisão pelo framework está documentada com evidências do próprio projeto.

4

SEGURANÇA, ARQUITETURA E CLOUD

Organize o back-end por casos de uso, aplique controles de segurança e publique os contêineres.

Vertical Slice agrupa o que muda junto. Em vez de espalhar cada funcionalidade apenas entre pastas globais de controller, service e repository, cada caso de uso reúne rota, validação, handler e acesso aos dados necessários. Preocupações realmente transversais permanecem compartilhadas.

ANTES · CAMADAS HORIZONTAIS

Arquivos agrupados pelo tipo técnico

controllers/services/repositories/

Uma funcionalidade simples atravessa várias pastas e pode depender de abstrações compartilhadas.

DEPOIS · VERTICAL SLICE

Arquivos agrupados pelo caso de uso

features/criar-projeto/features/listar-projetos/features/publicar-projeto/

Cada slice encapsula o caminho necessário para atender uma requisição ou comando.

apps/api/src/
├─ features/
│  ├─ criar-projeto/
│  │  ├─ route.js
│  │  ├─ schema.js
│  │  ├─ handler.js
│  │  └─ handler.test.js
│  └─ listar-projetos/
│     ├─ route.js
│     ├─ handler.js
│     └─ handler.test.js
├─ shared/                     # erros, autenticação, banco, logs
├─ app.js
└─ server.js

Entrada e saída

Validação por schema, limite de payload, serialização segura e mensagens de erro sem detalhes internos.

Identidade e acesso

Autenticação quando necessária, autorização por recurso e testes contra acesso indevido.

HTTP

HTTPS no ambiente publicado, headers de segurança, CORS restrito e cookies configurados conforme o uso.

Abuso

Rate limiting nas rotas sensíveis, timeouts, paginação e limites de consumo.

Segredos

Nenhuma credencial no Git ou na imagem; variáveis e secret manager da plataforma no deploy.

Evidência

Logs estruturados sem dados sensíveis, identificação de requisição, testes e registro das ameaças tratadas.

Entrega em cloud

1Testartestes e build local
2Construirimagem versionada
3Publicarregistry de imagens
4Executarserviço cloud via contêiner
5Observarhealth check, logs e métricas
“Está em cloud” não é evidência suficiente. Entregue URL HTTPS, plataforma escolhida, diagrama, configuração das variáveis, estratégia de persistência, health check, logs e instrução de rollback ou nova publicação. Nunca entregue chaves ou senhas.

Pronto quando

A aplicação responde por HTTPS, reiniciar o serviço não exige alteração manual da imagem, os slices correspondem a casos de uso reconhecíveis e os controles de segurança possuem teste ou demonstração reproduzível.

5

APRESENTAÇÃO FINAL

Apresente o produto, as decisões e as evidências — não apenas as telas.

A apresentação deve contar a evolução do projeto e provar que a equipe compreende o que construiu. Slides apoiam a narrativa; o repositório, o protótipo, os testes e o deploy sustentam as afirmações.

  1. 1

    Problema e público

    Quem precisa do produto, qual dor foi priorizada e qual resultado define sucesso.

  2. 2

    Pesquisa e protótipo

    Bibliotecas, frameworks, identidade, plano de negócios e mudanças provocadas pelo protótipo.

  3. 3

    Demonstração

    Fluxo principal executado ao vivo, incluindo um estado de erro ou recuperação.

  4. 4

    Arquitetura

    Front, API, slices, dados, contêineres, cloud e caminho completo de uma requisição.

  5. 5

    Qualidade e segurança

    Testes, acessibilidade, controles aplicados, ameaças consideradas e limitações restantes.

  6. 6

    Aprendizados

    Decisão que funcionou, decisão que mudaria e próxima evolução do produto.

Evidências para entregar

  • link do repositório e release/tag apresentada;
  • link do protótipo;
  • URL publicada;
  • documentação das etapas;
  • diagrama arquitetural;
  • resultado dos testes;
  • slides ou roteiro final.

Plano de contingência

  • vídeo curto do fluxo principal;
  • capturas da aplicação publicada;
  • dados de demonstração preparados;
  • branch/tag estável;
  • instruções para execução local;
  • nenhum segredo exposto nos materiais.

Pronto quando

A equipe consegue relacionar requisito, tela, endpoint, slice, contêiner, controle de segurança e evidência. Todos participam e conseguem responder por decisões concretas do projeto.

RUBRICA SUGERIDA

Avalie o processo, o produto e a capacidade de justificar decisões.

DimensãoPeso sugeridoEvidência principal
Descoberta, pesquisa e protótipo20%Documento da etapa 1 e protótipo navegável.
Base funcional e conteinerizada20%Repositório, histórico Git e execução via Docker.
Front-end com framework20%Aplicação e comparação com o front próprio.
Arquitetura, segurança e cloud25%Slices, testes, controles, imagem e deploy HTTPS.
Apresentação e domínio do projeto15%Demonstração, narrativa e respostas da equipe.

REFERÊNCIAS E APOIO

Documentação oficial para executar e justificar o projeto

Implementação

Arquitetura, segurança e entrega