Security

Every public API needs rate limiting. Without it, one misbehaving client can take down your entire service—whether through malice, bugs, or just enthusiasm. Rate limiting protects your infrastructure, ensures fair usage, and creates predictable behavior for all clients. The Core Algorithms Fixed Window Count requests in fixed time intervals (e.g., per minute): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 class FixedWindowLimiter { constructor(redis, limit, windowSeconds) { this.redis = redis; this.limit = limit; this.windowSeconds = windowSeconds; } async isAllowed(clientId) { const window = Math.floor(Date.now() / 1000 / this.windowSeconds); const key = `ratelimit:${clientId}:${window}`; const count = await this.redis.incr(key); if (count === 1) { await this.redis.expire(key, this.windowSeconds); } return count <= this.limit; } } Pros: Simple, memory-efficient. Cons: Burst at window boundaries. Client could hit 100 requests at 0:59 and 100 more at 1:00. ...

The Twelve-Factor App says store config in environment variables. That was good advice in 2011. For secrets in 2026, we need more. Environment variables work until they don’t: they appear in process listings, get logged accidentally, persist in shell history, and lack rotation mechanisms. For API keys and database credentials, we need purpose-built solutions. The Problems with ENV Vars for Secrets Accidental exposure: 1 2 3 4 5 # This shows up in ps output DB_PASSWORD=secret123 ./app # This gets logged by accident console.log('Starting with config:', process.env); No rotation: Changing a secret means redeploying every service that uses it. During an incident, that’s too slow. ...