Why I built it:

I’ve seen and spoken to a lot of fellow developers and I always find them having the same problem I used to have: crawlers, bots, automated pentesting/brute-force, file probing and really so much more. They all use a variety of tools like Cloudflare, Nginx, Fail2ban, CrowdSec, Traefik, etc…

About 2y ago I was building an art gallery website for the landlord who happens to be an artist and checking the server logs is that I was getting tired of these “attacks”. I couldn’t find anything that would fill the gap, since I had Cloudflare, Nginx, Fail2ban; all set up and still was getting attacked. My server (a Hetzner VPS) is fully covered. The problem was at the application layer: the API. Since I use FastAPI as my backend, I went on searching for a library that would help me out but found nothing. I was like an entire week out there searching for something that just didn’t exist. And so I got tired and I built it.

Now that I’ve layed the back-story, we can get into the details.

What my project does:

Architectural-wise, it’s a core engine (guard-core) that holds the entire security pipeline (we’ll get to that later on) and feeds framework-specific thin-adapters (fastapi-guard, flaskapi-guard and the django equivalent). I’m also extending to Typescript and Rust, so that this doesn’t stay Python only. The idea is to secure every API, otherwise it’s filling no gaps…

• Rate Limit based on IPs
  
• Auto-ban IPs
  
• Set up Honeypots that end in an automatic instant ban
  
• Use decorators to override gloval config
  
• Whitelist/Blacklist IPs, Countries, Cloud Providers (GCP, AWS, Digital Ocean, Azure, etc)
  
• Add/Remove patterns that you want to catch or bypass (specific to your use case)
  
• Behavioural tracking (per IP)
  
• User Agent/Security Headers filtering
  
• Penetration attempt detection
  
• Much more, for real.

Useful stuff

Inplaced each repo link under its name, but for clarity here’s the core engine: https://github.com/rennf93/guard-core and the one that is used the most https://github.com/rennf93/fastapi-guard

I created also an example app for/on each repo at root under the examples/ dir.

Special Note

I also want to say explicitely out loud if it wasn’t made clear before: this is not a replacement for any of the tools mentioned in the beginning. Cloudflare, Nginx, and all the others don’t do what my libraries do; and therefore I don’t do what they do. This aims to fill in the gap, to make your APIs airtight. The idea is to combine these libraries with your traditional WAFs.

How it differs from other projects / Comparison

I guess you could kinda compare it to SlowAPI and other rate limiters but the truth is that FastAPI Guard and its engine are full of features and rate limiting is just one of them all. So it basically has no comparison but I guess the reference would be that. And for the record, rate limit is not gonna fill in the gap on its own all alone. In this era of AI coordinated attacks, rate limiting alone can’t tell whether it’s a bunch of AIs doing some DDoS attack through residential IP proxies, or just a very odd spike in sloppy user requests from actual homes.

Target Audience

Basically anyone maintaining and building APIs (mainly in Python, but expanding).

Hey everyone, after taking a bit of a break I decided to write an in-depth tech blog to help those of you building (or about to build) an AI agent in the Python ecosystem, especially on FastAPI, so you can end up with something structured, scalable and efficient. This comes out of a lot of time working on chatbots, streaming and AI agents. There was no good guide for me when I built those, so after suffering plenty of pain and bugs I decided to write it up and open source part of my work to help you avoid the same. Hope it helps.

Full blog here in case you have time to read properly. Whether you're a team lead or senior who needs to build a scalable AI agent project, or a junior or intern who wants to build one the right way, this should be useful (it cost me a lot of time and money to learn): https://huynguyengl99.github.io/posts/pydantic-ai-typed-websockets-fastapi/

Comes with the repo: https://github.com/huynguyengl99/pydantic-ai-ws-agent

If you want to catch up first, TL;DR:

1. A contract-based, structured protocol still beats an unstructured, code-first one. Instead of writing a pile of if/else and tests to make sure things are correct (and sometimes they still aren't), you keep one up-to-date contract that both the backend and the frontend build against, so no field is silently missing or outdated. For REST APIs that's OpenAPI. For WebSockets it's AsyncAPI. You can even design the whole protocol before writing any code. Trust me, it saves you a lot of 2am bugs.
2. Prefer a structured, model-independent agent. There are plenty of options now (LangChain, the OpenAI SDK, the Gemini and Anthropic SDKs), but most of the time what matters is being able to switch model or provider without rewriting anything, structured and validated tool calls (without tool calls it's just a chat, not an agent), and something that fits your existing ecosystem. Tie yourself to one vendor's SDK and you'll feel it the first time you want to compare models or a provider has an outage. Pydantic AI is the one that gives you all of that. If you've used LangChain you'll remember the mess around messages and tool handling, a lot of unnecessary complexity. Pydantic AI keeps it structured, and since it comes from the Pydantic team it speaks Pydantic models natively, which is exactly why it fits FastAPI so well.
3. Once your agent is structured, your server API should be too. Most people reach for SSE because it's simple, but it's missing a few things: bidirectional messages, a proper API schema (OpenAPI 3.2.0 has some support for streaming now, but tooling is still limited and it doesn't feel as natural as it does for REST), and any official way to offload work to a worker or push a message from outside the request, like a notification from somewhere else in your system. WebSockets don't have that schema problem, because AsyncAPI is a real spec built for exactly this: every message your server can send or receive, described in one document your frontend can generate a client from. It's the same deal OpenAPI gives you for REST, just for event-driven APIs.
4. Bidirectional matters more than people expect, and human-in-the-loop is why. With Pydantic AI you can mark a destructive tool requires_approval=True. The run then stops before executing, hands you the pending calls, and you send an approval request to the UI. The user approves or denies (they can even edit the arguments), and you resume the run from where it paused. That round trip is awkward over SSE and completely natural over a WebSocket, it's just two more messages on a connection you already have.
5. That's where ChanX and fast-channels come in. Based on the well-known django-channels package, I built fast-channels to bring the channels architecture to FastAPI. ChanX is the only tool I'm aware of that makes WebSocket handlers structured and easy while auto-generating AsyncAPI docs, so your frontend can generate a client straight from the schema. That's the contract you need to stop things going stale or breaking silently. It also gives you the offload story: the run happens in a background task and broadcasts to a conversation group, so a page refresh mid-run doesn't kill the answer, every tab stays in sync, and moving the work to a Celery or taskiq worker later changes nothing else.
6. One more thing that surprised me: the whole flow becomes testable without an LLM. Because the protocol is typed and the agent is built from a factory, Pydantic AI's FunctionModel can script exactly what the model does. Streaming, tool execution, approve, deny and reconnect all become deterministic tests. Mine run in about a second with no API key, which is the difference between having tests and pretending to.

That's the core and the summary for a quick catch up. When you have time, reading the blog and looking at the repo will give you more insight into building a structured, scalable, production-ready AI agent.

Related repos:

• Pydantic AI, the agent framework: https://github.com/pydantic/pydantic-ai
• ChanX, typed WebSocket handlers with AsyncAPI generation, for Django and FastAPI: https://github.com/huynguyengl99/chanx
• fast-channels, the Django Channels architecture ported to FastAPI, which ChanX builds on: https://github.com/huynguyengl99/fast-channels
• The demo from this post: https://github.com/huynguyengl99/pydantic-ai-ws-agent

If ChanX or fast-channels turn out to be useful for you, a star or any contribution to improve them would be appreciated 😄

I'm open to any discussion in the comments, feel free to bring up any problem you're hitting when building an AI agent. I'll try my best to help, since I've been through most of the pain already.

I recently built an open-source reverse proxy using FastAPI and Uvicorn to handle strict PII redaction for LLM applications.

A common issue with Python based redaction tools is memory bloat from heavy NLP libraries and broken token delivery when intercepting real-time Server-Sent Events (SSE). To keep the resource footprint minimal and the streaming smooth, I structured it around a few specific patterns:

- Minimal Footprint ( approx. 24MB): It bypasses heavy frameworks entirely, using a compiled regex engine combined with a local quantized ONNX runtime model.

- Async Lookahead Buffer: To prevent PII placeholders from fragmenting across split SSE network chunks and leaking raw tags to the UI, I implemented an asynchronous sliding-window buffer that holds back unclosed bracket tags.

- Stateless Vault: Mappings are handled via a transient Redis TTL vault.

It operates as a drop-in base_url substitute for the OpenAI SDK. If you work with FastAPI and async streaming middleware, I would love feedback on the lookahead buffer logic or any edge cases in the request-response cycle!!

Repo: https://github.com/ninadphalak/LLM-Shield-Proxy

Hello folks!

We're organizing the first ever official FastAPI Conf, in Amsterdam, October 28th, 2026. ✨

It's gonna be very cool, great speakers, and announcements too.

Early Bird tickets are now available (until August 23th).

Here's the website with info, tickets, and newsletter: https://fastapiconf.com

Common problem with LLM streaming endpoints: client refreshes or the connection drops mid-response, and the whole stream is gone. Client has to start over, and you've already burned the tokens for nothing.

Built a small Redis-backed library for this. The producer runs as a background task, independent of the request, and buffers chunks so a client can reconnect and ask for everything after chunk N.

@app.post("/chat/{conversation_id}/stream")
async def start_stream(conversation_id: str, prompt: str):
    return await start_conversation_stream(
        stream, registry, stop, conversation_id, stream_id,
        producer=lambda: call_llm(prompt),
    )

Also has an explicit stop that's separate from disconnect (closes the producer's generator, so it actually cancels whatever's underneath, not just the client-facing stream), and thin adapters for LangChain and CrewAI plus encoders for the AG-UI and Vercel AI SDK wire protocols if you're feeding a useChat frontend.

pip install fastapi-resumable-stream[fastapi] https://github.com/ofershap/fastapi-resumable-stream

It's new (0.2.1), feedback welcome.

I've been building a small open-source project called FastStrapy over the past few weeks, and I'd love some feedback from the Python/FastAPI community.

The idea came from repeatedly recreating the same FastAPI project structure every time I started a new API. Copying folders, configuring environment variables, setting up Alembic, wiring configuration—it became repetitive.

So I built a CLI inspired by create-next-app that generates a FastAPI project through an interactive prompt.

Some of the design choices:

• Typed project configuration using Pydantic
• Registry-based generator architecture
• Jinja2-powered templates
• Typer-based CLI

It's still very early (v0.1), so I'm more interested in feedback than promotion.

A few questions I'd love your thoughts on:

• What features would you expect from a FastAPI scaffolding tool?
• Is there anything about the generated structure you'd change?
• Are there existing tools you think I should learn from?

GitHub:
https://github.com/AnoopGeorge418/faststrapy

Constructive criticism is very welcome. I'd rather improve the project now than after it grows.

Has anyone encountered this yet?

>fastapi deploy
  FastAPI Cloud 
  🚀 Deploying app...
   ✗ Something went wrong while contacting the FastAPI Cloud server. Please try again later. 
    The write operation timed out

This is just a 1MB deployment but it times out at around 300kb. Could it be a problem in my end or a service availability issue? I tried several times.

Hi everyone,

I'm currently building a fairly large e-learning platform using FastAPI,it's my first project, and before I go too far with development, I'd like to make sure my backend architecture is well designed, scalable, and maintainable.

The project will include features such as:

• User authentication and authorization (JWT, roles: Admin, Teacher, Student, Parent)
• Courses and modules
• Lessons (videos, PDFs, quizzes)
• Assignments and submissions
• Exams and grading
• Progress tracking
• Notifications
• Payments/subscriptions (later)
• File uploads
• Discussion/comments
• Certificates
• REST API (possibly GraphQL in the future)

I'm planning to use:

• FastAPI
• SQLAlchemy 2.0
• Alembic
• PostgreSQL
• Pydantic v2
• JWT Authentication

At the moment, I'm trying to decide on the best project structure. I've seen many different approaches:

• Traditional layered architecture
• Clean Architecture
• Domain-Driven Design (DDD)
• Hexagonal Architecture
• Vertical Slice Architecture
• Feature-based architecture

I'd like to avoid ending up with a project that's difficult to maintain as it grows.

My questions

1. Which architecture would you recommend for a medium-to-large FastAPI project like this?
2. How would you organize the folders and modules?
3. Where should business logic live?
4. How do you separate models, schemas, services, repositories, and dependencies without creating unnecessary complexity?
5. Are there any open-source FastAPI projects that you consider good examples of clean architecture?

I'm looking for an architecture that is:

• Easy to maintain
• Easy to test
• Scalable
• Production-ready
• Follows FastAPI and Python best practices

If you have an example repository or folder structure that you've used successfully, I'd really appreciate it.

Thank you!

Hi folks,

I am working on zinda, a small experimental caching library for FastAPI/Python, and I'd like some design feedback before I take it further.

The idea: instead of you picking TTLs and wiring up invalidation by hand, the cache should watch how your functions behave and keep hot data fresh on its own.

What Have I Implemented:

• @cache.cached() decorator - keys itself on function arguments, no config
• Single-flight: concurrent misses for the same key collapse into one recompute (no stampedes)
• Soft TTL + hard TTL: callers get stale data instantly while it refreshes in the background, and a background sweeper refreshes hot entries before anyone asks
• A /zinda/stats endpoint showing hit rates, miss costs, and refresh activity per function

​

app = FastAPI()
cache = install(app, Cache(default_ttl=60))

@cache.cached(ttl=120, refresh_after=30)
async def fetch_products(category: str):
    return await db.fetch_products(category)

Where I want feedback:

1. Next step is auto-detecting hot paths, the library scoring functions by call frequency and recompute cost, and deciding what's worth caching without any decorator. Would you trust that if every decision is visible in stats, or is explicit always better?
2. Automatic invalidation is the hard part. My plan is learned TTLs by default + optional tags for precise invalidation. Reasonable, or am I missing something?

It's in-memory only for now and definitely not production-ready. I am validating the ideas first.

Code: https://github.com/grandimam/zinda

I have been going through my codebase this morning and asked claude Ai how I can validate the phone number field of my schema model and it has recommended the official python phonenumber library, but suprisigley I checked out the Pydantic docs and found the same library which is wrapped on a Pydantic type and does all the validations as the Python phonenumber libarary plus less code and less mantainance, you just use it as type annotation and BUM it does the underhood workd for you.
I want to read it this is the link https://pydantic.dev/docs/validation/latest/api/pydantic-extra-types/pydantic_extra_types_phone_numbers/#_top

You can even configure the accepted regions and the default region as well.

I have a good Python experience. I did basic backend dev with PHP and Flask before, so the beginner concepts won't be that much challenging. What I'm looking for is a single well-organized course to learn FastAPI deeply. I've checked out the official documentation, which is absolutely great and lovely, and I will use that as a reference.

It doesn't matter if the course is certified or not. I focus on the skills I'll gain. It's more preferred to be a free course though (but don't hesitate to share paid courses too if they are really worth paying for).

Hey everyone,

I recently finished my first FastAPI project and wanted to get some feedback from people with more experience.

It's just a simple Movie Watchlist API that I built to learn FastAPI and backend fundamentals, so I'm not really looking for feedback on the idea itself. I'm more interested in hearing what you think about the code, the structure, and the way I approached building it.

Repo: https://github.com/BensefiaAbdessamed/MoviesWatchlist

My goal is to become a backend engineer who can build production-ready applications, so I'd really appreciate an honest review. If you were reviewing this as a junior's project, what would you point out? What beginner mistakes do you notice? What would you refactor or do differently? Are there any bad practices that I should stop early?

I'm also a bit unsure about what to learn next. Should I keep improving this project by adding more concepts, or is it better to start a new one? What backend topics do you think are important after getting comfortable with FastAPI? Things like testing, caching, message queues, Docker, CI/CD, design patterns, system design, or anything else?

A couple of friends also suggested that I should learn Django next. Do you think it's worth learning at this stage, or should I keep going deeper with FastAPI and backend fundamentals before jumping to another framework?

Lately I've also been getting interested in RAG systems and MCP integration because AI applications seem to be everywhere now. Do you think it's a good idea to start learning those, or would that just distract me from building a strong backend foundation first?

Feel free to be as critical as you want. I'm posting this because I genuinely want to improve and avoid building bad habits early on.

Thanks to anyone who takes the time to review it or share their advice. I really appreciate it.

Hello there! 😄

I'm currently building a backend for a Neo4j graph database and was wondering if some of the more experienced people here have any advice or best practices to share.

I only have basic experience with Python (although I'm comfortable with programming in general). Most of my backend experience comes from working with NestJS and Prisma ORM, so I'm trying to translate some of the concepts and patterns I'm familiar with into the Python ecosystem.

For the database access layer, I decided to use the official Neo4j Python driver rather than an ORM or ODM.

My current plan is to structure the backend like this:

text backend/ │ ├── main.py │ ├── api/ │ ├── routes/ │ │ ├── users.py │ │ ├── graph.py │ │ └── projects.py │ ├── services/ │ ├── user_service.py │ └── graph_service.py │ ├── repositories/ │ │── neo4j_repository.py │ ├── database/ │ └── neo4j.py │ ├── dto/ │ ├── user.py │ └── graph_models.py │ └── security/ └── auth.py

Coming from NestJS, my current thinking is roughly:

• routes → similar to NestJS controllers
• services → business logic
• repositories → database access layer (somewhat comparable to what Prisma handled for me)
• database → Neo4j driver initialization and connection management

Does this architecture make sense for a FastAPI + Neo4j project, or are there more idiomatic approaches in the Python ecosystem that I should consider?

Also, if you've built production applications with Neo4j and the Python driver, I'd appreciate hearing about common pitfalls, lessons learned, or things you wish you had known when starting out.

Thanks!

Hi all, i've created a python library above fastapi-filters that automatically generates filter, search, and sorting fields for any SQLAlchemy model in FastAPI, with native support for JSONB containment (contains), key presence (has_key), and case‑insensitive text search inside JSON values.

Example of usage (create your own custom filter for your orm model):

class UserFilter(DynamicFilter):
    db_model = User # your model
    exact_fields = ["id", "email"]
    search_fields = ["name", "bio"] # generates name__ilike, bio__ilike
    range_fields = ["created_at"] # generates created_at__gte, __lte
    contains_fields = ["tags", "metadata"] # tags__contains (list), metadata__contains (dict) + metadata__has_key
    json_search_fields = ["metadata"] # generates metadata__value_ilike
    default_order_by = ["-created_at"]

And then use it in your endpoint as a dependency:

app.get("/users")
def get_users(
  filter: UserFilter = Depends(UserFilter), # your filter here
):
    query = filter.filter(session.query(User))
    return query.all()

GitHub: https://github.com/matfatcat/fastapi-dynamic-filter/
PyPI: https://pypi.org/project/fastapi-dynamic-filter/

Working on a FastAPI + Next.js SaaS boilerplate (Python equivalent of the JS "ship fast" starters). Backend is FastAPI + Pydantic v2, Firestore for storage so far.

Before I finalize the feature list, curious what this community actually wants baked in:

• Auth: what's your default — Supabase, Clerk, roll-your-own JWT?
• Billing: Stripe is obvious, but subscriptions vs. usage-based matters a lot for setup
• Background jobs: Celery, arq, or just Cloud Tasks/Cloud Run?

Landing page + waitlist if you want to follow progress: https://fastforge.pionetix.com — but honestly more interested in the discussion here than the sign-ups.

Hi there! I'm an incoming 2nd year computer engineering student who wants to learn web development for microcontroller UI. However, I don't know where to start. I already know how to program in Python and some basic web requirements like HTML and CSS, but I am stuck whether I should learn JavaScript next or go straight to FastAPI. Thank you for reading this post. Any input would be appreciated.

Ivan Levkivskyi and I are proposing a native shorthand for Annotated (PEP 835) to clean up heavy type-hinting patterns. We have confirmed this syntax is fully compatible with FastAPI and works out of the box with zero changes required.

Before:

python def create_user( id: Annotated[int, Path(gt=0)], name: Annotated[str, Query(min_length=3)], role: Annotated[str, Query(min_length=2)] = "user" ) -> User: ...

After:

python def create_user( id: int @Path(gt=0), name: str @Query(min_length=3), role: str @Query(min_length=2) = "user" ) -> User: ...

The Spec: PEP 835 Full Draft

We are gathering community sentiment before moving forward. If you are a heavy user of Annotated in FastAPI, your feedback is valuable. You can register your stance in the official Discourse poll before it closes on July 15.

I have simple fast api app it recieves requests and either writes data to the sqlite dB or fetches data from it what would be the best place to host it preferably for free since its a small hobby project but would scale up successful

I built this, so take the "cool project" framing with a grain of salt — genuinely looking for people to poke holes in it.

The problem: if you've ever needed a model field in more than one language (blog post titles, product names, category labels), you've probably hit the same two bad options — a separate translations table with joins on every query, or a JSON column you hand-roll get/set logic for yourself, differently, in every project.

fastkit-i18n is a small weekend project that tries to make the second option not suck:

from sqlalchemy import JSON
from sqlalchemy.orm import DeclarativeBase, Mapped, mapped_column
from fastkit_i18n import TranslatableMixin

class Base(DeclarativeBase):
    pass

class Article(TranslatableMixin, Base):
    __tablename__ = "articles"
    __translatable__ = ["title", "content"]

    id: Mapped[int] = mapped_column(primary_key=True)
    title: Mapped[dict] = mapped_column(JSON)
    content: Mapped[dict] = mapped_column(JSON)

article = Article()
article.set_locale("en")
article.title = "Hello World"

article.set_locale("es")
article.title = "Hola Mundo"

article.set_locale("en")
article.title   # "Hello World" — reads/writes like a plain string field

One row, one JSON column per translatable field, no joins. It also works with SQLModel table models (since under the hood a SQLModel table class is a real SQLAlchemy mapped class), and there's a LocaleMiddleware (pure ASGI, works with FastAPI/Starlette/Litestar) plus a Laravel-style _() for JSON translation files if you want the whole package instead of just the mixin. All three share the same locale context, but each works standalone if that's all you need.

What's genuinely missing right now (not hiding this — would rather you hear it from me than discover it):

• No pluralization. If you need ngettext-style "1 item / 5 items" logic, gettext/Babel handles that natively, and this doesn't yet.
• Accept-Language Parsing in the middleware is simplified — it takes the first listed language, not full RFC quality-value negotiation (fr;q=0.5, en;q=0.9 resolves to fr, not the higher-weighted en). Fine for most apps, not a drop-in replacement if you need strict negotiation.
• It's genuinely new — published today, zero production mileage beyond our own testing. Wouldn't put it on a critical path yet.

Where I could actually use help:

1. RFC-compliant Accept-Language parsing as an opt-in alternative to the simple version
2. Pluralization support — open to suggestions on whether that belongs in this package or stays out of scope
3. Just... using it and telling me where it breaks. It's MIT licensed, no dependencies beyond an optional SQLAlchemy extra (pip install fastkit-i18n[sqlalchemy]), so the bar to try it is low.

Repo: https://github.com/fastkit-org/fastkit-i18n
Docs: https://fastkit.org/docs/fastkit-i18n
PyPI: https://pypi.org/project/fastkit-i18n

It's the standalone extraction of the i18n piece from a larger toolkit I work on (fastkit-core) — if you're already using that, you already have this, no separate install needed. This is for anyone who wants just the translation piece without the rest.

Happy to answer questions in the comments, and if anyone wants to contribute on either of the two gaps above, PRs and issues both welcome.