Flutter + API: checklist de deploy de backend

Resposta rápida

Antes de publicar o app Flutter apontando para a API, valide o contrato, o HTTPS, as variáveis de ambiente, autenticação, CORS, migrações e rollback. A versão móvel pode permanecer instalada por semanas; por isso, alterações incompatíveis no backend precisam de compatibilidade temporária.

Veja a infraestrutura: VPS com monitoramento e backup semanal para colocar este projeto no ar.

1. Congele o contrato

Liste endpoints, campos obrigatórios, códigos de erro e versões. Não remova um campo usado por uma versão antiga do aplicativo sem medir clientes ativos e oferecer transição. Testes de contrato no CI ajudam a detectar mudanças antes do deploy.

2. Separe configuração e segredos

URL da API, modo de ambiente e flags podem ser públicos conforme o desenho; chaves privadas, tokens e credenciais não devem ficar no app ou no repositório. No backend, injete secrets pelo ambiente de execução e registre somente nomes, não valores.

3. HTTPS, CORS e autenticação

Use certificado válido e valide cadeia em dispositivo real. Configure CORS para origens necessárias, não * por comodidade. Defina expiração, rotação e revogação de tokens. Rate limiting e limites de payload protegem endpoints públicos.

4. Banco e migrações

Faça backup antes de migrar, teste em cópia e prefira migrações compatíveis em duas etapas: adicionar, publicar código que usa, e remover depois. Uma migração irreversível exige janela, cópia e plano de retorno.

5. Healthcheck e rollout

Crie uma rota que confirme que o processo está vivo e, se necessário, dependências essenciais. Não exponha detalhes internos. Publique primeiro para uma parcela controlada, monitore erros e só então amplie.

curl -fsS https://api.exemplo.com/health
curl -i -H 'Authorization: Bearer TOKEN_DE_TESTE' https://api.exemplo.com/v1/profile

Use tokens de teste. Observe latência, 4xx, 5xx, logs e saturação. Uma VPS para o backend precisa de espaço para logs, banco e processos auxiliares.

Registre a versão do backend, do contrato e do aplicativo durante a validação.

Checklist final

• [ ] Contrato compatível com versões antigas.
• [ ] Segredos fora do código e do app.
• [ ] HTTPS, CORS e auth testados em dispositivo.
• [ ] Migração e backup validados.
• [ ] Rollback e monitoramento disponíveis.

FAQ

Posso mudar a URL da API sem atualizar o app?

Somente se houver uma camada de compatibilidade ou configuração remota segura. Apps já instalados podem continuar usando a URL antiga.

Healthcheck deve consultar todas as dependências?

Não necessariamente. Escolha um teste que indique capacidade real sem criar uma cascata de falhas.

Compatibilidade durante a transição

Prefira adicionar novos campos sem remover os antigos, aceite versões antigas durante uma janela conhecida e registre a versão do cliente quando houver erro. Se uma mudança exige migração de dados, publique primeiro o backend compatível e só depois mude o app. Faça o rollback de código separadamente do rollback de banco; restaurar um banco sem entender novas escritas pode causar perda de dados.