Aula 1: Introdução ao Desenvolvimento Web e Mobile

Esta é a primeira aula do Módulo 1 e a primeira da disciplina. Ela responde a uma pergunta que parece simples e não é: o que exatamente muda quando o mesmo sistema precisa atender um navegador e um celular?

A resposta não é "a linguagem" nem "o framework". É o conjunto de restrições em que cada cliente opera — rede, memória, ciclo de vida, forma de atualização — e o modo como essas restrições empurram o projeto para uma certa arquitetura. Esta aula estabelece esse vocabulário. As três aulas seguintes o transformam em decisões concretas: arquitetura (aula 2), linguagem (aula 3) e contrato (aula 4).

O que vem depois	Onde
Escolher a arquitetura e a estratégia mobile	Aula 2 — Arquiteturas e frameworks
A linguagem comum ao serviço e ao cliente web	Aula 3 — TypeScript
O contrato entre o serviço e os clientes	Aula 4 — API REST

Objetivos

Ao final desta aula, você deve ser capaz de:

• Distinguir aplicação web de aplicação móvel em termos de plataforma de execução, distribuição, atualização e experiência de uso.
• Explicar o modelo cliente–servidor e justificar por que o servidor nunca inicia a conversa.
• Descrever o percurso completo de uma requisição, do endereço digitado até a tela exibida.
• Identificar as partes de uma URL, de uma requisição e de uma resposta HTTP.
• Separar responsabilidades de front-end, back-end e persistência, e justificar por que a validação precisa existir dos dois lados.
• Comparar o modelo tradicional renderizado no servidor com o modelo desacoplado baseado em API.
• Enumerar as restrições específicas do dispositivo móvel e apontar, para cada uma, uma consequência concreta no código.

---

Parte 1 — Web e mobile: a mesma coisa?

A pergunta abre praticamente todo curso da área, e a resposta honesta é depende do que você está olhando.

Do ponto de vista dos conceitos — modelar dados, expor operações, autenticar usuários, tratar erros — web e mobile são a mesma disciplina. Do ponto de vista do ambiente de execução, são mundos diferentes o bastante para justificar duas frentes distintas nesta disciplina.

Característica	Aplicação web	Aplicação móvel
Onde executa	Navegador, em cima do sistema operacional	Diretamente sobre o sistema operacional do dispositivo
Linguagens típicas	HTML, CSS, JavaScript/TypeScript	Kotlin, Swift, Dart, JavaScript/TypeScript
Distribuição	Publicação no servidor; o usuário só recarrega	Loja de aplicativos, com revisão e aprovação
Atualização	Imediata e sob controle de quem publica	Depende do usuário aceitar atualizar
Alcance de recursos	Restrito pelo sandbox do navegador	Câmera, GPS, sensores, notificações, arquivos
Rede	Em geral estável	Intermitente por natureza; pode não existir
Ciclo de vida	A aba fica aberta	O sistema pode encerrar o processo sem avisar
Experiência	Mais uniforme entre dispositivos	Mais próxima das convenções de cada plataforma

A linha entre os dois é menos nítida do que parece

Um Progressive Web App instalado na tela inicial se parece muito com um aplicativo nativo; um aplicativo "nativo" pode ser, por dentro, uma página web embarcada. A aula 2 desfaz essa confusão examinando o que de fato executa em cada estratégia.

Duas linhas que se aproximaram

Vale registrar como chegamos aqui, porque explica muita coisa do estado atual:

Quando	O que mudou
Anos 1990	A web é feita de documentos. O servidor devolve HTML pronto e cada clique recarrega a página inteira
2005	A técnica que ficou conhecida como AJAX populariza a atualização de partes da página sem recarregá-la
2007–2008	Chegam o iPhone e o Android com suas lojas: nasce a distribuição de software por loja de aplicativos
2010–2015	Aplicações web viram Single Page Applications; o servidor passa a devolver dados, não telas
2015 em diante	Consolidam-se as estratégias multiplataforma (React Native, Flutter) e o backend passa a ser, primeiro, uma API

O ponto da linha do tempo não são as datas. É que o servidor deixou de produzir telas e passou a produzir dados — e essa mudança é o que torna possível um mesmo backend atender um navegador e um celular. É essa a arquitetura desta disciplina.

---

Parte 2 — O modelo cliente–servidor

Quase tudo nesta disciplina é uma variação de um arranjo só: um programa pede, outro responde.

Três propriedades desse arranjo têm consequências práticas que reaparecem o semestre inteiro:

O cliente sempre inicia. O servidor não tem como "avisar" o aplicativo de que algo mudou dentro do modelo básico de requisição–resposta. Se a tela precisa reagir a um evento do servidor — uma mensagem nova, um pedido aceito — é preciso uma técnica adicional: consultar periodicamente, manter uma conexão aberta (WebSocket) ou usar notificações push. A aula 4 detalha essas alternativas.

Cliente e servidor são independentes. Podem ser escritos em linguagens diferentes, evoluir em ritmos diferentes e rodar em máquinas diferentes. O que os mantém integrados é o contrato — e é por isso que a aula 4 existe.

O servidor é compartilhado; o cliente, não. Cada usuário tem sua própria cópia do front-end rodando no próprio dispositivo, e nunca precisa se preocupar com concorrência. O servidor atende milhares de usuários ao mesmo tempo, e precisa. Essa assimetria explica por que problemas de concorrência, transação e cache aparecem quase sempre do lado do servidor.

Nada que roda no cliente é confiável

O código do front-end está na máquina do usuário: pode ser lido, alterado e executado fora do contexto do aplicativo. Qualquer chamada que o aplicativo faz, uma pessoa pode fazer manualmente com valores diferentes. A consequência é direta e sem exceção: toda regra que importa precisa ser verificada no servidor, mesmo que o cliente já a verifique.

---

Parte 3 — O que acontece entre a URL e a tela

Vale percorrer o caminho completo uma vez, porque quase todo problema de desempenho ou de erro difícil de diagnosticar mora em uma dessas etapas.

1. Endereço. O usuário abre uma URL, ou o aplicativo monta uma internamente.
2. DNS. O nome (api.exemplo.br) é traduzido para um endereço IP.
3. Conexão. Estabelece-se a conexão TCP e, sobre ela, a camada de segurança TLS — o "s" do https.
4. Requisição. O cliente envia método, caminho, cabeçalhos e, quando houver, corpo.
5. Processamento. O servidor identifica a operação, aplica as regras, consulta a base de dados.
6. Resposta. Volta um código de status, cabeçalhos e o corpo.
7. Exibição. O cliente interpreta a resposta e atualiza a tela.

Os passos 2 e 3 acontecem uma vez por conexão e ficam em cache. Em uma aplicação que já está aberta, cada nova tela repete apenas os passos 4 a 7 — o que explica por que a primeira tela é sempre a mais lenta.

As partes de uma URL

https://api.exemplo.br:443/alunos/42/notas?semestre=2026-1#observacoes
└─┬──┘  └──────┬──────┘└┬┘└──────┬───────┘└──────┬────────┘└────┬────┘
esquema      host     porta    caminho      query string    fragmento

Parte	O que faz
Esquema	O protocolo. Em produção, sempre https
Host	Quem responde
Porta	Implícita: 443 para https, 80 para http
Caminho	Identifica qual recurso — quem é o aluno, qual a nota
Query string	Modifica a consulta: filtros, ordenação, paginação
Fragmento	Só existe no navegador; nunca chega ao servidor

A distinção entre caminho e query string parece um detalhe e não é: o caminho diz o que você quer, a query string diz como você quer. A aula 4 desenvolve essa regra ao modelar recursos.

Requisição e resposta

Uma requisição HTTP tem quatro partes:

POST /alunos HTTP/1.1
Host: api.exemplo.br
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...

{"nome": "Ana Souza", "email": "ana@exemplo.br"}

• a linha inicial, com o método (POST) e o caminho (/alunos);
• os cabeçalhos, que descrevem a requisição — formato do corpo, credenciais, idioma aceito;
• uma linha em branco;
• o corpo, opcional (um GET normalmente não tem).

A resposta segue a mesma estrutura, trocando a linha inicial pelo código de status:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /alunos/42

{"id": 42, "nome": "Ana Souza", "email": "ana@exemplo.br"}

As classes de código de status seguem uma lógica simples:

Faixa	Significado	Quem tem o problema
2xx	Deu certo	Ninguém
3xx	Está em outro lugar	Ninguém; o cliente segue adiante
4xx	A requisição está errada	O cliente
5xx	O servidor falhou	O servidor

A fronteira entre 4xx e 5xx é a mais útil no dia a dia: ela responde a pergunta "o erro é meu ou dele?" antes de qualquer investigação. A aula 4 trata dos códigos individualmente.

Vale abrir agora

Abra as ferramentas de desenvolvedor do navegador (F12), vá até a aba Network e recarregue qualquer site que você use. Cada linha é uma requisição, com método, status, tamanho e tempo. Passar cinco minutos ali antes da próxima aula vale mais do que reler esta seção.

---

Parte 4 — Front-end, back-end e persistência

A divisão entre front-end e back-end não é organizacional — é uma divisão de responsabilidades ditada pelo ambiente de execução.

	Front-end	Back-end
Onde executa	No dispositivo do usuário	Em servidor sob controle de quem publica
Tecnologias nesta disciplina	Next.js/React (web), Flutter (mobile)	NestJS sobre Node.js
Concorrência	Não é problema: cada usuário tem sua cópia	Central: milhares de requisições simultâneas
Cache	No navegador ou no armazenamento local do app	Em memória, em Redis ou em CDN
Segurança	Melhora a experiência; não garante nada	Onde a garantia efetivamente está
Objetivo	Interface correta, responsiva e compreensível	Regras corretas, dados íntegros, acesso controlado

Por que validar duas vezes não é redundância

É a pergunta que todo mundo faz na primeira semana. As duas validações têm objetivos diferentes:

• A validação no front-end é sobre experiência: avisar imediatamente que o e-mail está malformado, sem esperar a ida e a volta na rede. Ela pode ser contornada.
• A validação no back-end é sobre integridade: garantir que nenhum dado inválido entre na base, venha de onde vier. Ela não pode ser contornada.

Suprimir a primeira degrada a experiência. Suprimir a segunda cria uma falha de segurança.

Onde mora a regra de negócio

Uma regra de negócio deve morar no back-end — sempre. Se um aluno só pode se matricular em disciplinas cujo pré-requisito ele já cursou, essa verificação precisa estar no serviço. O front-end pode também verificar, para desabilitar o botão e explicar o motivo; mas se apenas ele verificar, a regra não existe.

O critério prático: se contornar essa verificação causa um problema real, ela precisa estar no servidor.

---

Parte 5 — O que muda no mobile

Tudo o que vimos até aqui vale para os dois clientes. Esta seção trata do que é específico do celular — e é aqui que a maior parte das surpresas acontece.

A rede é intermitente por hipótese

No navegador, "sem internet" é a exceção. No celular, é um estado normal do sistema: elevador, metrô, roaming, dados esgotados, Wi-Fi que conecta mas não navega.

Isso muda o projeto do cliente:

• Toda chamada de rede pode falhar, e a tela precisa de um estado para isso — não um null silencioso.
• A latência é variável. Uma requisição que leva 40 ms no laboratório pode levar 4 s no 3G.
• Dados custam dinheiro para o usuário. Baixar uma lista de dez mil registros para exibir vinte não é apenas ineficiente.
• Cache local deixa de ser otimização e vira requisito de usabilidade: o app precisa mostrar algo antes da resposta chegar.

Bateria e recursos são finitos

Um laço de espera ocupada, uma requisição a cada segundo ou o GPS ligado sem necessidade aparecem para o usuário como "esse aplicativo acaba com a bateria" — e o sistema operacional reage suspendendo o processo.

O ciclo de vida não é o da aba

Esta é a diferença mais consequente e a menos intuitiva para quem vem da web.

No navegador, a aba fica aberta e o estado da página sobrevive enquanto o usuário não fechar. No celular, o sistema operacional pode encerrar o processo a qualquer momento para liberar memória, sem avisar — e o usuário, ao voltar, espera encontrar a tela como deixou.

Consequências diretas no código:

• salvar rascunhos de formulário antes de sair da tela;
• tratar o token expirado no retorno do segundo plano;
• pausar timers, sensores e uploads ao sair do primeiro plano;
• reconstruir o estado da tela sem assumir que ele ainda está em memória.

Distribuição e atualização passam por terceiros

	Web	Mobile
Publicar	Enviar os arquivos ao servidor	Submeter à loja e aguardar revisão
Prazo	Minutos	Horas a dias
Corrigir um erro	Publicar de novo	Nova submissão, nova revisão
Quem atualiza	Quem publica	O usuário, quando quiser
Versões em uso	Uma	Várias, simultaneamente, por tempo indefinido

A última linha é a que mais afeta o backend. Uma versão antiga do aplicativo pode continuar em uso por meses, e ela vai continuar chamando a API do jeito antigo. Por isso a aula 4 dedica uma seção inteira a versionamento e mudanças compatíveis: no mundo mobile, quebrar o contrato não quebra uma tela — quebra os aparelhos de quem ainda não atualizou.

Fragmentação

Além das versões do seu aplicativo, há as versões do sistema operacional, os tamanhos de tela, as densidades de pixel e as camadas de personalização dos fabricantes. Testar em um único aparelho diz pouco. Emuladores ajudam, mas não substituem o teste em dispositivo real.

---

Parte 6 — Onde isso nos leva

Recapitulando as forças que atuam sobre o projeto:

• o servidor concentra o que precisa ser confiável e compartilhado;
• os clientes concentram o que precisa ser rápido e específico de cada plataforma;
• o navegador e o celular operam sob restrições muito diferentes;
• versões antigas do aplicativo continuam em uso por tempo indeterminado.

A arquitetura que responde a essas quatro forças é a mesma que esta disciplina adota: um serviço, dois clientes, um contrato explícito entre eles. A aula 2 examina as alternativas a essa escolha — e por que ela é, hoje, a opção padrão.

---

Erros comuns

Erro	Consequência
Validar apenas no front-end	A regra não existe: basta chamar a API diretamente
Tratar falha de rede como caso excepcional	O aplicativo trava ou mostra tela em branco no metrô
Assumir que o estado da tela sobrevive ao segundo plano	O usuário volta e perde o que preencheu
Colocar identificador na query string (/alunos?id=42)	A URL deixa de nomear o recurso e o cache deixa de funcionar
Confundir 4xx com 5xx	O erro é investigado no lugar errado
Baixar a coleção inteira para exibir uma página	Funciona no laboratório, consome os dados do usuário em produção
Publicar uma mudança incompatível na API	Quebra os aplicativos já instalados, que não atualizam sozinhos
Guardar segredo (chave, senha) no código do cliente	Está publicado: qualquer pessoa consegue extrair

---

Exercícios (Checkpoints)

1. Compare aplicação web e aplicação móvel em quatro dimensões — execução, distribuição, atualização e acesso a recursos do dispositivo — e indique, para cada uma, uma consequência prática no projeto do backend.

2. Explique por que, no modelo cliente–servidor, o servidor não consegue avisar o aplicativo de que algo mudou. Cite duas técnicas que contornam essa limitação e diga em que situação cada uma é preferível.

3. Percorra os sete passos entre digitar https://ensino.diegoinacio.com.br/dev-web-mobile e ver a página. Indique em qual passo cada problema abaixo se manifestaria: (a) o domínio expirou; (b) o certificado é inválido; (c) a consulta ao banco está lenta; (d) uma imagem não carrega.

4. Decomponha a URL https://api.escola.br/turmas/7/alunos?ativo=true&pagina=2 em suas partes e explique por que 7 está no caminho enquanto pagina está na query string.

5. Classifique cada situação como 2xx, 4xx ou 5xx, justificando: (a) o aluno foi criado; (b) o e-mail enviado é inválido; (c) o banco de dados está fora do ar; (d) o token expirou; (e) o recurso não existe.

6. Justifique, com um exemplo concreto de um sistema acadêmico, por que validar no front-end e no back-end não é duplicação de esforço. Depois, descreva o que aconteceria se apenas a validação do front-end existisse.

7. Descreva três decisões de projeto que um aplicativo Flutter precisa tomar por causa do ciclo de vida móvel e que o cliente web equivalente não precisa. Para cada uma, indique o que acontece se ela for ignorada.

8. Analise o cenário: uma nova versão da API renomeia o campo nome para nomeCompleto. A aplicação web é atualizada no mesmo dia. Explique o que acontece com o aplicativo móvel e proponha uma forma de fazer essa mudança sem quebrar as versões instaladas.

9. Investigue, com as ferramentas de desenvolvedor do navegador, um site que você usa. Registre: quantas requisições a primeira tela dispara, quantas são de dados e quantas de recursos estáticos, e qual é a mais lenta. Comente o que mudaria se esse mesmo site fosse um aplicativo móvel em rede 3G.

---

Referências

Principais

• MDN — Visão geral do HTTP — protocolo, métodos, cabeçalhos e status
• MDN — O que é uma URL — anatomia e partes
• MDN — Códigos de status HTTP — referência completa
• AWS — Diferença entre front-end e back-end — comparação por responsabilidade

Aprofundamento

• Android Developers — Ciclo de vida de atividades — os estados e as transições, no Android
• Apple — Managing your app's life cycle — o equivalente no iOS
• web.dev — Métricas de desempenho — como se mede a experiência percebida
• RFC 9110 — HTTP Semantics — a especificação vigente do HTTP