[Desafio] - Validações 02/02
Published: 2022-08-15 02:26:00

> 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

↓

![Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/o6gsxxt7mkmhqrs2dqj3.png)

---

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.


![Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1k3zk2qlv7p9b56i48ne.png)
 
---

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).

![Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lyonvvykd9g2dexse4nu.png)

---

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! 🫂