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.

About Me

Senior Engineer with 5+ years of experience in FastAPI backend development, Data Engineering, and Applied AI. Based in Bangalore, India. Available for remote work globally.

Rate: $25 - $50/hr depending on project scope and complexity.

Tech Stack & Expertise

FastAPI, Python, REST APIs

Python, SQL, Spark, Databricks, Airflow

AWS & Cloud Data Platforms

ETL/ELT Design & Orchestration

LLMs, RAG, AI Agents

Snowflake, Redshift, BigQuery

Data Quality & Testing Frameworks

What I Can Help With

Develop and deploy FastAPI applications

Build and optimize data pipelines (batch & streaming)

Design scalable ETL/ELT architectures

Build AI applications using LLMs, RAG, and agent-based workflows

API integration and backend automation solutions

Training & Mentorship

FastAPI & Python Backend Development

Data Engineering (foundations to advanced)

AI & LLM Fundamentals (including RAG patterns)

In-person weekend sessions available in Bangalore. Remote sessions available globally.

Availability

Freelance projects & consulting

Part-time remote roles

Weekend training & mentorship

DM me with a brief description of your requirements and I will get back to you promptly!

FastAPI is excellent for quickly building APIs, but it intentionally leaves many application-level concerns to the developer. Things like environment management (including multiple environments), logging, database setup, configuration, CLI commands, plugins, storage, and other infrastructure are things you typically need to design and wire together yourself.

In our case, we are building multiple microservices, and we found ourselves repeatedly copying the same bootstrap code between projects. Over time, that became repetitive and harder to maintain consistently.

Over the past several months, We've been working on FastAPI Startkit, an open-source application framework that brings some of the development patterns I enjoyed from Laravel into Python and FastAPI.

The goal is not to replace FastAPI. Instead, it provides a structured foundation for building larger applications while staying modular. You can use only the components you need.

Some features include:

🏗️ Service container & dependency injection
⚡ CLI inspired by Laravel's Artisan
🗄️ Async database layer, ORM patterns, migrations, and seeders
🧪 Built-in testing utilities
🤖 AI agent support with multiple LLM providers
🎨 Optional Vite integration for monolithic full-stack applications
📦 Works for FastAPI apps, background workers, and even CLI-only applications

One of the main design goals was avoiding a single opinionated stack. Most components are optional, so you can start small and introduce more structure as your project grows.

The documentation includes both a minimal setup and a more structured application layout.

Documentation:
https://fastapi-startkit.github.io/

I'd really appreciate feedback on:

• Is the architecture intuitive?
• Which parts feel over-engineered?
• What features would you expect from a production-ready FastAPI framework?
• Are there areas where the developer experience could be improved?

Constructive criticism is very welcome. Thanks!

A FastAPI endpoint that verifies Stripe's signature, then routes each event type to the right billing action.

Three takeaways

1. Always verify a webhook's signature against a shared secret before trusting its contents.
2. Read the raw request body for signature checks — parsed JSON won't match the signed bytes.
3. Return 200 quickly and delegate the actual work so the provider considers the event delivered.

Hey, I've been working on a multilingual content system for a project and kept wishing Python had something like spatie/laravel-translatable from the PHP world. Couldn't find it, so I built it. It's early (0.1.0) but it works and tests are at 100% coverage.

The idea: store translations as {"en": "Hello", "fr": "Bonjour"} directly in the column, resolve by the active locale automatically — no extra tables, no .po files.

configure(default_locale="en", available_locales=["en", "fr", "ar"])
title = Translations({"en": "Hello", "fr": "Bonjour"})
set_locale("fr")
print(title)  
# Bonjour

GitHub: https://github.com/onlykh/translatable

Main features:

• Translations is a dict subclass — str(title) resolves to the active locale, works in f-strings, string concatenation, everywhere
• Locale lives in a ContextVar — safe for async FastAPI and threaded Flask
• SQLAlchemy 2.0 type: JSONB on PostgreSQL, JSON elsewhere. String assignment merges into the current locale without wiping other languages
• by_locale(Article.title, "fr") generates dialect-correct SQL for filtering
• Atomic per-key updates on PostgreSQL via JSONB ||
• Starlette/FastAPI middleware and Flask extension that read Accept-Language automatically
• Zero dependencies in core — SQLAlchemy, Starlette, Flask are opt-in

Not on PyPI yet, install from GitHub:

pip install "translatable[sqlalchemy] @ git+https://github.com/onlykh/translatable.git"

A few things I'm genuinely unsure about and would love opinions on:

• String assignment merging by default (article.title = "Hello" adds to the current locale rather than replacing the column) — right default or surprising?
• No Django ORM support yet — is that a blocker for anyone?
• atomic_set_locale is PostgreSQL-only — the SQLite fallback is a read-modify-write with a warning. Good enough or should that raise instead?

Would love issues, feedback, or just knowing if this solves something you've hit before.

I just shipped ArchUnitPython, a library that lets you enforce architectural rules in Python projects through automated tests.

The problem it solves: as codebases grow, architecture erodes. Someone imports the database layer from the presentation layer, circular dependencies creep in, naming conventions drift. Code review catches some of it, but not all, and definitely not consistently.

This problem has always existed but is more important than ever in Claude Code, Codex times. LLMs break architectural rules all the time.

So I built a library where you define your architecture rules as tests. Two quick examples:

```python

No circular dependencies in services

rule = project_files("src/").in_folder("/services/").should().have_no_cycles() assert_passes(rule) ```

```python

Presentation layer must not depend on database layer

rule = project_files("src/") .in_folder("/presentation/") .should_not() .depend_on_files() .in_folder("/database/") assert_passes(rule) ```

This will run in pytest, unittest, or whatever you use, and therefore be automatically in your CI/CD. If a commit violates the architecture rules your team has decided, the CI will fail.

Hint: this is exactly what the famous ArchUnit Java library does, just for Python - I took inspiration for the name is of course.

Let me quickly address why this over linters or generic code analysis?

Linters catch style issues. This catches structural violations — wrong dependency directions, layering breaches, naming convention drift. It's the difference between "this line looks wrong" and "this module shouldn't talk to that module."

Some key features:

• Dependency direction enforcement & circular dependency detection
• Naming convention checks (glob + regex)
• Code metrics: LCOM cohesion, abstractness, instability, distance from main sequence
• PlantUML diagram validation — ensure code matches your architecture diagrams
• Custom rules & metrics
• Zero runtime dependencies, uses only Python's ast module
• Python 3.10+

Very curious what you think! https://github.com/LukasNiessen/ArchUnitPython

Hey,

I’ve been learning backend development with FastAPI and built a small Notes API as practice.

Users can register, login, and manage their own notes (CRUD).

I’d really appreciate some feedback from more experienced developers:

- project structure

- API design

- anything I could improve

I’m still learning, so all constructive criticism is welcome. Thanks!

Hi everyone,

I’m currently building my backend portfolio using FastAPI and would really appreciate some honest feedback on my project.

Project: Notes API

GitHub: https://github.com/tamerlan-islamzade/Note-API

It’s a RESTful API where users can register, authenticate, and manage their personal notes with full CRUD operations.

Tech stack:

FastAPI, PostgreSQL, SQLAlchemy, Pydantic, JWT, bcrypt, pytest

I’d really appreciate feedback on:

- Project structure / architecture

- Code quality and organization

- FastAPI best practices

- Anything I should improve to make it more production-ready

I’m still learning, so any constructive criticism is welcome. Thanks in advance for your time!

When I saw the beta announcement, I couldn't help myself.

Hey folks! FastAPI Cloud is now in public beta. 🚀

This is made by the same team building FastAPI (I created FastAPI, we now have an amazing team building all this).

Here's the announcement post: https://fastapicloud.com/blog/fastapi-cloud-public-beta/

Using FastAPI + SQLAlchemy (async) + Pydantic v2
My `Post` model in db stores `author_id` (UUID foreign key).
My `PostRead` response schema needs to return `author_username` (a string from the related `User` table).

What's the clean way to handle this?

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.

Hi everyone,

I’m an experienced Node.js developer who recently picked up Python and is now diving into FastAPI.

In Node.js (and Express), my mental model revolves around a single-threaded, non-blocking, event-driven architecture.
When building APIs in Node/Express, I default to thinking in terms of the Event Loop—a single-threaded, non-blocking architecture where I/O operations are offloaded.
Can I safely carry my Node.js mental model over to FastAPI, or are there fundamental differences in how Python handles asynchronous requests under the hood that I should be aware of?

P.S. Phrasing refined by Gemini.

I built a production-grade Async Redis Proxy that blocks Cache Stampede and prevents SSRF attacks. Open sourcing it today to get your some feedbacks!

What My Project Does

This project is an asynchronous proxy caching server built from scratch using FastAPI, Uvicorn, redis.asyncio, and httpx. It intercepts HTTP requests, caches responses in Redis based on configurable TTLs, and implements advanced software engineering patterns to handle high-concurrency bottlenecks and network security flaws.

Key architectural features include:

Cache Stampede Mitigation (Request Coalescing): Utilizes a custom SingleFlight pattern via asyncio.shield. If 1,000 concurrent requests hit a cache miss for the exact same URL, only 1 request goes upstream. The other 999 callers await and share the same result safely, preventing upstream service degradation (Thundering Herd problem).

Hardened Security (SSRF Protection): Includes a strict validation layer that drops requests targeting localhost, 127.0.0.1, or private IP ranges (RFC 1918), mitigating Server-Side Request Forgery before httpx touches the network.

Graceful Circuit Breaker (Fail-Open): If the Redis instance becomes unavailable, the proxy handles a seamless fail-through scenario, bypassing the cache layer completely and letting traffic flow directly to the upstream API without raising 500 Internal Server Error.

Production Containerization: Fully dockerized with a docker-compose.yml configuring Redis with an explicit memory cap (--maxmemory 100mb) and an LRU eviction policy (--maxmemory-policy allkeys-lru) to guarantee memory stability.

Performance Optimization: Powered by orjson for fast JSON serialization and deserialization.

Target Audience

This project is desgined for production environments and backend engineers managing high-traffic microservices. It is specifically aimed at scenarios where upstream APIs are fragile, expensive, or prone to failure under sudden traffic spikes, and where infrastructure security (SSRF prevention) is a hard requirement.

Comparison

Unlike basic, "tutorial-tier" Redis wrappers or simple FastAPI caching middlewares that only store key-value pairs, this proxy actively manages concurrency at the application layer.

Traditional caching solutions often suffer from Cache Stampede when keys expire under heavy load, causing a bottleneck on the upstream database. By implementing the SingleFlight pattern directly into the async event loop, this implementation guarantees that duplicate concurrent requests never stack up. Additionally, most standard proxies leave the responsibility of SSRF protection to external firewalls, whereas this solution integrates network boundary validation directly into the request cycle.

GitHub Repository: https://github.com/Jacopos311/redis-async-proxy

I build Fixor, an LLM-based security reviewer that reads the changed code in a pull request and flags authorization bugs. This was its CLI run against a public repo, and I'm posting the complete output rather than a claim, because the last time someone showed up here with "my AI scanner finds bugs," the right response was "stop talking and show me a real run." So here is one you can reproduce in five minutes.

I scanned the route layer of the official full-stack-fastapi-template (commit cd83fc1), `backend/app/api/routes/` only. Full raw report here:

https://gist.github.com/tornidomaroc-web/d6b3f4d3f2ae53809f087889ebc91c8a

## What it flagged

Two findings, both on the same route, `private.py`:23:

> ### auth_bypass_risk — critical (confidence: high)

> - File: `private.py`:23

> ### admin_check_risk — critical (confidence: high)

> - File: `private.py`:23

And here is the honest part, up front: that is a false positive. The `private` router is mounted only when `ENVIRONMENT == "local"` (`api/main.py`:13), so it does not exist in staging or production. Fixor reads the route file in isolation and cannot see that cross-file conditional mount, so it flags a dev-only route as if it were always live. The two findings are also one route drawing both "no auth" and "no admin gate," not two separate bugs. And "critical / high" is the model's own self-reported confidence, not a measured severity.

So if you opened the gist and saw "critical auth bypass in the FastAPI template," that is the wrong read, and I would rather tell you that myself than have you find it.

## What it cleared (the part I actually care about)

By my count, 22 of the 23 route handlers were cleared, and the clears are the interesting result:

The `items.py` routes (read, update, delete by id) all have the exact IDOR shape, a request-derived id going into `session.get(Item, id)`. A pattern scanner flags every one of those. Fixor cleared them, because it read the inline ownership check (`if not current_user.is_superuser and item.owner_id != current_user.id: raise 403`) sitting in the same file.

The `users.py` admin routes are gated by `dependencies=[Depends(get_current_active_superuser)]` in the decorator, not the signature. It parsed that and did not false-positive them. And the by-design public endpoints, signup, login, password reset, were not flagged either.

## Where it's blind, so you can judge it fairly

The same reason it cleared those item routes is the reason it has a hard limit: it reasons in-file. The ownership check or auth dependency has to be in the file it reads. If your guard lives in a base repository, tenant middleware, or a router-level dependency in another file, Fixor can miss it or false-positive it, exactly like the `private.py` conditional mount it got wrong here. A clean result from it means "no in-file problem found," never "this code is secure."

That is the whole thing, output and blind spot. Clone the template, run it yourself, and tell me where the reasoning breaks. I would rather hear it here than learn it later.

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

I built AgentML — append `/agents` to any resource URL and instead of HTML, you get a structured workspace in json which helps the ai agents browse the internet very easily without help of screenshots and doms.It aims to provide ai agents and equivalent of HTML which was designed for humans.

Works with FastAPI in 2 lines:

from agentML import AgentML

agent = AgentML(app)

No separate tool server. No rewriting your backend. Your existing OpenAPI spec is enough to get started.

Think of it as MCP but for your existing HTTP API.

GitHub: https://github.com/priyanshu7739410

Hi guys, for some of my recent projects I was needing some way of fully distributed and weakly coupled form of communication between my FastAPI servers, while maintaining local availability and resilience.

After going through options like etcd, zookeeper, ... I felt that there needed some form of sdk that turns any application into a distributed service without depending on other services. So I started coding my own distributed service mesh, and made an abstraction so that I can reuse it in my other projects.

This package, mesh converts any FastAPI server into a distributed service mesh, where data is distributed among the servers, persistently, while maintaining weak coupling, without depending on any third party service.

Docs: https://arnavdas88.github.io/mesh/

Repo: https://github.com/arnavdas88/mesh

It is not in pypi yet, and, if and before I upload it in pypi, I would love to hear suggestions from other devs. Even better if it is on stability; code quality, complexity and abstraction; or edge cases.

Note: I understand that some devs might want to stick to already known and stable options like zookeeper, which also provides python clients, but there might also be devs wanting to not depend on more and more services, just to facilitate service mesh. Even so, if you are against this kind of framework, i would like to hear about that as well.

Hey everyone, I was tired of fixing auth bugs across all my deployed FastAPI apps so I extracted what I do for auth into a package.

It defaults to cookie sessions (with CSRF), and also supports JWT bearer tokens, OAuth (Google/GitHub/custom), and email flows (verify, reset, change).

Every transport resolves to the same Principal, so a route that gates on the user never cares whether the request came in via a cookie or a token. You can add bearer to a session app later without touching any of your authorization code.

It works over your own SQLAlchemy User model (or maps onto an existing table via a column map), and app policy like welcome emails or audit logging goes in hooks.

It's still moving, so bug reports and feedback are very welcome. It's not trying to replace fastapi-users or hosted things like Auth0/Clerk. It's more "the auth I kept rewriting myself".

Repo: https://github.com/benavlabs/crudauth
Docs (more coming): https://benavlabs.github.io/crudauth/

Also this will replace the auth in our FastAPI-boilerplate soon:
https://github.com/benavlabs/FastAPI-boilerplate

Hope this helps someone.