You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A Vercel fornece automaticamente proteção contra DDoS nos recursos estáticos, porém ela não pode fornecer isso para as APIs por não conhecer as regras de negócio do seu serviço. E quando se fala em DDoS, quase que automaticamente se pensa em Cloudflare, porém quanto mais eu pesquisei sobre colocar o Cloudflare na frente da Vercel, mais reclamações eu encontrei sobre os recursos mais avançados do Next.js, como ISR, stale-while-revalidate e invalidação de cache dos estáticos. Caso queira se dar o trabalho de pesquisar e encontrar algo que funcione sem atrito para todos os recursos do framework, por favor responda essa issue, porque seria uma maravilha controlar tudo pelo Cloudflare.
Então uma alternativa é colocar as Edge Middleware na frente e por lá fazer o controle das requisições. Este é um recurso que distribui computação/processamento na borda (na CDN) e lá conseguimos fazer a verificação da quantidade de requests que estão acontecendo por ip. Mas para isso não gerar uma latência grande entre onde está o state e o processamento dele, o state também precisa ser distribuído globalmente e pelo que vi muita gente recomenda utilizar o Upstash, pois lá é possível criar uma instância de Redis distribuída globalmente.
Então na execução desse rate limiting, vamos configurar um limite geral de requisições contra a API, e um limite específico e muito mais baixo para certos caminhos, como por exemplo fazer um POST contra a rota /api/v1/sessions.
No banco global tanto a escrita quanto a leitura ocorrem na réplica mais próxima. No caso da gravação, instantes após já ocorre a replicação. Acontece que isso não agrega nada para a implementação de um rate-limit, então é só um custo desnecessário.
Contexto
A Vercel fornece automaticamente proteção contra DDoS nos recursos estáticos, porém ela não pode fornecer isso para as APIs por não conhecer as regras de negócio do seu serviço. E quando se fala em DDoS, quase que automaticamente se pensa em Cloudflare, porém quanto mais eu pesquisei sobre colocar o Cloudflare na frente da Vercel, mais reclamações eu encontrei sobre os recursos mais avançados do Next.js, como
ISR
,stale-while-revalidate
e invalidação de cache dos estáticos. Caso queira se dar o trabalho de pesquisar e encontrar algo que funcione sem atrito para todos os recursos do framework, por favor responda essa issue, porque seria uma maravilha controlar tudo pelo Cloudflare.Então uma alternativa é colocar as
Edge Middleware
na frente e por lá fazer o controle das requisições. Este é um recurso que distribui computação/processamento na borda (na CDN) e lá conseguimos fazer a verificação da quantidade de requests que estão acontecendo porip
. Mas para isso não gerar uma latência grande entre onde está ostate
e o processamento dele, ostate
também precisa ser distribuído globalmente e pelo que vi muita gente recomenda utilizar o Upstash, pois lá é possível criar uma instância de Redis distribuída globalmente.Então na execução desse rate limiting, vamos configurar um limite geral de requisições contra a API, e um limite específico e muito mais baixo para certos caminhos, como por exemplo fazer um
POST
contra a rota/api/v1/sessions
.Execução
/api/v1/sessions
#635POST
,PATCH
eDELETE
#656The text was updated successfully, but these errors were encountered: