Conteúdo original em https://twitter.com/zanfranceschi/status/1559000993127247872

Ei dev,

Dando continuidade ao desafio de validações, essa thread aborda algo um pouco mais avançado relacionado a validações.

Na verdade têm várias outras coisas além de validações ─ tem bastante a ver com uma aplicação real.

Segue o fio pra saber mais!

cc @sseraphini

↓

A parte 01/02 é essa aqui em baixo ↓

https://twitter.com/zanfranceschi/status/1559000660506341376

Pensando em performance, algumas validações são mais pesadas. Por exemplo, fazer um request para um bureau (tipo Serasa) para validar o score de uma pessoa.

Geralmente, o que envolve IO (rede, disco, etc) gera gargalo de CPU. Num cenário de alta vazão, isso pode ser um problema.

A ideia então desse desafio é manter as validações que não envolvem IO (tipo, tamanho, obrigatoriedade, formato, etc) na API ─ parte 01 do desafio. E as validações mais pesadas serem feitas em background.

E isso pode gerar uma mudança significativa na experiência do usuário.

O primeiro passo é fazer uma mudança na API da primeira parte.

Faça com que o retorno da API seja um HTTP 201/Created ─ isso irá sinalizar que criamos um recurso do tipo Proposta. Adicione também ao retorno um cabeçalho chamado "Location" indicando a URI do novo recurso criado.

Note que, em caso de sucesso, a API de captação de propostas envia o recurso para um processamento posterior em plano de fundo e também retorna o header "Location" que indica o endereço do novo recurso criado.

Se esse endereço for imediatamente consultado, talvez retorne uma proposta com status "em processamento" ou algo assim.

Bom, agora você precisa implementar as validações mais pesadas; aquelas que exigem IO (consulta em banco, bureaux, etc).

Algumas sugestões para você implementar como validações de plano de fundo (use as que quiser, invente as suas):

• Verificar se o CPF ou RG já não existe em outras proposta;

• Usar algum serviço de API gratuita pra simular score (http://randomnumberapi.com/api/v1.0/random?min=100&max=1000&count=1);

• Etc.

A validação em plano de fundo deveria resultar em:

• A proposta estar válida e talvez abrir uma conta (que iria gerar um recurso "conta").

OU

• Proposta inválida que apenas gera um histórico/insumo para outras propostas da mesma pessoa.

Para qualquer um dos cenários, faz sentido atualizar o recurso "proposta" com esse novo status para que quem o consultar via API posteriormente saiba o que aconteceu.

Reflita um pouco aqui sobre como seria a experiência do usuário final por conta dessa abordagem assíncrona.

Confesso que estou em dúvida se essa será uma boa série de threads porque têm muitas coisas sendo abordadas ─ espero que sim. O que foi abordado:

• Processamento distribuído
• Validações em 2 etapas
• Semântica HTTP (status codes, headers)
• Experiência do usuário e dev
• Etc

Espero que tenha gostado desse desafio em duas etapas.

De qualquer forma, muito obrigado por ter lido até aqui!

Se curtiu, por favor, me dá uma força curtindo, comentando e até dando retweet no primeiro tweet dessa thread.

Um abraço! 🫂