Відео

Quais são pontos críticos que tu levantou ?

Ótima pergunta! Não é necessário usar o `ToList()` para utilizar o `CountBy` (ou métodos semelhantes) em muitas situações. O `ToList()` serve para materializar os dados, ou seja, trazer tudo para a memória. Isso só é útil se você realmente precisar manipular os dados já carregados ou fazer várias operações sobre eles. No caso de métodos como `CountBy`, eles podem ser aplicados diretamente em coleções do tipo `IEnumerable` ou `IQueryable` sem precisar materializar os dados antes. O LINQ trabalha de forma diferida, o que significa que ele só avalia a consulta no momento em que você realmente precisa do resultado. Então, se sua fonte de dados suportar essa operação (como consultas de banco usando Entity Framework, por exemplo), você pode usar o `CountBy` direto, sem precisar do `ToList()`. Só use o `ToList()` se for realmente necessário!

Ótima pergunta, Leonardo! No caso do Fixed Window, por padrão, ele limita de forma global (independente da origem). Porém, é possível personalizar o comportamento para limitar por IP ou qualquer outro identificador, utilizando os PartitionKey no middleware de Rate Limiting. Você pode configurar isso com algo como: app.UseRateLimiter(new RateLimiterOptions { RejectionStatusCode = 429, GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, string>(context => { // Aqui você pode usar o IP como chave var clientIp = context.Connection.RemoteIpAddress?.ToString() ?? "unknown"; return RateLimitPartition.GetFixedWindowLimiter(clientIp, _ => new FixedWindowRateLimiterOptions { PermitLimit = 10, // Limite de requisições Window = TimeSpan.FromMinutes(1), QueueProcessingOrder = QueueProcessingOrder.OldestFirst, QueueLimit = 2 // Quantidade de requisições na fila }); }) }); Com essa abordagem, você consegue controlar o Rate Limiting baseado no IP de quem faz as requisições. Se precisar de mais detalhes, só avisar!

A diferença entre lock e Semaphore está na forma como eles controlam o acesso a recursos compartilhados: lock é como uma fila de acesso exclusivo: só uma thread por vez pode entrar na "área protegida". É simples e ideal para situações onde você precisa evitar que várias threads mexam no mesmo recurso ao mesmo tempo, garantindo exclusividade total. Já o Semaphore funciona como um controle de acesso com limite. Ele permite que várias threads entrem ao mesmo tempo, mas dentro de um número máximo definido. Por exemplo, se você quer permitir até 3 acessos simultâneos a um recurso, o Semaphore gerencia isso pra você. Resumindo: Use lock quando precisa que apenas uma thread execute algo de cada vez. Use Semaphore quando quer limitar o número de acessos simultâneos, mas permitindo que mais de uma thread trabalhe ao mesmo tempo.

Acredito que outra diferença também é que não tem como usar funções assíncronas dentro do Lock. Já no Semáforo, isso é possível

Ótima pergunta! Configurar PermitLimit e QueueLimit para proteger uma rota de autenticação contra ataques DDoS é crucial no mundo real. PermitLimit define o número máximo de requisições simultâneas que podem ser processadas. Para uma rota sensível como autenticação, é recomendado ajustar esse número com base na capacidade do seu servidor e no tráfego típico. Por exemplo, se seu servidor consegue lidar com 100 requisições simultâneas sem degradação, um PermitLimit de 50-70 pode ser razoável, garantindo alguma margem de segurança. QueueLimit especifica quantas requisições podem ser enfileiradas antes de serem descartadas. Aqui, a ideia é permitir alguma flexibilidade, mas sem sobrecarregar o sistema. Valores entre 20-50 podem funcionar bem, dependendo de quanto atraso você pode tolerar antes de descartar requisições. Estratégia Completa: Além dessas configurações, é importante também usar um rate limiter baseado em IP ou tokens para proteger ainda mais a rota. Considere adicionar serviços de firewall na camada da API ou serviços como Cloudflare para mitigar picos repentinos de tráfego malicioso. Esses números são exemplos gerais; ajustes específicos devem ser feitos conforme testes de carga e as necessidades de seu sistema.

Oi Daniel! O HangFire oferece uma versão gratuita que você pode usar sem limitações de tempo, mas existem algumas diferenças importantes entre a versão gratuita (Community) e as versões pagas (Pro e Enterprise). A versão gratuita é ótima para começar, especialmente se você estiver desenvolvendo projetos pessoais ou aplicações que não precisam de recursos avançados, como o suporte a filas distribuídas ou o dashboard aprimorado. As versões pagas, por outro lado, oferecem funcionalidades como maior escalabilidade, suporte técnico direto, e otimizações de desempenho que são úteis para aplicações empresariais ou de alta carga. Se precisar de funcionalidades mais robustas ou suporte profissional, você pode optar por uma das versões pagas. Portanto, você pode começar gratuitamente e expandir conforme suas necessidades crescem. Espero que isso tenha esclarecido!

@@DjesusNet Esclareceu sim, obrigado. Parabéns pelo vídeo!

Patrick, ótima observação! A utilização de atributos como `[Required(ErrorMessage="é obrigatório")]` realmente é uma abordagem válida e funciona bem em cenários de validação simples. No entanto, em sistemas que demandam validações mais complexas, o **Fluent Validation** traz uma flexibilidade maior, pois permite definir regras condicionais, validações em cadeias, e até mesmo reutilizar regras entre diferentes contextos. Além disso, com o Fluent, conseguimos separar as preocupações de validação da modelagem dos objetos, o que pode tornar o código mais limpo e fácil de manter em longo prazo, especialmente em projetos maiores. Cada abordagem tem seu espaço, e a escolha depende muito da complexidade e da escalabilidade do projeto.

Bora fazer

Sim, Paulo !

Borá , fique a vontade de me add no LinkedIn ;)

Opa , tem no meu Médium ;)

Vende mercado livre , tudo encontra no GitHub

Não

Tmj

Obrigado ! Poderia compartilhar o código para que eu possa dar uma olhada?

Vou lançar um em breve ;)

@@DjesusNet Maravilha! Me inscrevi e estarei no aguardo. É muito difícil encontrar materiais aprofundados de C# no Brasil.