Lovablefeatureintermediate
Add Rate Limiting to Lovable App
Add rate limiting to Edge Functions with 429 handling, sliding window, and cleanup.
What you'll get
Rate limiting on Edge Functions with sliding window, 429 responses, and automatic cleanup.
The Prompt
Add rate limiting to my Lovable app's Edge Functions. REQUIREMENTS: 1. Create a rate limiting utility that tracks requests per IP or user ID using a Supabase table. 2. Implement sliding window rate limiting: allow N requests per M-second window (e.g., 10 requests per 60 seconds). 3. Wrap existing Edge Functions with the rate limiter as middleware. 4. When rate limited, return HTTP 429 with headers: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, and Retry-After. 5. Show a user-friendly error message on the client: "Too many requests. Please try again in X seconds." 6. Add different rate limits per endpoint (e.g., auth endpoints: 5/min, API endpoints: 30/min, public endpoints: 60/min). 7. Create a cleanup function that runs periodically to delete expired rate limit entries. 8. Log rate limit hits for monitoring abuse patterns. DATABASE: - "rate_limits" table: id, identifier (IP or user_id), endpoint, request_count, window_start, created_at - Index on (identifier, endpoint, window_start) for fast lookups. - Consider using pg_cron for automatic cleanup of old entries. SECURITY: - Use IP-based limiting for unauthenticated endpoints. - Use user-based limiting for authenticated endpoints. - Don't expose internal rate limit logic to clients.
Replace these variables
| Variable | Replace with |
|---|---|
| [RATE_LIMITS] | Limits per endpoint (e.g., auth: 5/min, api: 30/min) |
Tips for best results
Start with generous limits and tighten based on actual usage patterns.
Always include Retry-After headers so clients know when they can try again.
Follow-up prompts
Add IP blocking
Add the ability to permanently block specific IP addresses from the admin dashboard. Store blocked IPs in a "blocked_ips" table.