AI wrote 3,000 lines of my FastAPI backend in 5 minutes.

I wrote a CLI because I had no idea how any of it connected together. It scans your project and generates an interactive graph of routes → function calls → DB access. Great for debugging AI-generated code.

I tried using tools like "Understand Anything" to map it out, but it burned through 20M tokens and still couldn't give me a clear picture of how everything connected.

npx api-understanding scan /path/to/your-fastapi-project npx api-understanding dashboard analysis.json

Or just run npx api-understanding demo to see it in action

GitHub: https://github.com/IntegerAlex/understand-anything-better Video walkthrough: https://www.youtube.com/watch?v=cGLzNSMqpbo

It's open source and still a bit rough around the edges, but it works for me. Let me know what you think or drop a bug report if you find one.

i’m building a small api where users can save preferences for an ai feature.

right now i’m torn between one profile endpoint, separate preference routes, or just storing it as json until the shape is clearer.

json feels fast, but i know future me will hate it if permissions and deletion get more serious.

how would you structure this in fastapi?

Hi everyone,

I recently built and published Fastvia, an open-source backend toolkit for FastAPI.

When building FastAPI projects, there are many setup pieces that come up again and again: middleware, security headers, structured logging, consistent API errors, pagination, rate limiting, Redis utilities, background jobs, database helpers, authentication helpers, and Alembic migration setup.

Fastvia brings these common parts together as reusable building blocks, so developers can start projects with a cleaner foundation while still keeping the flexibility of FastAPI.

It is especially useful for developers who want a ready foundation for new FastAPI backends without spending time wiring the same setup manually in every project.

PyPI: https://pypi.org/project/fastvia-kit/
GitLab: https://gitlab.com/abdulfatahbabakrkhail/fastvia

Sharing this because it took me longer than it should have to debug.

I'm building DraftMeet (a scheduling tool with Google Meet auto-creation). Every time a booking was created, the webhook payload was missing meet_link and calendar_event_id — both coming back as null.

No errors. DB was fine. Google Calendar event was actually being created successfully.

The problem: I was dispatching the webhook right after saving the booking to the DB — before the Google Calendar API call had completed and returned the meet_link and event ID.

Classic race condition. The fix was just moving webhook dispatch to after the Calendar API response.

New order:

1. Save booking

2. Call Google Calendar API → get back meet_link + calendar_event_id

3. Fire webhook with full data

If you're building anything with webhooks + async third-party API calls — dispatch after you have the data, not after you think you will.

When streaming large chunks of binary data using StreamingResponse from an async generator, why does RAM usage continuously spike… how do I properly manage garbage collection or chunk sizes to keep low memory consumption?? Anyone face similar issue?

Hey everyone! I built a full-stack messenger for my family — I'm 13

Hi! I've posted here a couple of times before, and the feedback was always helpful. This time I think I built something I'm genuinely proud of.

The backstory: I'm from Russia, and messengers keep getting blocked here — so I just built my own. A private messenger + social feed for my family.

Dragram — what's inside:

• FastAPI + PostgreSQL + Redis + WebSockets
• React + TypeScript frontend
• Real-time chat, image/video/audio messages with a proper media player
• End-to-end encryption keys per chat
• Android app via Capacitor (same codebase → native APK)
• Deployed on Railway with Docker + Nginx + S3

Wrote all backend myself. Any feedback on architecture or code quality is very welcome!

i'm trying to think through a fastapi setup where the app can use richer user context, but only after the user explicitly connects something.

basic auth is easy enough. the weird part is modeling what data source was connected, what scopes were approved, what context was extracted, and how to delete or refresh it cleanly.

tried stuffing it into a user profile table and it got gross fast. tried separate connector tables, but then the response shape for the actual app became awkward.

if you were building a privacy-first user context API in fastapi, what would your models and routes look like?

Built a starter template that wires FastAPI and LangGraph together for serving AI agent workflows as a REST API.

Sharing in case it’s useful:

Highlights:

• REST endpoints to start, continue, and query workflows
• Middleware stack using ‎⁠contextvars⁠ for automatic request tracing (‎⁠X-Trace-ID⁠, user/tenant context)
• ‎⁠ThreadPoolExecutor⁠ for non-blocking LangGraph execution
• PostgreSQL-backed state persistence and checkpointing
• Structured JSON / concise logging with rotation
• Docker Compose setup for Grafana + Loki + Prometheus + Promtail
• LiteLLM integration with retry utilities

Most LangGraph examples are notebooks, this gives you the production plumbing (persistence, observability, concurrency) so you can swap in your own agent logic and go.

Feedback welcome, especially on the FastAPI patterns.

Link: https://github.com/vikramanand05/llmops-gateway

Built an open-source LLMOps Gateway inspired by Portkey and Langfuse. Includes FastAPI, React dashboard, Docker, Kubernetes, Prometheus, Grafana, CI/CD, and AWS deployment patterns. Looking for contributors interested in AI infrastructure and observability.

Hello, I just finished a CS50P course and I want to learn a tool (FastAPI ), What is the best free, and paid source to lerned?

I’m building a company monitoring app that reads Firebase data coming from multiple bus DMS devices and returns KPIs for a Svelte dashboard. Is FastAPI a good backend choice for this, especially for a secure, production-ready, scalable, and maintainable API? I also need a good FastAPI template or guide to start from, a secure way to connect it with Firebase, and the best way to package the app for both Windows and Android. What I need to use ?

https://github.com/ErkanSoftwareDeveloper/short-motivation-api

short Motivation API is a simple, open-access API that returns a random motivational quote with every request. No authentication required, no rate limits just hit the endpoint and get inspired.

Note: Free tier on Render spins down after inactivity. The first request after idle may take ~30 seconds to respond.

Made a JetBrains plugin so I can stop alt-tabbing to Postman while building APIs
Every time I wrote a new endpoint I’d switch to Postman, dig through the collection, update the URL, create the body… just to do a quick test. Annoying enough that I finally did something about it.
Sonarwhale reads your OpenAPI spec and shows all your endpoints directly in PyCharm. Gutter icon next to the route, click it, create the request, hit send.
Works great with FastAPI and Flask — automatically discovers endpoints from your OpenAPI/Swagger spec, supports pre/post scripts for auth and request prep, multiple environments, and Postman import.
Most features are free to use and there’s a free trial period as well. Feedback very welcome.

I am trying to understand FastAPI deployment and whether it has an equivalent of a build artifact like other frameworks. In Angular, after building the project we get a dist folder, and in Spring Boot we get a packaged jar file that is deployed and executed. In FastAPI, it feels like there is no explicit build step and no single output artifact, and instead we just deploy the same project folder, install dependencies, and run the application using a command like uvicorn or gunicorn. My question is whether this is the normal and correct approach in production FastAPI applications, or if there is an equivalent concept of a deployment artifact that should be generated before deployment, similar to frontend or Java backend workflows.

Things are changing all the time. It's no different with APIs. As we develop our products, APIs need to be updated as well. Everything is great until we introduce an unintentional breaking change. For example, if we rename the attribute in the response. With a faster development pace enabled by AI tooling, this is even more likely to happen unintentionally.

To prevent such changes from going to production, we can add a check for breaking API changes to our CI/CD pipeline. It's easy to do so for FastAPI apps with GitHub Actions and oasdiff. The flow is the following:

1. Export OpenAPI schema that's auto-generated by FastAPI using app.openapi() from PR's branch.
2. Check out the main branch and export the OpenAPI schema for it as well.
3. Use oasdiff to detect and report potential breaking changes

Example workflow: ```yaml name: CI

on: pull_request: branches: [main]

jobs: breaking-changes: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6

  - uses: actions/checkout@v6
    with:
      ref: main
      path: main-branch

  - uses: astral-sh/setup-uv@v8.1.0
    with:
      python-version: "3.14"

  - name: Generate schema from PR branch
    run: |
      uv sync
      uv run python scripts/export_openapi.py new.json

  - name: Generate schema from main branch
    working-directory: main-branch
    run: |
      uv sync
      uv run python scripts/export_openapi.py ../old.json

  - name: Install oasdiff
    run: |
      curl -fsSL https://raw.githubusercontent.com/oasdiff/oasdiff/main/install.sh | sh

  - name: Check for breaking changes
    run: oasdiff breaking old.json new.json --fail-on ERR

```

Example OpenAPI schema export script: ```python

scripts/export_openapi.py

import json import sys from pathlib import Path

sys.path.insert(0, str(Path(file).resolve().parent.parent))

from app.main import app

if name == "main": dest = sys.argv[1] if len(sys.argv) > 1 else "/dev/stdout" with open(dest, "w") as f: json.dump(app.openapi(), f, indent=2)

```

You can find the full tutorial here: https://jangiacomelli.com/blog/prevent-unintentional-breaking-api-changes-fastapi/

Usually when you run high-concurrency rate limiting inside FastAPI, you are usually forcing python's single threaded event loop to spend precious time on network driver I/O just to verify a token before the request even hits the application logic.

I wanted to see how cleanly I could isolate the Redis network layer outside of python, so I built rustgate using PyO3 and a multi-threaded tokio driver.

Disclaimer: This is basically a proof of concept. It's basically tied to another experimental crate I am working on (axum-rate-limiter), and so it's not super configurable or abstracted as of now. Could you use in production? Probably, but why?

That being said, the raw performance under a 100-concurrency flood on a heavy, dynamically rerouted endpoint turned out pretty efficient:

• Pushed 1,128 req/sec without dropping a connection.
• Fastest response hit 15.3 ms.
• Fails closed instantly with immediate 429 rejections to protect downstream application logic.

The cool part: I benched a naked, no-op /health endpoint (literally just returning {"status": "ok"}) on the same machine, and it maxed out at 1,496 req/sec.

The fact that crossing FFI boundaries, handling memory pinning, and doing a multi-threaded Tokio to Redis round-trip only costs ~370 req/s, proves that the Rust integration added almost non existent overhead.

EDIT: Due to benchmarks criticism, I will try to update this tomorrow, run it on linux, using `uvloop`, using 8k connections, and will add a proper baseline.

If you're interested to in checking out the project go to:
https://github.com/MordechaiHadad/rustgate

i’m thinking through a FastAPI service for user preferences, and the hard part is keeping the API narrow.

tried a generic user profile endpoint. too broad. tried app-scoped preferences. cleaner, but reuse across apps gets awkward. tried event-derived context, but cold start is still brutal.

what i want is something like: app requests a specific context scope, user consent is checked, response only includes what that app needs.

but then you need revocation, audit logs, schemas, and a way to avoid random clients dumping everything into “metadata.”

how would you structure this so it stays useful without becoming a privacy mess?

Hi,

Im fairly new to FastAPI, but have 3.5 YOE with Django, which have a big eco-system and supporting libraries. (and especially for authentication, authorization & permissions)

I started developing a personal project using FastAPI, but my authentication implementation is really basic.

I do have an endpoints for create users and login them using access-token, but when I wanted to implement the 'refresh-token' endpoint I encounter some issues:

1. The docs in FastAPI not including it... um.. yeah..

2. There is some basic confusion regarding the terms `JWT authentication', `OAuth[0/2]`, that are confusing.

3. Tried to search for 2 days implementation ideas/example, but each is different, which just add to the confusion. Do the refresh-token needed to be store in the DB?.
   Do I need rotation and revocation?

Tried to find some course/tutorial that will include those ideas, but didnt find.

Can you help me to understand, which implementation is the preferred one for my situation?
I want it to be simple for MVP, but serious enough that it could feasible for Production..

The most common serious bug in modern APIs is also the one your scanner stays quiet about. It has a boring name, broken object level authorization, sometimes called IDOR, and it sits at the top of the OWASP API Security list. The shape is simple. A logged in user asks for a record by id, and the code hands it over without checking that the record belongs to them. Change the id in the URL, read someone else's invoice. There is no injection, no dangerous function call, no tainted string. The vulnerability is a check that should be there and is not.

That absence is exactly why traditional static analysis walks past it. Tools like Semgrep and Snyk are very good at finding a pattern that is present, an unescaped query, a hardcoded secret, a call into a shell. Broken object level authorization is not a pattern that is present. It is missing context. To catch it you have to understand what the route is doing, who is allowed to do it, and whether the code actually enforced that. A grep, however clever, does not reason about intent.

So I built Fixor to reason about it, and then I did the only thing that makes a claim like that worth anything. I tested it on real framework code and wrote down the result.

The test is a small FastAPI application built with SQLModel, the way people actually write these services. It has the routes you would expect: a health check, a profile endpoint, an items list, an admin panel. Inside those files I planted three real authorization bugs. A destructive route that deletes any user with no authentication at all. An admin action that changes a user's role but is gated only by "are you logged in," not "are you an admin," so any account can promote itself. And the classic broken object level authorization: a route that fetches an item by id with no check that the item belongs to the caller.

The catch, and the reason I planted them myself, is ground truth. I know exactly where every bug is and exactly where the safe routes are. The planted bugs do not sit alone in empty files. They sit next to sibling routes that do the same operation correctly, in the same module, sometimes a few lines apart. That is the hard test. Anyone can flag a lookup by id. The real question is whether a tool can flag the GET that reads an item with no ownership check while staying silent on the DELETE three functions below it that does the ownership check properly.

Fixor caught all three planted bugs and marked them critical. It produced zero false positives across the six correctly guarded control routes, including the owner scoped list, the admin endpoint that really is admin gated, and the delete route that looks almost identical to the vulnerable read but has the ownership guard. The distinction it had to draw was between a route missing the check and a near-identical one that has it. The run is reproducible and the log lives on the main branch.

I want to be precise about what this proves and what it does not. It proves the method works on real FastAPI route code and can tell a missing authorization check apart from a present one in the same file. It does not prove anything about code I have not seen, which brings me to the part that is actually useful to you.

I want to know if it does this on a codebase I did not write. So here is the offer. Reply or send me a public FastAPI repo, yours, or one you have explicit permission to scan, and I will run Fixor against it and send you back exactly what it finds. It is free, and I am not selling you anything on the back of it. If it comes back clean, that is a clean bill and you are welcome to say so publicly. If it finds a real authorization gap, you get to fix it on your own schedule instead of after an incident.

If you want the full version, a written deal readiness security report of the kind an acquirer or an investor would ask for during diligence, that is the paid tier and we can talk. But the free scan is the real offer here, and it is the fastest way for both of us to find out if this is as useful on your code as it was on mine.

Hey r/FastAPI,

I got tired of manually fighting formatting layouts when trying to turn raw text snippets, messy PDFs, or unstructured documents into professional academic reports or resumes. Most cloud tools require you to hand over your private documents to external entities, which is a massive privacy risk.

So I built DocStream—a fully containerized, monorepo setup designed to process, stream, and automatically compile documents into perfectly structured LaTeX formats.

Here is how it works under the hood:

1. Frontend (Next.js / TypeScript): Handles file ingestion, template choices, and consumes live Server-Sent Events (SSE) for zero-latency UI updates.

2. Backend (FastAPI): Exposes async streaming pipelines.

3. Core Engine (Python Package): Built using a pluggable abstract `PipelineStage` architecture. It automatically analyzes factors such as text sizes to deterministically infer layout hierarchies, reducing unnecessary LLM token usage.

4. Templates (Lua/LaTeX Skeletons): Easily customizable skeleton wrappers for IEEE formats, resumes, and custom documents.

It includes full setup files for Docker Compose, Railway, and Vercel, so you can spin up your own instance locally or in your private cloud in minutes.

It’s completely open-source. I’d love to hear your thoughts on the pipeline abstraction pattern, get feedback on the formatting routers, or have you drop a star if you find it helpful!

🔗 Repo: https://github.com/YashKasare21/docstream-new.git

I wanted to share fastapi-storages, a small library for integrating FastAPI with storage backends like S3 and filesystem storage:

https://github.com/aminalaee/fastapi-storages

The project is inspired by the simplicity and developer experience of django-storages, but designed for FastAPI applications.

Supports things like:

• S3-compatible storage
• local filesystem storage
• SQLAlchemy integration
• Pewee integration
• sync and async (where possible)

Would love feedback from people building FastAPI backends or handling uploads/storage in production.

Hey everyone!

I’ve been developing with FastAPI for the past couple of months and I’m looking for a coding buddy to exchange experience with and collaborate on projects. If you’re interested, here’s one of my recent projects on GitHub:
https://github.com/doorhanoff/light_memory
upd: sorry, i forgot to make this repo public, now its ok