Middleware de Verdade

type Middleware func(http.Handler) http.Handler

func Chain(final http.Handler, middlewares ...Middleware) http.Handler {
	// Envolve de trás para frente; o primeiro fica por fora.
	for i := len(middlewares) - 1; i >= 0; i-- {
		final = middlewares[i](final)
	}
	return final
}

Uma requisição chega a uma API como uma encomenda numa portaria. Antes de alcançar a pessoa destinatária, alguém registra a entrada, confere a autorização e aplica regras do prédio. Na saída, o caminho se repete ao contrário: a entrega termina, o tempo é registrado e o resultado volta ao visitante. Se cada apartamento repetir essas etapas, uma mudança de regra exige editar todos eles. Se a portaria concentra as regras comuns, cada apartamento cuida só do seu trabalho.

Em net/http, o contrato que permite construir essa portaria é http.Handler. Qualquer valor com ServeHTTP(http.ResponseWriter, *http.Request) é um handler. O endpoint final implementa o contrato; um middleware recebe esse handler e devolve outro handler com comportamento adicional. A assinatura conceitual é func(http.Handler) http.Handler. Não há protocolo secreto nem framework: há funções compondo valores que satisfazem uma interface pequena.

A palavra envolver descreve melhor que “executar antes”. Um middleware pode agir antes de next.ServeHTTP, depois dele ou nos dois momentos. Autenticação costuma decidir antes e interromper o fluxo quando a credencial falha. Logging anota dados antes, delega e registra o resultado depois. Recovery instala um defer antes, mas só trabalha depois de um panic. Pensar em camadas explica todos esses comportamentos sem exceções artificiais.

A ordem importa. Em Chain(handler, auth, logging), a leitura desejável é da esquerda para a direita: a requisição passa por auth, depois logging, depois handler. A resposta retorna por logging e por auth. Para produzir essa estrutura, a montagem acontece de trás para frente. Primeiro logging(handler); depois auth(resultado). Percorrer para frente inverteria a promessa da API e criaria bugs difíceis de notar, especialmente quando um logger deveria registrar também as rejeições de autenticação.

O risco principal é quebrar a delegação. Um middleware que esquece next.ServeHTTP encerra a requisição naquele ponto. Isso pode ser correto para uma guarda que escreveu 401, mas é defeito numa camada de header ou log. Chamar next duas vezes executa efeitos duplicados. Escrever o status antes de delegar também fecha uma decisão que talvez pertencesse ao endpoint. Cada camada deve declarar com precisão quando interrompe, quando delega e qual parte da resposta observa.

O benefício aparece no trabalho seguinte: você testa uma camada em memória com httptest, combina funções pequenas e aplica a mesma política a um ServeMux inteiro. As próximas aulas acrescentam logging, recovery, limite e autenticação sem alterar os handlers de negócio. A chain deixa visível a política de entrada da aplicação.