À primeira vista, o Proxy parece o Decorator do artigo anterior de bigode: um objeto com a mesma interface embrulhando outro. O desenho é irmão; a intenção é oposta. O Decorator soma comportamentos ao objeto; o Proxy controla o acesso a ele: decide se, quando e como a chamada chega ao objeto real. Essa diferença de intenção gera uma família de usos próprios.

As quatro caras do Proxy

1. Proxy virtual: adiar o caro. O objeto real custa criar (conexão, arquivo gigante, modelo de ML na memória)? O proxy se apresenta no lugar e só materializa o real no primeiro uso:

class RelatorioPesadoProxy implements Relatorio {
  private real?: RelatorioPesado;

  async gerar(filtros: Filtros) {
    this.real ??= await RelatorioPesado.carregar(); // só agora, se precisar
    return this.real.gerar(filtros);
  }
}

É o lazy loading que os ORMs fazem por baixo dos panos: aquele pedido.cliente que dispara uma query na primeira leitura é um proxy, e entender isso explica tanto a mágica quanto os N+1 que ela esconde.

2. Proxy de proteção: o porteiro. Verifica permissão antes de deixar a chamada passar:

class DocumentosProtegidos implements Documentos {
  constructor(private interna: Documentos, private usuario: Usuario) {}

  async excluir(id: string) {
    if (!this.usuario.pode("documentos:excluir")) {
      throw new AcessoNegado(this.usuario.id, "documentos:excluir");
    }
    return this.interna.excluir(id);
  }
}

A autorização sai de dentro da lógica de negócio e vira camada explícita, testável isolada, e impossível de esquecer num método novo (o nº 1 do OWASP agradece).

3. Proxy remoto: o longe parecendo perto. O objeto local que representa um serviço do outro lado da rede: stubs de gRPC, clients de SDK. E o alerta clássico da computação distribuída: o proxy remoto esconde a rede, mas a rede continua lá, com timeout, retry e falha parcial que a interface bonita não mostra.

4. Proxy de cache/registro: intercepta para memorizar ou auditar. (Sim, a fronteira com o Decorator fica borrada aqui: a distinção honesta é a intenção: controlar o acesso vs enriquecer o comportamento. Não perca sono com a taxonomia; perca com o desenho.)

O Proxy que a linguagem te dá

O JavaScript tem o padrão embutido como recurso: o objeto Proxy intercepta operações de outro objeto (leitura, escrita, chamada):

const config = new Proxy(configReal, {
  get(alvo, chave) {
    if (!(chave in alvo)) throw new Error(`Config inexistente: ${String(chave)}`);
    return alvo[chave];
  },
});

config.databaseUrl;  // ok
config.databseUrl;   // 💥 erro na hora, não undefined silencioso

É assim que o Vue implementa reatividade e que bibliotecas de mock interceptam chamadas: os Signals do Angular e afins são primos conceituais dessa interceptação.

E na arquitetura, você já vive cercado deles

Reverse proxy (nginx), API Gateway, service mesh, RDS Proxy, CDN: o padrão em escala de infraestrutura: um intermediário com a mesma "interface" (HTTP, protocolo do banco) controlando acesso, cacheando e protegendo. O conceito é o mesmo do objeto; muda o tamanho.

A régua de uso

Use quando o controle de acesso é transversal e esquecível (proteção), o custo de criação merece adiamento (virtual), ou a distância precisa de representação local (remoto). Evite quando é indireção sem decisão: proxy que só repassa tudo é camada de cerimônia, e proxy demais na pilha faz o depurador chorar.

No próximo artigo da série: o Observer, o padrão por trás de todo evento que você já disparou. Aplicar esse catálogo com intenção é parte do olhar do nosso serviço de Arquitetura de Software.

Sua autorização está espalhada por 40 ifs dentro do domínio? Descreva para a IA da Rabelo Digital, aqui no canto da tela, e ela desenha o proxy de proteção equivalente. Sem formulário, sem espera.

---

Leia também

• Observer: o padrão por trás de todo evento
• Adapter: contratos incompatíveis conversando
• Factory Method: criando objetos sem se acorrentar