Hi everyone,

Like many of you, I’m using Claude Code and Cursor daily. But I got tired of constantly correcting the agent because it didn't "know" my project’s specific patterns, leading to hallucinated APIs and broken boilerplate.

I’m working on FastKit Core — a meta-framework for FastAPI designed to be "Agent-Friendly" from the ground up.

The Philosophy: Instead of the AI guessing how you structure your services, DTOs, or events, FastKit ships with a pre-configured AI_CONTEXT.md.

How it works:

You reference AI_CONTEXT.md in your CLAUDE.md or .cursorrules.

1. The agent instantly understands the entire architectural layout.

2. You can prompt: "Create a new CRUD module for 'Book' with async events" and it actually gets the imports and patterns right the first time.

Key Features of FastKit Core:

• Production-Ready Patterns: Built-in support for asynchronicity, clean architecture, and standardized response formats.

• Zero Hallucinations: Every snippet in the context file is verified against actual source code.

• Meta-Framework approach: It doesn't replace FastAPI; it standardizes it so you can focus on business logic while the AI handles the scaffolding.

I’m looking for early adopters to try it out, break things, and give feedback on the DX (Developer Experience).

Check it out here:https://fastkit.org/docs/fastkit-core

Repo:https://github.com/fastkit-org/fastkit-core

Would love to hear your thoughts on "AI-native" project structures. Is this the future of how we'll build frameworks?

every time i started a new fastapi project i was spending the first week doing the exact same stuff. jwt auth, sqlalchemy setup, alembic migrations, docker, celery for background tasks, stripe webhooks... it was just boring repetitive work.

so i packaged everything into a template and have been using it across projects. setup takes like 10 mins and you get:

• jwt auth with email verification and google/facebook social login

• stripe + webhooks already wired up

• postgresql + sqlalchemy + alembic migrations

• celery for background tasks

• docker config ready to deploy

• openai/langchain integration if you're building ai stuff

• pytest setup out of the box

250+ apis deployed with it so far, works well across different cloud providers. been getting good feedback from other devs using it too.

if anyone's interested: fastlaunchapi.dev

happy to answer questions about the stack or how anything is structured

I have created an productivity and automation website. Even though my code is working perfectly well on localhost and Postman

I am facing challenges in deployment at the server side

I have tried Docker approach. That too isn't working well for me

My front end is React JS

It is very frustrating as I am stuck on this for 3 weeks

I am getting Network Error Message

Object { stack: "AxiosError@http://localhost:3000/static/js/bundle.js:1523:18\nhandleError@http://localhost:3000/static/js/bundle.js:872:14\nEventHandlerNonNull*dispatchXhrRequest@http://localhost:3000/static/js/bundle.js:869:5\n./node_modules/axios/lib/adapters/xhr.js/__WEBPACK_DEFAULT_EXPORT__<@http://localhost:3000/static/js/bundle.js:784:10\ndispatchRequest@http://localhost:3000/static/js/bundle.js:2012:10\n_request@http://localhost:3000/static/js/bundle.js:1440:77\nrequest@http://localhost:3000/static/js/bundle.js:1318:25\nhttpMethod@http://localhost:3000/static/js/bundle.js:1474:19\nwrap@http://localhost:3000/static/js/bundle.js:2581:15\nhandleFileUpload@http://localhost:3000/main.62298adbe23a6154a1c3.hot-update.js:106:42\nprocessDispatchQueue@http://localhost:3000/static/js/bundle.js:22100:33\n./node_modules/react-dom/cjs/react-dom-client.development.js/dispatchEventForPluginEventSystem/<@http://localhost:3000/static/js/bundle.js:22397:27\nbatchedUpdates$1@http://localhost:3000/static/js/bundle.js:15768:40\ndispatchEventForPluginEventSystem@http://localhost:3000/static/js/bundle.js:22180:21\ndispatchEvent@http://localhost:3000/static/js/bundle.js:24262:64\ndispatchDiscreteEvent@http://localhost:3000/static/js/bundle.js:24244:58\n", message: "Network Error", name: "AxiosError", code: "ERR_NETWORK", config: {…}, request: XMLHttpRequest }

Pls suggest a way out

Generating PDFs usually sucks because you're stuck concatenating HTML strings in your backend. Every time you need to change a font size or move a logo, you have to redeploy your code.

We built PDFMyHTML to fix that workflow.

It’s a PDF generation API that uses real headless browsers (Playwright) so you get full support for Flexbox, Grid, and modern CSS. But the real value is in the workflow:

• Hosted Templates: Build your designs (Handlebars/Jinja2) in our dashboard and save them.

• Live Editor: Tweak your layout and see the PDF render in real-time before you integrate.

• Clean API: Your backend just sends a JSON payload { "name": "John", "total": "$100" } and we merge it with your template.

We’re looking for our first 50 power users to really stress-test the platform. We just launched a Founder's Deal (50% OFF for all of 2026) for early adopters who want to lock in a rate while helping us shape the roadmap.

Would love to hear your feedback on the editor experience!

What's in your agent files for standardising your code? Any good GitHub repos to look at?

Hey, after spinning up one too many projects and rebuilding the same auth, database setup, payments, and background jobs over and over, I finally built something to escape that loop. Sharing it in case it helps someone else.

FastLaunchAPI: https://fastlaunchapi.dev

It includes:

• Auth: JWT, refresh tokens, email verification, password reset

• Database: SQLAlchemy 2.0, Alembic migrations, Postgres-ready

• Background jobs: Celery and Redis for async tasks

• Payments: Stripe subscriptions with webhook handling

• Email: async SMTP with Jinja templates

• Infrastructure: Docker setup, clean project layout, environment-based config

• Testing: pytest structure ready to go

I use it as the base for my own projects because it lets me skip the boilerplate and start building actual features immediately.

I also offer full support for anyone using it. If you need help finishing your product, I am available by email or calls until you get it shipped.

https://web.archive.org/web/20190204230401/https://fastapi.tiangolo.com/

https://github.com/tiangolo/fastapi/issues/3205

https://github.com/tiangolo/fastapi/pull/5122

The whole time, the frontpage saying “production ready,” and the docs saying sync routes are perfectly fine. Even though (if you read the github thread) there was literally deadlock causing code examples in the docs.

I cannot believe anyone is putting any faith in this project.

It’s the dishonest presentation which I would not be able to tolerate.

I can say, maybe you will get lucky running this in production, and maybe the slick presentation will continue to rope enough people into this project to somehow keep it alive.

Even if this thing manages to succeed in the real world, I will not forget this, and will unavoidably I think end up holding a grudge, and advise to use a different framework.

Built Meridian, an open-source API reliability layer that adds retries, circuit breakers, failover, schema drift detection, and observability across 46 providers including OpenAI, Anthropic, Stripe, Razorpay, Twilio, and more.

Feedback on the architecture, developer experience, and use cases would be appreciated.

https://meridianjs.raghav-verma.com

If you are building public-facing APIs, standard rate limiting is pretty solved. If a user spams your endpoint, you instantly reject them with an HTTP 429 (Too Many Requests).

But recently, I was building out a system that ingested heavy payloads from internal microservices and third-party webhooks. If you hit a webhook provider with a 429 and they don't have perfect exponential backoff/retry logic built-in, that payload is just gone forever. Permanent data loss.

I realized I didn't want to reject the incoming requests; I wanted to act as a shock absorber and queue them, letting them process cleanly at a steady pace (e.g., exactly 5 per second) without dropping the HTTP connection.

I had already built an async distributed traffic-shaping engine for some outbound K8s workers, so I ended up extending it to hook natively into FastAPI's core Dependency Injection system. I wrapped it into an open-source library called Throttlekit.

I built it so you can explicitly choose how the rate limiter behaves per route:

• block=False (The Standard): Instantly returns a 429 HTTPException. Perfect for public APIs.

• block=True (The Shock Absorber): Holds the connection open and queues the request using a GCRA (Generic Cell Rate Algorithm) Leaky Bucket via a shared Redis backend. It processes the payload exactly when the rate limit allows it.

Because it hooks into Depends, you don't have to wrap your route logic in messy decorators, and you can dynamically resolve the rate limit key from the fastapi.Request object (like an IP address, or an extracted JWT user ID).

Here is what the architecture looks like in practice:

Python

from fastapi import FastAPI, Depends, Request
from throttlekit import DistributedLeakyBucket, DistributedTokenBucket, RedisBackend
from throttlekit.fastapi import FastAPIRateLimiter
import redis.asyncio as aioredis

app = FastAPI()

# Share the state across your Uvicorn workers via Redis
backend = RedisBackend(aioredis.from_url("redis://redis-cluster:6379"))

# Strict pacing for heavy webhooks (max 5 per second globally)
webhook_limiter = DistributedLeakyBucket(
    backend=backend, rate=5.0, max_queue_size=100, name="webhook_ingest"
)

# Standard bursty limits for API users (50 requests per minute)
public_api_limiter = DistributedTokenBucket(
    backend=backend, max_tokens=50, refill_interval=60.0, name="public_api"
)

def get_client_ip(request: Request) -> str:
    return request.client.host or "anonymous"

# Route 1: Internal Webhook (block=True)
# Instead of a 429, this smoothly throttles and paces the incoming requests.
@app.post(
    "/internal/webhook",
    dependencies=[
        Depends(FastAPIRateLimiter(
            limiter=webhook_limiter,
            key=lambda req: "shared_webhook_queue", 
            block=True 
        ))
    ]
)
async def process_webhook(payload: dict):
    return {"status": "queued and processed safely"}

# Route 2: Public API (block=False)
# If a user exceeds 50 req/min, instantly reject with HTTP 429.
@app.get(
    "/public/data",
    dependencies=[
        Depends(FastAPIRateLimiter(
            limiter=public_api_limiter,
            key=get_client_ip, 
            block=False,
            detail="Quota exceeded. Please slow down."
        ))
    ]
)
async def get_public_data():
    return {"data": "..."}

It is fully type-hinted and also supports global RateLimitMiddleware if you want to protect the entire application instead of specific routes.

I'm curious how you guys handle webhook ingestion floods. Do you instantly dump incoming payloads into a message broker like RabbitMQ/Kafka, or are you enforcing limits at the FastAPI routing layer like this to protect downstream resources?

(Installs via uv add "throttlekit[redis,sql,fastapi]" or pip install)

Would love any feedback on the architecture or the FastAPI integration!

(Note: I will drop the GitHub and PyPI links in the comments if anyone wants to check out the Redis Lua scripts or try it out!)

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.

So i've spent unhealthy hours building and perfecting my api for stocks & finance data , i've enjoyed making it and hope to make more and better ones in future. It works very well and I am proud of the quality, BUT im facing a problem:

i want to add more but avoid breaking. Ive thought of all the possible end points i could add for users to get best value without overcomplicating and adding soon to be deprecated endpoints(problem with many apis).

(options data is missing but i plan to make a seperate api for that which is heavily focused on advanced options data only.)

So, if you have some good ideas for features or endpoints I could add that are missing from the photo please drop em down below, I want to add more!

my project: https://rapidapi.com/mcodesagain/api/yh-better-finances-api

Thanks

Is FastAPI really fast as claimed on the website? “ on par with Node Js and GO “

What do you think ? Is it misleading or not ?

Honestly just need a sanity check here.

Every time I start a new python project I go through the same loop: install redis, configure celery, deal with broker connections randomly forget... it's too much hustle as a thing.

I am trying to validate my idea, basically generalizing all this task management in a cloud based solution.

After couple of weeks, I came up with this some cloud based service which can handle the hustle.

I have been testing it in a couple of projects myself, and looks really useful, but really would love to hear what other people think? Open to critics.

How it works (fastAPI projects only):

- you install our SDK, add our router in your fastAPI app

- decorate the functions you want to run async

- We enqueue and you will have total visibility on request/retries/failure etc

I would love to hear critics and feedback from other developers. If anyone wants to try it, please get in touch directly via DM. I'm happy to offer the service for free for the first six months to validate and refine it for production.

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.

I'm setting up React frontend for an existing FastAPI backend.

At first, I tried just asking ChatGPT4 (not ChatGPT4o, but gpt-4-turbo, which personally experience being better) and that guided me into a react setup that had "162 vulnerabilities (1 low, 91 moderate, 67 high, 3 critical)" after doing an "npm audit fix --force".

I have just enough experience in React to say, that's not good. (I've had one React class, and that was enough to say I'm going to hire someone to do this. Far too much attention to that community is required to stay on top of the fast moving dependencies of React.)

So I deleted that setup, and tried a more careful, step wise series of questions with backing research lookups using Phind.com, and the reference links provided by Phind.com... and that gave me a similar react frontend with a similar high number of vulnerabilities.

Thinking, "okay... maybe these LLMs are just behind, and I need a more recent tutorial." So I tried a tutorial at testdriven.io and that gave me just as many vulnerabilities as the LLM guides. So... either I need a more recent tutorial, or some advice telling me "that's the state of React, you'll have these vulnerabilities, some of them called 'critical' even, just ignore them?"

FWIW, I've been writing FastAPI for nearly 3 years now, REST API servers in C++ since the early 2000's, and more going back decades. I think I just need more current instructions not requesting unsupported, old, abandoned npm components and libraries. Is that incorrect, and React just exists in this messy state?

If you use FastAPI and SQLAlchemy, then this post is for you. If you are not using these 2 magnificent pieces of tech together, read on.

People that are reading TechEmpower benchmarks, make sure to look at the “fastapi-Gunicorn-ORM” benchmarks and compare those to the rest.

You will see actually how slow Fastapi together with SqlAlchemy is basically on par with Django.

I guess no sane person will write raw sql în 2024 so all the speed is lost because of the ORM.

Compare it in TechEmpower with gin-gorm or Nestjs-Fastify+ORM (type ORM) and you will see they both are many times faster than FastAPI.

The problem is, we don’t have any fast ORM in python because of how the language works.

Do this : In TechEmpower:

1.select python, go and javascript/typescript as languages

2. In the databases section select Postgres as a db to have the same db engine performance compared

3. In the ORM section select : full (so you compare benchmarks using full fledged orms for all frameworks)

Now you will see correct comparison with an ORM used. Here it is:

https://www.techempower.com/benchmarks/#hw=ph&test=db&section=data-r22&l=zijmkf-cn1&d=e3&o=e

Now look at how far away gin-gorm and even Nodejs is to Fastapi.

Gorm and TypeORM are miles ahead in performance compared to SqlAlchemy

==

—- Single query:

Gin-gorm: 200k

Nest+fastify + typeorm : 60k

Fastapi+sqlalchemy: 18k (11+ times slower than go, 3+ times slower than Nodejs)

Django+DjangoORM: 19k (faster than Fastapi lol)

—- Multiple query:

Gin-gorm: 6.7k

Nestjs+fastify+typeorm: 3.9k

Fastapi+sqlalchemy: 2k ( 3+ times slower than go, 1.9+ times slower than Nodejs)

Django+DjangoORM: 1.6k

—- Fortunes:

Nest+fastify+typeorm: 61k

Fastapi+sqlalchemy: 17k (3+ times slower than Nodejs)

Django+DjangoORM: 14.7k

—- Data updates:

Gin-gorm: 2.2k

Nestjs+fastify+typeorm: 2.1k

Fastapi+sqlalchemy: 669 (3+ times slower than than go, 3+ times slower than Nodejs)

Django+DjangoORM: 871 (again, Django is faster than Fastapi)

==

You can check the source code of fastapi to see it uses sqlalchemy and no complicated things here:

https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Python/fastapi/app_orm.py

Conclusion: Fastapi is fast, ORM is slow, if you plan to do raw sql then it’s mostly on par with the others. When you use an ORM it falls behind very very much and it’s extremely slow, without any comparison to Nodejs or Go.

It’s on par with Django(Django winning in 2 out of 4 tests), so at least go with Django for all the nice batteries.

Edit: I wanted to raise awareness to people believing using FastAPI with an ORM would give them the same speed as the ones in the TechEmpower link from fastapi’s site(which has no ORM attached). Because this is clearly not the case.

Edit 2: If you had the patience to read until this point, I just want to let you know the title should have been: “SQLAlchemy will limit your api performance, even with FastAPI”, too late to edit now.

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).

I built this application (backend) in my second year of college. Rezonance is an ad-free music streaming platform with features like AI-powered recommendations and in-app sharing. I also tried to build an autocomplete and auto-correct-based searching feature from scratch, as you get in the popular streaming platforms. I built this using FastAPI and SQLite3 and used Redis to cache the requests for improved response times.

This is the first project which I sent to production. Please feel free to suggest any improvements/changes.

Link to the repository: https://github.com/rezonance-india/engine-api (Edited: typo)

Will Microsoft SQL Server ever be integrated into fastapi?

I need help integrating sqladmin with fastapi, if anyone has done this before, I have few queries, thanks

Hey everyone,

Been learning Python seriously for a while

and kept running into the same frustration —

pytest fails, spend 30 minutes figuring out

why, fix it, run again, something else breaks.

So I tried building something to automate

that loop. Spent the last month on it.

It basically:

- Runs pytest on your project

- Tries to fix what's failing

- Reruns to check if fix worked

- Rolls back if it made things worse

Current honest capability:

→ Works well on import errors

→ Handles dependency conflicts

→ Simple logic bugs sometimes

→ Fails on complex multi-file issues

→ Struggles with fixture problems

My question to this community:

Is this actually a problem worth solving?

Do you spend significant time debugging

pytest failures?

And if anyone has a Python project with

failing tests they'd be willing to share —

I'd love to run it through and see what

happens. Would help me understand if this

is useful or not.

Just trying to figure out if I've built something useful or wasted a month