Você já parou para pensar em quantos Middlewares são executados antes da sua Controller responder um simples “OK” ? Autenticação, CORS, Roteamento, Rate Limiting, Logging… e às vezes o seu endpoint nem precisa de nada disso!
Pensando nisso, o ASP.NET Core adicionou um novo atributo chamado [ShortCircuit], que faz o endpoint ser executado logo após o Roteamento, “pulando” todo o restante do pipeline de Middlewares.
Mas isto não é novidade ?
Pode parecer facil migrar um projeto não é ? Só trocar as referências no csproj e rodar uns updates no nuget, e pronto!
Façil falar, mais difícil e complexo fazer!
Cenário Temos um projeto na empresa que precisa gerar um QRCode para PIX, e para isto usamos um componente para “desenhar” o QRCode. Parece simples, até você tentar rodar isto em um container usando Linux Alpine.
Não é tão simples assim, primeiro que o Linux Alpine é extremamente enxuto e depois de algum tempo você chega a conclusão que instalar libgdiplus nele pode ser um pouco mais trabalhoso do que parece.
O que é ser resiliente ? E uma aplicação resiliente ?
Ser resiliente é saber lidar com adversidades, adaptar-se a mudancas e lidar com pressões. Mas e uma aplicação resiliente ? Basicamente é a mesma coisa, saber contornar problemas que não estão ao seu alcance, tratar erros e sobrecargas.
No cenário de aplicações web, vamos explorar um recurso que nem é tão novo assim, mas que ganhou uma nova “roupagem” nas últimas versões do .
Como você tem organizado seus projetos, dependências e o código em geral ? Está separando tudo por projeto, isolando dependências e responsabilidades ?
Se não está, veja aqui um jeito simples e eficaz de organizar seu código e deixar os projetos mais claros!
Vamos considerar este projeto como exemplo:
É exemplo bem interessante de uma arquitetura Clean, com alguns projetos:
APIComIoC.API - API básica (CRUD) APIComIoC.Core - Serviços Core (podemos considerar aqui a regra do negócio) APIComIoC.
Você ja precisou ver como a consulta do EntityFramework Core é traduzida para o banco de dados ? Já teve aquela sensação de “será que a query ficou boa?”
Isto é um grande dilema para quem usa algum tipo de ORM, certo ? Você manipula classes e não tem muito controle sobre as queries que vão para o banco. Logicamente que você pode ativar algum tipo de LOG, mostrar na console, etc.
Vamos começar este artigo explicando o que é um “job”. Um job é um serviço que vai rodar de forma autônoma na nossa aplicação, sem a interferência de nenhuma chamada ou usuário, apenas respeitando uma regra básica, que pode ser um timer, um loop, etc.
Então podemos criar em uma aplicação ASP.NET, um código que é sempre executado em um determinado tempo, com um timer, e o melhor, este mecanismo é nativo da plataforma, não precisamos instalar nenhum pacote adicional.
Se você já trabalhou em um projeto onde existe um DBA então o título deste post é muito familiar para você, pois o DBA jamais vai deixar você rodar qualquer tipo de ‘coisa’ no banco de produção. Em um ambiente bem controlado, mesmo sem a presença de um DBA, isto também é uma EXCELENTE prática, afinal deixar o DEV rodar qualquer tipo de coisa no banco de produção pode ser um tanto perigoso!