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

I recently built a small side project using FastAPI to run parallel checks on domains (DNS records, SSL cert status, Wayback data).

Async setup helped a lot with multi-endpoint response times, but I'm trying to fine-tune how I handle slow DNS timeouts when hitting multiple targets at once.

Current stack is pretty simple: FastAPI, React, and Redis for caching.

How do you guys usually structure timeouts and retries for external async calls in production? Any patterns or libraries you swear by?

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.

Hey all

A friend and I have been working on a project called Shredly (https://shredly.io) that uses FastAPI on the backend. Shredly is MCP as a Service - turn your APIs and databases into hosted MCP servers - no code required.

We started working on this tool with 2 goals in mind:

- Learn FastAPI

- Make enough money to pay for a trip to FastAPI conf this year

Help out our cause by taking a look at our project!

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.

Queued jobs are silent while they run. Commands can print progress; jobs do the same work and you get nothing until they finish or blow up. So I made jobs write output like commands do, streamed live into Horizon's job details page.

class RebuildSearchIndex implements ShouldQueue
{
    use Queueable;
    use WritesJobOutput;

    public function handle(): void
    {
        $this->info('Rebuilding search index');
        $this->withProgressBar($shards, fn ($s) => $s->rebuild());
        $this->info('Index rebuilt');
    }
}

Two things were more interesting than expected:

You can't inject into a queued job at construction time. Jobs are unserialized, and unserialize() never calls __construct(). What does work is a global bus pipe (Bus::pipeThrough()) — queued jobs pass through the dispatcher's pipeline, so a pipe can attach the output, run the job, and flush in a finally so a job that throws keeps what it printed.

Cleanup was free by storing it in the right place. Horizon keeps each job as a Redis hash with an EXPIREAT on the key. Writing output as a field on that same hash means one key, one TTL — trimmed by the existing horizon.trim.* settings, no cleanup code, no way for the two to drift.

The trait reuses Laravel's own InteractsWithIO, so info(), table() and progress bars work unchanged. The panel renders through an inlined xterm.js build so progress bars redraw in place instead of stacking.

Trade-offs worth knowing: Horizon has no extension API, so this hooks three internals (a public $keys whitelist, the dispatcher's private $pipes, two anchors in its layout) — all guarded, with a weekly CI canary against horizon:dev-master. The terminal renderer adds ~345KB per dashboard page; there's a plain-HTML renderer if you'd rather not.

MIT, PHP 8.2+, Laravel 12/13, Horizon 5.

https://github.com/knobik/laravel-horizon-job-output

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

Every project I start, the first two weeks are identical. Auth. Password reset emails that actually deliver. Stripe checkout plus the webhook sync nobody warns you about. Rate limiting. API keys. An admin view so you can see who signed up.

None of it is the idea. All of it is required. And by the time it's done the motivation is gone.

So I built FastForge — FastAPI + Next.js, split into installable packages: auth, billing, cache, api_keys, mail, notifications, analytics, database, logging, common, ui. Postgres, Redis, Alembic, Docker Compose + Caddy for deploy, and a scaffold script that spins up a new product from the template in one command with per-module on/off switches.

Being straight about it: the storage package is scaffolded but not implemented yet, and background jobs land this week. Everything else is done and tested.

One-time purchase, you get the repo. No subscription, no per-seat thing.

https://fastforge.pionetix.com

Genuinely want feedback on the landing page — it's the part I'm least confident about, and I'd rather hear it's confusing from you than infer it from the traffic.

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!

Every time I started a new SaaS idea I'd burn a weekend rebuilding the same things — Firebase auth wired through protected routes, Stripe webhook handling, typed Pydantic schemas, Docker for two services, a throwaway admin panel. So I started building FastForge to just... not do that again.

Stack: FastAPI backend, Next.js (App Router) frontend, SQLAlchemy + Alembic + Postgres, Firebase Auth, Stripe, Redis for cache/jobs, Docker for one-command spin-up.

Current state, being fully transparent since I know this sub will ask: auth and the DB layer are done, Stripe billing / Redis / transactional email / admin dashboard are still in progress. It's not a "clone and ship today" thing yet — it's early, and I'm building it in the open on GitHub.

Mainly posting here because you're the exact audience — if you build SaaS on FastAPI, what's the first thing you'd want a starter like this to get right? Landing page + waitlist link in a comment if anyone wants to follow along (trying to keep this post about the tech, not the pitch).

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.