.NET

10 jan, 2019

Compressão de respostas em APIs ASP.Net Core

100 visualizações
Publicidade

Quando estamos desenvolvendo nossas APIs, é muito importante nos preocuparmos com o tráfego de mensagens que ela irá gerar, pois largura de banda é um recurso limitado e não podemos esperar que nossos clientes poderão contar com conexões de banda larga via fibra ótica a todo momento, ou ainda conexões 4G ultra velozes sem limites de dados – infelizmente essa não é a nossa realidade ainda.

O que podemos fazer é reduzir o tamanho das respostas em nossas APIs, e isso tem um impacto muito grande, tanto financeiro, quanto em performance.

Lembre-se de que a grande maioria dos players de nuvem, ou todos eles, cobram por tráfego de dados, e além de tentar reduzir o custo, devemos concordar que quanto menor for o tamanho dos dados, mais rápida será a resposta para quem estiver consumindo nossas APIs, e assim melhorando a performance de nosso sistema de uma forma geral.

Uma maneira de diminuir o tamanho das mensagens trafegadas é implementando um mecanismo de compressão de respostas.

A compressão de respostas pode ser feita diretamente nos servidores web como o IIS e Nginx – só para citar alguns. Já o Kestrel e o HTTP.sys não possuem esse recurso nativamente até o momento em que escrevo esse artigo.

Middleware de compressão de respostas do ASP.Net Core

O ASP.Net Core conta com alguns middlewares muito úteis, e um deles serve justamente para comprimir as respostas de nossas APIs.

Para isso, basta adicionarmos uma referência ao pacote nuget Microsoft.AspNetCore.ResponseCompression e seguir os trechos de código abaixo:

public class Startup
{
	public Startup(IConfiguration configuration)
	{
		Configuration = configuration;
	}

	public IConfiguration Configuration { get; }

	public void ConfigureServices(IServiceCollection services)
	{
		services.AddResponseCompression();
		services.AddMvc();
	}

	public void Configure(IApplicationBuilder app, IHostingEnvironment env)
	{
		if (env.IsDevelopment())
		{
			app.UseDeveloperExceptionPage();
		}

		app.UseResponseCompression();
		app.UseMvc();
	}
}

O que fizemos foi a chamada de dois métodos bem específicos, nas linhas 12 e 23. Esses métodos de extensão são disponibilizados quando referenciamos o componente mencionado acima.

  • Linha 12: foi adicionado o método “services.AddResponseCompression()”, que é responsável por adicionar o serviço de compressão de respostas no injetor de dependências nativo do ASP.Net Core.
  • Linha 23: foi adicionado o método “app.UseResponseCompression()”, que adiciona o middleware de compressão de respostas no pipeline do ASP.Net Core.

Com apenas duas linhas de código, a compressão de resposta já funcionará, mas se quiser ir além, poderá customizar alguns aspectos como otimizar ainda mais a compressão, ou ainda, criar seu próprio algoritmo conforme podemos ver abaixo — os trechos de código de customização foram extraídos da documentação oficial que você encontra no final deste artigo.

Use a compressão de respostas nativa do servidor web sempre que possível, pois ela tende a ter melhor performance que o middleware de compressão.

Como funciona?

Esse middleware interceptará todos os retornos das suas controllers e usará um algorítmo de compressão para diminuir o tamanho da resposta.

Por padrão, ele usará o algorítmo Gzip. Apenas para conhecimento, existe outro algoritmo de compressão também muito famoso, chamado Deflate.

Para ver a compressão funcionando na prática, podemos fazer uma chamada à nossa API de testes com dados fake através do navegador mesmo, conforme você pode ver abaixo:

Então, através do Fiddler podemos conferir o tamanho da resposta, que neste exemplo foi de 1.143 bytes. Além disso, foi adicionado o header Content-Encoding: gzip, que indica que essa resposta foi compactada utilizando o algoritmo Gzip conforme o esperado.

Em uma requisição sem a compactação, podemos ver o tamanho da reposta em 6.174 bytes, e não existe o header Content-Encoding indicando o algoritmo de compressão.

Verificando a documentação oficial, você irá observar uma nota de atenção para não tentar comprimir arquivos menores que 1.000 bytes, pois a compressão não será eficiente. O que pode, inclusive, resultar em uma resposta com tamanho maior ao original sem a compressão, além do tempo de processamento que foi gasto.

Dessa forma, podemos perceber que com uma simples adição ao nosso pipeline do ASP.Net conseguimos comprimir a resposta de nossa API, e dessa forma reduzir o tráfego de dados de nosso serviço.

É isso, pessoal. Espero que tenham gostado, e se ficou qualquer dúvida ou se tiverem sugestões e críticas, fico à disposição para bater um papo.

Abraços!

Referências