E porque essa técnica muito legal é gambiarra.

Hoje eu vi outro post ensinando a criar uma função de debounce pra diminuir a quantidade de requisições desnecessárias.

Se você não viu, tem esse ótimo post do FreeCodeCamp ensinando.

O debounce é uma gambiarra um recurso super útil e que pode te ajudar bastante a controlar a quantidade de requisições feitas ao servidor, principalmente quando os recursos são limitados. Geralmente usado em campos de autocomplete, você espera até o usuário parar de digitar por determinado tempo (300 ou 500ms) pra fazer a requisição, assim você não faz uma requisição pra cada letra e diminui a quantidade de requests "desnecessários".

Isso faz sentido?

Hoje podemos escalar aplicações como nunca em horários de pico, e poupar grana enquanto elas não estão sendo utilizadas. A obsessão por performance do lado do backend é frequente. Será que a API não consegue resolver isso sozinha?

A resposta é: sim, deveria. Estratégias de cache, bancos em memória, indexação, e um mundo de ferramentas criadas para fornecer uma resposta super rápida sem onerar o banco principal. APIs respondendo em 50ms enquanto a gente vai lá e mete um debounce de 300ms 🤡

A experiência do usuário

Todo mundo, principalmente quem é heavy user, já passou por apps ou sistemas onde você precisa esperar um tiquinho depois de digitar pra ver os resultados. É pouco tempo, mas é irritante quando você compara com ferramentas como a busca da Amazon, Google Maps, ou outras do tipo.

Se você já colocou o delay e a API demora um pouco a mais pra responder, soma os tempos e você vai ver o usuário triste.

"Aí, travou essa *****"
– Usuário triste

Depois, abre o seu inspector e faz uma pesquisa no Google Maps pra você ver quantas requisições ele faz.

Ah, mas DDoS...

Se você confia no seu frontend pra te poupar de um DDoS, meu amigo... você tá em uma situação complicada. Acho que só outro post mesmo pra caber, mas me avisa aqui que eu faço.

Então eu não devo usar debounce?

Calma... depois de virar dev sênior, você aprende que é pago pra dizer "depende" pra tudo. E mais uma vez aqui: DEPENDE.

Se você trabalha em um frontend que consome uma API nova, e o backend não consegue dar conta de muitas requests, remove o debounce e pede pra ele consertar esse treco aí. Manda o print do inspector do site da Amazon e avisa quantas pessoas usam diariamente.

Agora, se você trabalha em um sistema legado onde a API não dá conta da quantidade de requests, ou se o chefe não deixar o backend consertar o bug, ou se vc quiser salvar dinheiro pq a API do Google Places tá comendo seu orçamento, aí sim vc usa o debounce, mas não acostuma com ele. Debounce é gambiarra, não deixa te convencerem do contrário.