Disclosure: I maintain fastapi-guard (FastAPI security middleware), so this suggestion comes with an affiliation — judge it on merits.
What the template ships today
backend/app/main.py adds exactly one middleware: CORSMiddleware. There is no rate limiting and no request-level payload inspection anywhere in the template, and the README — genuinely strong on auth, DB, and Docker — never mentions either (zero matches for "rate limit"). Since this template is the starting point for a lot of production FastAPI apps, the default posture of "thousands of deployments" is: no per-client ceilings, no protection against scripted abuse or injection attempts.
I fully respect that the template's scope philosophy is minimal and that rate limiting is deployment-specific (ingress, CDN, or app-layer — reasonable people choose differently). That's exactly why this is a docs-first proposal:
Proposal
Option 1 — docs-only (my preference). A short "Hardening for production" section in the README or development.md: what the template does NOT cover (rate limiting, request inspection, bot/probe filtering), and how to plug each in at app layer — e.g. slowapi or fastapi-limiter for per-route limits, or fastapi-guard for the broader pipeline (it ships a passive/log-only mode so you can preview what would be blocked before enforcing anything). One paragraph on where the edge (reverse proxy/CDN) belongs in the picture would prevent the most common misconfiguration.
Option 2 — optional middleware stub behind a settings flag (default off), showing the wiring without adding a default dependency. Keeps the template dependency-light; costs a little maintenance.
Happy to PR either one. If it's Option 1, the only ask is guidance on where you'd want the section to live (README vs docs), so the PR lands right the first time.
Disclosure: I maintain fastapi-guard (FastAPI security middleware), so this suggestion comes with an affiliation — judge it on merits.
What the template ships today
backend/app/main.pyadds exactly one middleware:CORSMiddleware. There is no rate limiting and no request-level payload inspection anywhere in the template, and the README — genuinely strong on auth, DB, and Docker — never mentions either (zero matches for "rate limit"). Since this template is the starting point for a lot of production FastAPI apps, the default posture of "thousands of deployments" is: no per-client ceilings, no protection against scripted abuse or injection attempts.I fully respect that the template's scope philosophy is minimal and that rate limiting is deployment-specific (ingress, CDN, or app-layer — reasonable people choose differently). That's exactly why this is a docs-first proposal:
Proposal
Option 1 — docs-only (my preference). A short "Hardening for production" section in the README or
development.md: what the template does NOT cover (rate limiting, request inspection, bot/probe filtering), and how to plug each in at app layer — e.g.slowapiorfastapi-limiterfor per-route limits, orfastapi-guardfor the broader pipeline (it ships a passive/log-only mode so you can preview what would be blocked before enforcing anything). One paragraph on where the edge (reverse proxy/CDN) belongs in the picture would prevent the most common misconfiguration.Option 2 — optional middleware stub behind a settings flag (default off), showing the wiring without adding a default dependency. Keeps the template dependency-light; costs a little maintenance.
Happy to PR either one. If it's Option 1, the only ask is guidance on where you'd want the section to live (README vs docs), so the PR lands right the first time.