O que é Middleware (Ciclo de Vida da Requisição)?

Middleware é uma função no pipeline de requisições que inspeciona ou modifica requisições e respostas antes de a lógica da rota rodar. Dois sentidos dividem a palavra — o sentido corporativo mais antigo (message brokers e barramentos de integração entre aplicações) e o sentido de framework web que este verbete cobre: funções dentro de uma aplicação pelas quais toda requisição flui, em ordem. O Express enuncia o modelo sem rodeios: um app “é essencialmente uma série de chamadas de funções de middleware” — e a ordem dessas chamadas é, bem literalmente, o programa.

Principais pontos

O stack, em ordem

// JavaScript / Node.js — Express + Parse Server
// Middleware: functions the request flows through, in registration order
const app = express();
app.use(helmet());                       // 1 · security headers
app.use(cors(corsOptions));              // 2 · CORS before anything that fails
app.use(express.json({ limit: '1mb' })); // 3 · body parsing, bounded

// Parse Server IS middleware — a whole backend mounted into the stack
app.use('/parse', new ParseServer(config).app);

app.use(notFoundHandler);                // 404 — after all routes
app.use(errorHandler);                   // error handler LAST (4 args)

// Flutter / Dart — Back4app Flutter SDK
// One SDK call — and the platform's middleware stack ran the gauntlet:
final response =
    await QueryBuilder<ParseObject>(ParseObject('Post')).query();
// Before your query touched data, the request passed through:
//   security headers → CORS → body limits → key check → session auth
//   → rate limiting → routing → (your beforeFind trigger) → the database
// You wrote none of it — that's the middleware a BaaS runs for you.

// iOS / Swift — Back4app Swift SDK
// One SDK call — and the platform's middleware stack ran the gauntlet:
let posts = try await Post.query().find()
// Before your query touched data, the request passed through:
//   security headers → CORS → body limits → key check → session auth
//   → rate limiting → routing → (your beforeFind trigger) → the database
// You wrote none of it — that's the middleware a BaaS runs for you.

// Android / Kotlin — Back4app Android SDK
// One SDK call — and the platform's middleware stack ran the gauntlet:
val posts = ParseQuery.getQuery<ParseObject>("Post").find()
// Before your query touched data, the request passed through:
//   security headers → CORS → body limits → key check → session auth
//   → rate limiting → routing → (your beforeFind trigger) → the database
// You wrote none of it — that's the middleware a BaaS runs for you.

Cada posição tem um porquê: headers de segurança primeiro (precisam estar em toda resposta, inclusive nos erros); CORS antes de qualquer coisa que possa falhar (ou os navegadores mascaram o erro real); parsing de body limitado e antes das rotas (ou req.body fica undefined); autenticação antes de autorização (permissões checadas contra ninguém são permissões concedidas a qualquer um); rate limiting antes do trabalho caro (um limitador depois da query ao banco não protege nada); o 404 depois de todas as rotas; o handler de erro por último, sem exceção.

A cebola, desenhada corretamente

A metade que a maioria das explicações omite: o pipeline roda nos dois sentidos. A documentação do Django o desenha como uma cebola — cada middleware é uma camada em volta da view no núcleo — e o código depois da chamada a next() (ou depois de get_response) roda no caminho de volta da resposta, em ordem inversa. É ali que o tempo de resposta é medido, que os headers são carimbados e que o logging registra o que de fato aconteceu. Uma camada que faz short-circuit não pula só o handler; pula as duas metades de toda camada interna — que é exatamente a garantia que um portão de auth existe para dar.

Bugs de ordem que vão para produção

O conselho genérico é “a ordem importa”; os bugs específicos ensinam mais. Autorização antes de autenticação: a checagem de permissão roda contra um principal anônimo — 401s/403s intermitentes, nenhuma exceção em lugar algum, horas de debugging. Body parser depois das rotas: todo handler vê req.body === undefined e culpa o cliente. Auth antes de CORS: o navegador bloqueia a própria resposta 401 por falta de headers CORS, e o frontend vê um erro de rede em vez do erro real. Arquivos estáticos antes de auth: arquivos privados servidos alegremente aos não autenticados. Handler de erro que não é o último: erros lançados depois da posição dele no stack nunca chegam até ele. Cada um desses passa em um smoke test no caminho feliz — bugs de ordem são o tipo que vai para produção.

Short-circuit: quando não chamar next() é o objetivo

O contrato tem duas saídas legais: passar o controle adiante, ou encerrar o ciclo. Encerrá-lo cedo não é uma falha do middleware — é metade do trabalho dele: o 401 do portão de auth, o 429 do limitador, o cache hit, o redirect, o preflight de CORS respondido na hora. A regra que mantém as duas saídas honestas: sempre faça exatamente uma — responda, ou chame next(). Não fazer nenhuma pendura a requisição para sempre; fazer as duas lança erros de headers-already-sent que confundem todo mundo rio abaixo.

A mesma ideia em todo framework

Um modelo, quatro sotaques. O caminho de erro ganha sua própria convenção por framework — a assinatura de quatro argumentos (err, req, res, next) do Express é o mecanismo de registro, e é por isso que apagar um parâmetro “não usado” transforma silenciosamente o handler de erro em um middleware comum que nunca dispara.

Middleware vs. gateways vs. hooks

Três camadas de interceptação, um aninhamento: o gateway fica na frente da frota, o middleware roda a esteira de cada app, e os hooks disparam onde requisições viram dados. Uma preocupação pertence à camada mais externa capaz de decidi-la — rate limits globais no gateway, auth de sessão no middleware, “essa gravação é válida?” no hook.

Casos de uso comuns

• Autenticação e gestão de sessão — estabelecer identidade uma vez, cedo, para tudo que vem depois.
• Higiene transversal — CORS, headers de segurança, compressão, IDs de requisição.
• Disciplina de entrada — parsing de body com limites de tamanho, enforcement de content-type, validação.
• Observabilidade — logging e timing envolvendo o pipeline inteiro pelo caminho de volta da cebola.
• Proteção de tráfego — rate limits e portões antiabuso que fazem short-circuit antes de o custo ser incorrido.

Em qual camada isso pertence? Matriz de decisão

Limitações e trade-offs

• A ordem é invisível até deixar de ser. O stack se lê de cima para baixo, mas falha apontando para todo canto; trate o registro de middleware como código revisado e estrutural.
• Toda camada taxa toda requisição. Dez middleware de 2 ms cada são 20 ms em toda resposta; meça o stack como você mede queries.
• Estado global é uma armadilha. Middleware roda concorrentemente entre requisições; qualquer coisa mutável compartilhada vira uma corrida — anexe dados por requisição ao objeto da requisição, e em nenhum outro lugar.
• Pipelines escondem o fluxo de controle. Uma camada com short-circuit três níveis abaixo pode ser o motivo de uma rota “nunca rodar”; o movimento de debugging é sempre o mesmo: imprima o stack, em ordem.
• Nem tudo é preocupação de pipeline. Lógica de negócio contrabandeada para o middleware acopla toda rota a ela; o pipeline é para preocupações transversais, não centrais.

Middleware no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. A relação aqui é excepcionalmente literal: o servidor do Back4app é, ele próprio, middleware do Express — a aba de JavaScript o mostra montado com app.use('/parse', …) em um stack padrão — e a plataforma roda a esteira canônica para toda requisição: headers de segurança, CORS, parsing limitado, checagem de chaves, autenticação de sessão e rate limits, na ordem certa, mantidos como infraestrutura. Sua lógica por requisição vai então para onde a matriz de decisão aponta, em vez de para código de pipeline artesanal: triggers beforeSave/beforeFind para regras junto aos dados, Cloud Functions para operações — cada um com o contexto do usuário da requisição anexado, que é a maior parte do que um middleware customizado sempre quis saber.