hurbcom / challenge-bravo Goto Github PK

Boa tarde, hoje mais cedo abri um PR incorretamente. Faltava subir os readmes então fechei o PR incorreto e abri um novo que no caso é o deste link: #288

Grato pela atenção dispensada.

Caso essa API em questão seja uma API interna, não seria o caso de desenvolver um RPC e mudar o protocolo para Protobuf invés de JSON?

Por sinal, a gRPC é compatível com todas as linguagens que o HU tem afinidade.

Pessoal, bom dia.

Apenas informando, desde o início do desenvolvimento do projeto tive a preocupação de não gerar boilerplates no código do projeto, portanto, os únicos pontos onde é possível verificar boilerplates é nos arquivos de configuração. ex: web.config, Global.asax.cs, etc.

Todo o restante do código foi feito por mim, seja no back ou no front-end.

Abs

Pessoal, bom dia.

A respeito do bug relatado na documentação do pull request "README_API_PROJECT.md" sobre o swagger (inclusão da barra após o último parâmetro, caso seja numérico) estou trabalhando em melhorias para que a correção não fique apenas no front mas também no back-end. Com isso também será possível testar a requisição sem a inclusão da barra via swagger (como descrito no realme do peojeto).

Outro ponto importante, após inclusão do regex no front, os formatos aceitos para amount são: 100 - 1000.00 - 1000,00 - 100000.00 - 100000,00. Resumindo, utilizei apenas separadores de decimais (dois dígitos) e não de milhar. Não há validação para números negativos se não me engano, portanto caso testem esse input é possível que retorne erro.

Propostas para melhoria:

• Definição de uma cultura padrão para forçar o tratamento dos decimais d acordo com a cultura;
• Conversão do parâmetro amount de decimal para string;

Sobre o docker, ainda estou lendo a documentação para entender como funciona a ferramenta. Mas caso queiram testar a interface, posso publicar o projeto e passar a url postar aqui. :)

Abraço

Boa noite pessoal, vi que um dos requisitos do desafio é a API suportar 1000 requests por segundo num teste de estresse.

Como as APIs externas de conversão cambial que achei tem um limite de requisições por mês de cerca de 1000 requests, vou precisar fazer com que a minha API faça muito poucas consultas a uma API externa permitindo a conversão entre as moedas suportadas. Dai, tenho algumas perguntas:

1. Qual a quantidade máxima de moedas que podem ser suportadas? Seria o total no mundo todo (cerca de 180)?
2. Tendo em vista que trabalhando com conversão entre todas as 180 moedas, teríamos cerca de 32k possíveis conversões, é aceitável um erro de precisão na conversão (poder chegar até 0.1%)? Isso seria para reduzir o número de consultas a API externa (fazendo a conversão da moeda FROM para USD e de USD para TO)
3. Tem alguma API de conversão de moedas que vocês recomendariam usar?

Pessoal, bom dia.

É permitido que minha API consuma uma API de terceiros para exibição das conversões?

Ex:

• open exchange rates
• currency layer

Boa tarde pessoal!

Possuo um arquivo de configuração que contêm a api key da api externa usada para consseguir as rates atualizadas para as converções, para não expor essa chave, o arquivo de config no remote não contêm ela, quando eu abrir o PR esse arquivo de config vai chegar para vocês sem a chave.

Devo enviar a chave para vocês por algum outro modo, ou vocês conseguem uma api key só para vocês?
(estou usando a https://openexchangerates.org/)

Como posso lidar com a adição de moedas reais em minha aplicação? Existem moedas fictícias e moedas cuja base não é o dólar americano, e essas precisam ser ajustadas manualmente, pois não estão disponíveis na API que estou usando. Porém, há a possibilidade de adicionar moedas reais. Minha dúvida é se essas moedas deveriam ter seus valores atualizados dinamicamente (a cada hora, baseado na taxa de atualização disponível na API) ou se deveriam ser mudadas apenas manualmente pelo usuário. Uma solução que me parece razoável é permitir que o usuário escolha se deseja adicionar uma moeda como real ou não. Se for real e estiver disponível na API, permitir a cotação ao vivo junto com as 5 iniciais.

Estou na dúvida sobre o requisito de cotação dinâmica da moeda, se eu quiser cadastrar uma moeda aleatória e/ou que não existe nas APIs públicas de cotação de moedas como a API que deve ser desenvolvida no teste deve se comportar? A cotação na hora da conversão tem que ser dinâmica para todas as moedas (mesmo as que não existir nas APIs públicas de cotação)?

Pessoal, bom dia.

Subi mais algumas atualizações e consegui fechar a lógica de conversão para as moedas. (Este step me consumiu bastante tempo).

Próximo passo é refatorar a lógica e aplicar para o restante das moedas.

Vou implementar o front-end utilizando bootstrap e depois implementar o teste de estresse. Optei por criar duas solutions separadas (uma para a API e outra para o front/client). Provável que eu tenha que configurar dois containers por conta dessa escolha.

Estou trabalhando com a previsão de fechar API (só falta replicar a lógica já pronta para as outras moedas) hoje e o Front até quarta.

Para a configuração do docker, vou reservar a quinta-feira para aprender como fazer isso e preparar o pull request para a sexta-feira (quando completa a data limite de 10 dias).

o/

Gostaria de saber se a contação precisa ser atualizada dinamicamente, ou simplesmente posso pegar as cotações na data de hoje e manter estes valores?