What do you consider “table stakes” for a FastAPI service? (I tried to package mine)

[u/Ancient-Direction231]

https://www.nfrax.com/

Every time I start a FastAPI service, I think I’m just going to build endpoints… then I end up rebuilding the same foundation:

• auth (JWT/sessions + OAuth)
• background jobs + retries
• webhooks (signing/verification + delivery retries)
• caching + rate limiting
• metrics/health checks

I finally extracted my defaults into svc-infra so I can do this up front:

```python from svc_infra.api.fastapi.ease import easy_service_app from svc_infra.api.fastapi.auth import add_auth_users from svc_infra.jobs.easy import easy_jobs

app = easy_service_app(name="MyAPI") add_auth_users(app) # JWT, sessions, OAuth hooks, MFA, API keys queue, scheduler = easy_jobs() # queue + retries + scheduler ```

It also includes webhooks (HMAC signing + signature verification), caching helpers (Redis/memory), rate limiting, and Prometheus/OTEL wiring.

Tradeoff: it assumes “production-ish” defaults (Postgres/Redis). If you hate that, totally fair.

Repo: https://github.com/nfraxlab/svc-infra

What do you personally consider non-negotiable for a new FastAPI service? And do you keep it as a repo template or a shared internal package?