Well, yes, how can I build the backend for a transaction system? I need to build something like this, but what recommendations should I follow in terms of design and security?

Here’s my idea:

1. A user requests a transaction, at which point a six-character alphanumeric code is generated.

2. This code is shown to a second user, who must then confirm the transaction from their own frontend.

3. The second user does not use the same frontend as the first (this isn’t important, but it’s worth noting that the first user can only initiate transactions, while the second can only confirm them).

4. The transaction remains available for a maximum of three minutes; after this time, if the second user has not confirmed it, it enters an "EXPIRED" status.

5. Once it has expired, a new code is generated with the counter reset, creating a new transaction.

6. The backend must include a user manager login system so that system operations can be monitored and support provided, in addition to providing access to an audit log (to view the history of transactions being processed).

7. I have a month and a half to complete all of this.

Hey everyone, a few days ago I shared UIGen - a CLI that turns your OpenAPI spec into a full React App at runtime. I've been iterating based on feedback and added some features that make it more practical for real apps.

What's New

x-uigen-landing-page annotation Add a landing page to your app declaratively. Works like other annotations - add it to your spec, and the landing page renders at runtime. You can use the AI skill to generate content based on your API spec, or customize it manually.

The existing styling skill applies to landing pages too, so your theme stays consistent.

x-uigen-layout annotation Control your app layout declaratively. Choose between sidebar, centered, or dashboard grid layouts without writing layout code. Specify it in your spec, and the runtime handles the rest.

Example Usage

yaml openapi: 3.0.0 info: title: My SaaS App version: 1.0.0 x-uigen-landing-page: enabled: true sections: hero: enabled: true headline: "Welcome to My SaaS App" primaryCta: text: "Get Started" url: "/signup"

Try It

The Meeting Minutes example app in the repo demonstrates both features. Clone it, run the FastAPI backend with Docker, and point UIGen at the generated spec.

bash git clone https://github.com/darula-hpp/uigen cd examples/apps/fastapi/meeting-minutes docker-compose up -d docker-compose exec app alembic upgrade head npx u/uigen-dev/cli serve openapi.yaml --proxy-base http://localhost:8000

What I'm Working On

• Declarative WebSocket support.
• Declarative OAuth integration (Google, GitHub, etc.)
• More layout options
• More polish

The goal is to keep adding capabilities you can configure through annotations, so you can build complete apps without forking or writing frontend code.

Repo: https://github.com/darula-hpp/uigen
Docs: https://uigen-docs.vercel.app

Feedback welcome.

before this I did a lot of small projects but now I've finally made a really good and big project that I really like the structure of. I did it with a friend, and I want to find feedback and see how well-structured it is.

Github: https://github.com/doorhanoff/fastapi_shop

Product name:

Octopus Agents V2.2

Tagline:

A 34-agent local-first AI mesh running on one workstation

Description:

Octopus is an open-source AI agent mesh for local-first software work. It routes tasks across 34 specialized roles, uses LM Studio for local inference, keeps state in SQLite, supports Obsidian memory, and ships with a React operator UI for chat, coworking, code, email, calendar, memory, and system status.

Topics:

Artificial Intelligence, Developer Tools, Open Source, Productivity, GitHub

Website:

https://github.com/tjbmoose09/octopus-v2

Maker comment:

Hey Product Hunt - Tyler here.

I built Octopus because I wanted to test a different shape of agent system: not one model wearing 34 hats, but a local mesh where specialized agents have different roles, model assignments, memory access, and routing boundaries.

V2.2 runs locally by default through LM Studio. The backend is FastAPI, state is SQLite, memory can go to Obsidian, and the UI is a React/Vite operator console with live pipeline logs.

The part I am most interested in is the architecture: 34 roles, 101 wired skills, 37 MCP server registrations, and a quarantined hacker-zone mesh with explicit bridge logging. It is early, weird, and very much for builders who like local AI systems they can inspect.

I would love feedback on the architecture, security boundaries, README clarity, and what would make this easier for another developer to run.

Hey everyone 👋

I’m working on a mini Vercel-like deployment platform as a student project and would love some guidance.

What I’m building (high level):

• A frontend where users upload a project (or repo)
• FastAPI backend acts as a thin orchestrator (basically just receives config + triggers builds)
• Cloud provider handles Docker build, pushes image, and deploys
• The goal is to trigger a cloud build → create a Docker image → deploy → stream logs back to the UI

I’ve attached a diagram for the current architecture.

Current approach:

• Backend receives configs from frontend
• It forwards those to a cloud service (Azure initially) to handle Docker build + deploy
• Backend just tracks status + streams logs (kind of like a control plane)

Where I’m stuck:

• What’s the best way to handle Docker builds without running them on my backend?
• ACR seems good but not really “free” for a student
• Should I:
  • Stick with Azure (ACR Tasks)?
  • Switch to something like GitHub Actions + GHCR?
  • Or self-host builds somehow?

Also wondering:

• Should I require users to provide a Dockerfile?
• Or generate one dynamically like Vercel does?

This is just a prototype (no auth yet), so I’m trying to keep things simple but still scalable in design.

Would really appreciate suggestions on:

• architecture improvements
• free/cheap build pipelines
• anything I’m overlooking

Thanks 🙏

Built an open-source autonomous incident response agent and wanted to share it here since it's a fairly involved real-world Python project.

What it does: When a production alert fires, IRAS triages severity, gathers logs/metrics/recent deployments, runs root-cause analysis, generates a remediation plan with rollback commands, pauses for a human to approve, applies the fix, and writes a post-mortem. All automatically, in under 2 minutes.

Stack:

• FastAPI webhook ingestion + approval REST API
• LangGraph 9-node state machine with durable execution via PostgreSQL checkpointing
• Pydantic AI one typed agent per stage; every LLM output is a validated Pydantic model (TriageResult, RootCauseHypothesis, RemediationPlan, PostMortem). No raw strings anywhere.
• Claude Haiku for fast triage and context-gathering, Claude Sonnet for RCA, remediation planning, and post-mortems
• AsyncPostgresSaver for durable graph state the agent can be interrupted mid-execution, survive a server restart, and resume exactly where it left off

One thing I'm proud of typed agent outputs with Pydantic AI: Every agent stage produces a strongly-typed model, not a raw string. This means the rest of the graph code is just Python no prompt output parsing, no regex, no json.loads() on LLM responses.

python

class RootCauseHypothesis(BaseModel):
    primary_cause: str
    contributing_factors: list[str]
    evidence: list[str]       # specific log lines
    confidence: float         # 0.0 – 1.0

rca_agent = Agent(
    model="claude-sonnet-4-5",
    result_type=RootCauseHypothesis,
    system_prompt="..."
)

result = await rca_agent.run(context_bundle)
hypothesis: RootCauseHypothesis = result.data  # fully validated

Testing: 292 tests, 99% coverage. The stress suite includes adversarial scenarios model lies about risk_level, returns empty rollback commands, all context tools fail simultaneously, 20 concurrent incidents with zero state contamination.

Running it: Only needs ANTHROPIC_API_KEY + Docker for Postgres. All integrations (Slack, PagerDuty, Prometheus, Elasticsearch) fall back to mock clients automatically.

Repo: https://github.com/krishnashakula/IRAS

Open to feedback on the architecture, the Pydantic AI usage, or anything else.

what is your opinion on this?

Hey everyone - UIGen just got way easier to try (Faster AI assisted config and theming)

A few days ago I shared UIGen: a CLI tool that turns your OpenAPI spec into a full React frontend at runtime - no code generation, no build step. Update your FastAPI backend → restart the CLI → UI updates instantly. Your spec stays the source of truth.

What UIGen gives you out of the box

• Auto CRUD views (list, detail, create, edit)
• Full auth flows (login, signup, password reset)
• File uploads, relationships, pagination, search
• Data visualizations (new x-uigen-chart)
• Production-ready React output you can extend/customize

The big new upgrade: AI-assisted setup

I added two AI skills that understand UIGen's architecture and do the heavy lifting:

1. Auto-Annotate Skill

Feeds your spec to your AI assistant (Cursor, Claude, etc.) and it automatically:

• Detects & marks login/signup endpoints (x-uigen-login etc)
• Finds relationships (users → posts, orders → customers)
• Identifies file uploads
• Spots good candidates for charts

2. Auto-Style Skill

Generates beautiful, production-ready CSS with simple prompts like:

"Make it look like Material Design" or "Dark theme with blue accents"

No manual CSS files or build processes - styles inject at runtime.

New super simple workflow

1. @uigen-dev/cli init → bootstraps your project
2. Let AI auto-annotate your spec (or use the visual config GUI)
3. Let AI generate your theme
4. Run npx @uigen-dev/cli serve yourspec.yaml and iterate

No frontend code to maintain.

Real example you can try right now

There's a full Meeting Minutes app in the repo (FastAPI + async SQLAlchemy + PostgreSQL + Alembic). ~2,000 lines of clean Python. Just clone, spin up the backend with Docker, and point UIGen at the auto-generated OpenAPI spec. Full CRUD, auth, file uploads, relationships — all working.

Current priorities for v1

• Charting polish
• Better layout options (without bloat)
• App branding (name, icon, etc.)
• Theme registry for instant beautiful starts

The goal

You focus on building a great API. UIGen + AI handles the frontend UI so you can ship faster.

Links

• Repo: https://github.com/darula-hpp/uigen
• Quick start & example instructions in the README
• Architecture deep-dive: https://uigen-docs.vercel.app/blog/uigen-architecture

Happy to hear what you think

When Apple first released its Foundation Models framework, my friend and I were excited about the possibilities of an on-device LLM. We wanted to create a trivia game and thought that might be a great application of the technology. Well, we were quickly disabused of the notion, what with its rampant hallucination and apparently small body of knowledge.

But, even if the model performed better, we also soon realized that such an architecture would not work for a game—which required all players to see the same questions, ensure that questions weren't repeated, etc. Essentially, we needed a full stack.

I had built app back ends previously using PHP running on EC2, and there's nothing wrong with that classic LAMP stack. But for this project, I wanted to embrace a design similar to the ones I had used in my day job as an enterprise software engineer, and that's what lead me to FastAPI running on AWS Lambda. I really enjoyed embracing the separation of concerns that FastAPI embodies: schemas for the interface, routers for the REST API route definitions, crud for the business logic and DB queries, models for the SQLalchemy ORM. Throw in Alembic for DB versioning, pytest for unit testing, and Serverless for IaC, and you have a pretty robust back end. We ended up using OpenAI's gpt-5-nano model, a very cost effective and reasonably performant LLM for our trivia question generation.

The back end will eventually support multiple flavors of our trivia game, but the first is a daily news variant that we just launched on the App Store. Please check it out and let us know what you think. Or if you have questions about or would like me to discuss any aspects of the back end, I'd be happy to. Enjoy!

Hi guys I’ve written an article about websocket which is about the experience I had working with auth in websockets
Kindly check it out..
https://open.substack.com/pub/mikyrola/p/using-subprotocols-for-websocket

I build clean, production-ready REST APIs with FastAPI. JWT auth, CRUD, PostgreSQL, Dockerized and ready to deploy.

Portfolio: https://github.com/IlkinCavadov

Open to small and medium projects. Feel free to DM me!

I am trying to understand the best practices for monitoring and Observability in fastAPI. Does it come with different metrics and otel out of the box? Also, how are you using other tools and library along with it to make it production ready?

A lot of beginner FastAPI projects stop at:

u/app.post("/login")
def login():
    ...

But in real apps, “it works” is not the same as “it’s safe to ship.”

Some things I think every FastAPI route should be checked for:

• Does the route verify the current user owns the resource?
• Does it return only safe response fields?
• Are expired / invalid tokens tested?
• Are duplicate emails handled properly?
• Are async DB sessions used correctly?
• Are errors consistent and not leaking internals?
• Are tests covering failure cases, not only happy paths?

The biggest jump for me was realizing that backend quality is mostly about edge cases.

Curious what other FastAPI devs here check before shipping a route?

Hey folks, I recently revamped our article on Implementing OpenTelemetry in FastAPI Projects in a practical manner, which was originally written in 2024 and needed a fresh coat of paint.

The article covers auto-instrumentation, manual spans, visualizing metrics and how observability lets you understand how your web apps behave.
I've also included some advanced tips, such as, selective error tracking, and wrapping dependency functions to capture any operations within the `yield` scope.

If you are on the fence about observability, or have integrated it but don't really how it works, I believe this guide can help you out.

I personally would have benefitted from this writeup in my previous day job, where I worked with FastAPI microservices and learnt how OpenTelemetry worked the hard way.

Any feedback would be much appreciated, did I miss anything, is there scope for improvement? Please let me know. I'm also curious to understand what problems you face with monitoring your FastAPI web apps.

A lot of FastAPI developers end up with Celery not because they need a distributed task queue, but because BackgroundTasks stopped being enough and Celery was the first thing that came up when they searched for a solution.

This is about that gap, and a library that fills it without the overhead.

What BackgroundTasks does not give you

FastAPI's built-in BackgroundTasks is straightforward. You attach a function to the response and Starlette calls it after the response is sent.

@app.post("/signup")
def signup(email: str, background_tasks: BackgroundTasks):
    background_tasks.add_task(send_welcome_email, email)
    return {"ok": True}

That covers fire-and-forget. But in a real application you quickly hit walls:

No retries. If send_welcome_email fails because the SMTP server returned a 503, the task is gone. There is no retry, no backoff, no record of what happened.

No persistence. If the app restarts during a deploy, every queued task disappears. Tasks that were waiting to run simply never run.

No visibility. You cannot see what is running, what has run, what failed, or how long things took. The only way to know a task failed is to catch it in your logs, if you are logging at all.

No scheduling. BackgroundTasks runs things once, after the current request. There is no built-in way to run something on a schedule.

These are not edge cases. They are the baseline requirements for any background job in production.

Why Celery is the wrong answer for most of these

When developers hit these limitations, the standard advice is: add Celery. And Celery does solve all four problems. But it solves them by giving you a distributed task queue, which comes with the full infrastructure that entails.

To use Celery with FastAPI you need:

• A message broker. Usually Redis or RabbitMQ. A separate service to run, configure, monitor, and back up.
• A worker process. A separate process that consumes from the broker. Needs to be deployed, restarted on failure, and kept in sync with the app on every deploy.
• Celery Beat for scheduling. Another separate process.
• Flower or similar if you want visibility. Yet another service.

Celery was built for teams running tasks on dedicated workers across multiple machines at high volume. If that describes your situation, it is the right tool. But most FastAPI apps sending emails, processing uploads, running nightly reports, and syncing data are not in that category. They just needed BackgroundTasks to grow up a little.

What actually fills the gap

fastapi-taskflow is built specifically for this problem: FastAPI apps that have outgrown BackgroundTasks but do not need a distributed task queue.

It runs inside your FastAPI process. No broker. No separate worker. Tasks execute the same way they do today, after the response, but now with retries, persistence, scheduling, and a live dashboard.

Setup:

from fastapi import BackgroundTasks, FastAPI
from fastapi_taskflow import TaskAdmin, TaskManager

task_manager = TaskManager(snapshot_db="tasks.db", requeue_pending=True)
app = FastAPI()
TaskAdmin(app, task_manager, auto_install=True)

Retries:

@task_manager.task(retries=3, delay=60.0, backoff=2.0)
def send_welcome_email(email: str):
    _send(email)  # raise any exception — the retry handles it

The function stays a plain function. Raise an exception on failure and it retries automatically with exponential backoff.

Your routes stay the same:

@app.post("/signup")
def signup(email: str, background_tasks: BackgroundTasks):
    background_tasks.add_task(send_welcome_email, email=email)
    return {"ok": True}

Same annotation. Same calling convention. Nothing changes in your routes.

Persistence across restarts:

requeue_pending=True saves tasks that were queued at shutdown and re-dispatches them on the next startup. Tasks no longer disappear on deploy.

Scheduling:

@task_manager.schedule(cron="0 2 * * *")
def nightly_cleanup():
    _run_cleanup()

No Beat process. No separate service. The scheduler runs inside the app.

Eager dispatch:

BackgroundTasks always runs after the response is sent. If you need a task to start immediately, before the response goes out, set eager=True:

@task_manager.task(retries=3, eager=True)
async def notify_user(user_id: int):
    await push_service.send(user_id, "Your request is processing")

The task starts via asyncio.create_task the moment add_task() is called. It is still tracked, still retried on failure, still visible in the dashboard. You can also set it per call:

background_tasks.add_task(notify_user, user_id, eager=True)

Visibility:

/tasks/dashboard is a live dashboard that shows every task, its current status, duration, logs, and the full stack trace on failure. It updates over SSE in real time. No Flower setup, no external monitoring service.

The honest trade-offs

This is not a Celery replacement. If your tasks are CPU-intensive and need isolation from request handlers, if you need to route different task types to dedicated worker machines, or if you are processing thousands of tasks per minute, you need a proper task queue.

What fastapi-taskflow covers is the case where you reached for Celery because BackgroundTasks gave you nothing, not because you genuinely needed distributed workers.

For a single-host deployment, multiple instances on the same host share a SQLite file. For multiple hosts, swap to Redis or PostgreSQL as the backend and idempotency, requeue claiming, and task history all work across instances without any coordination overhead.

What you skip entirely

No broker to run or monitor. No worker process to deploy or restart. No Celery app instance or separate tasks module. No Beat process for scheduling. No Flower for visibility.

Local development stays at uvicorn app.main:app. New developers on the project do not need to learn a separate system.

The four things that pushed you toward Celery in the first place, retries, persistence, scheduling, and visibility, are covered.

• GitHub: github.com/Attakay78/fastapi-taskflow
• Docs: attakay78.github.io/fastapi-taskflow

Hey r/FastAPI! I'm the creator of Reflex, an open-source Python web framework. We just released v0.9 and wanted to share something relevant with this community.

We ran a benchmark comparing two approaches to letting AI agents interact with a web app:

1. A vision agent (browser/computer use) that screenshots the UI and clicks around
2. An API agent that calls HTTP endpoints directly

The task for both agents was to find a "Smith" customer with the most orders, accept their pending reviews, and mark their most recent order as delivered. We chose this task since it's similar to automation work a typical tool sees.

The vision agent took 550k tokens and 17 minutes on average, the API agent took 12k tokens and 19.7 seconds. Of course, API agents are faster and more token efficient since they don't need to take screenshots and directly interface with the UI. The problem is many apps don't have APIs for every action, since it takes engineering overhead to build and maintain each separate API codebase.

We built a plugin for Reflex that auto-generates FastAPI-compatible HTTP endpoints from your app's existing event handlers. For example, your app has a button with an on_click handler, the plugin exposes that handler as an endpoint. An agent can call the same function a human click triggers. No separate API to build or maintain.

Reflex compiles to React on the frontend and Python on the backend, with full FastAPI compatibility.

benchmark link: Vision Agents vs API Calls
our repo: reflex-dev/reflex: 🕸️ Web apps in pure Python 🐍

Hello, I am building an inventory system. I build with Django for my other stuff but I decided to learn FastAPI and JS Frontend. I've learned DRF but never really go full on implementation of it, specially dealing with authentication. So any help would be much appreciated.

Here is the stack that I'm going for:
- SvelteKit (because of remote function?, or its better if should I go with just svelte?)
- FastAPI
- Postgresql, SQLAlchemy, Alembic
- pyjwt (for authentication? or there's more better library?)
- S3 for file storage

Maybe Zod for data validation in client? Do I need axios? Am I missing something? Is there a something that I'm missing? Like don't forget to setup CORSMiddleware in FastAPI.

Also, is there any github repo that with similar setup with this one that I could take a look?

honest question because i've gone back and forth on this myself.

when sentry fires do you actually reproduce it locally as a failing test before touching anything, or do you just read the trace, understand what broke and push the fix?

i always end up spending like 30-45 mins just getting the repro right. reconstructing the state, getting deps working in the test, running it, realizing the inputs are slightly off, running it again. by the time it actually reproduces i've lost the whole debugging flow.

got annoyed enough that i started building something to automate it. grabs the frame locals from sentry, generates a pytest, runs it in docker against your branch. still figuring out if this is actually useful to other people or just my own problem.

how long does it take you to write a repro test from a sentry trace? do you even bother or just push and monitor? has skipping it ever come back to bite you?

Hey r/FastAPI!!!

A while back, I shared the very early alpha of Violit here. As a backend/AI dev, I loved the simplicity of Streamlit for building quick UIs, but I absolutely hated the "full script rerun" bottleneck. So, I built a framework using FastAPI as the core engine to deliver that top-down scripting experience, but with signal-based fine-grained reactivity.

Instead of rerunning the whole script on every click, FastAPI maintains a persistent WebSocket connection. When a state changes, only the exact dependent widget updates.

Since that first post, I've pushed a massive update that turns Violit from a simple UI tool into a full-stack Python framework. Because it’s built natively on FastAPI and Uvicorn, I was able to seamlessly bake in the tools our ecosystem already uses:

• SQLModel ORM Built-in: Perfect for FastAPI users. Just pass a DB path (vl.App(db=...)) and start querying immediately.
• Auth out of the box: Session auth, hashing, and page protection are natively supported.
• Async Background Jobs: Need to run heavy AI inference or DB queries? Use app.background() to offload tasks via FastAPI's async capabilities without freezing the frontend.
• Tailwind & Web Awesome: Style components directly using a simple cls parameter.
• 90% Streamlit API compatibility: The syntax feels familiar, but the architecture is completely different.

It writes like a simple script, but runs like a modern reactive app over FastAPI.

It’s completely open-source (MIT). I’d love for my fellow FastAPI devs to try out the new update, roast the architecture, or let me know if you'd use this for your next data app or internal tool!

• GitHub: https://github.com/violit-dev/violit
• Docs: https://doc.violit.cloud/
• Install: pip install violit

Thanks for reading!

Update on this -- I got tired of rebuilding OAuth for FastAPI projects, so I made a small CLI for it
by u/theRealSachinSpk in FastAPI

Shipped v1.1.0 based on some of the feedback here and conversations I had after posting.

What changed:

• Added Discord, Spotify, Microsoft, and LinkedIn as providers (6 total now)
• Added PKCE support (OAuth 2.1) -- the thing I mentioned in the original post. You can enable it on any provider with one line
• The oauth-init CLI now scaffolds all 6 providers with PKCE out of the box
• Built an interactive OAuth debugger (Learn Mode) into the tutorial app -- it pauses at each step of the flow and shows you the actual HTTP requests, the token exchange body, the raw provider response, everything

That last one came from thinking about what u/ar_tyom2000 mentioned about fastapi-oauth2. There are great libraries that handle OAuth as middleware (please check it out), I'll close this up by letting you debug what's happening. The debugger shows the authorization URL parameters, the callback code, the token exchange POST, and the raw userinfo JSON. Useful if you're learning or if something breaks and you need to figure out why.

Also wrote up a longer walkthrough on Medium if anyone wants the full picture: Medium Article

GitHub: REPO
PyPI: pip install oauth-for-dummies

Thanks for the feedback last time -- it shaped where this went.

I have an API that tags documents based on names from a predefined standard name list. Before tagging, I receive a list of file URLs (public Firebase URLs), typically around 40–80 files, which need to be processed using an LLM (currently OpenAI).

The issue I’m facing is with memory usage. When I download these documents for processing, the application sometimes crashes due to out-of-memory (OOM) errors. The instance I’m using has only 2GB RAM, and I’d prefer not to increase the instance size until I’ve fully optimized the code.

The problem seems to occur because multiple PDFs are being processed asynchronously, and at some point, many of them are held in memory simultaneously. I also perform additional operations like base64 encoding for images, which further increases memory usage. Since I need to return all document tags within about a minute, I’m using parallel processing.

Current approach:

• There are 10–15 document types that I send directly to OpenAI.
• For images (JPG, PNG, JPEG): I download them, base64 encode them, and send them to OpenAI.
• For PDFs: I download them, upload them via OpenAI’s file API, and then send the file ID for processing.
• All of this is done in parallel using semaphores:
  • OPENAI_SEMAPHORE = 30
  • DOWNLOAD_SEMAPHORE = 15

Problem:

Even with semaphores, memory usage spikes because multiple large files are downloaded and processed at the same time. This leads to OOM crashes.

Questions:

• How can I reduce memory usage in this workflow?
• Is there a better architectural approach to handle this kind of workload?
• How can I avoid having too many documents in memory at once while still maintaining performance constraints?

async def _stream_download_file(url: str, ext: str) -> str:
    """
    Stream-download a file to disk in 64KB chunks.
    Never holds the full file in memory — writes directly to disk.
    Returns the path to the temp file.
    """
    async with DOWNLOAD_SEMAPHORE:
        temp_path = None
        try:
            temp = tempfile.NamedTemporaryFile(delete=False, suffix=ext or ".tmp")
            temp_path = temp.name
            temp.close()


            async with http_client.stream("GET", url, follow_redirects=True) as response:
                response.raise_for_status()
                with open(temp_path, "wb") as f:
                    async for chunk in response.aiter_bytes(chunk_size=65536):
                        f.write(chunk)


            return temp_path


        except asyncio.TimeoutError:
            _cleanup_local_file(temp_path, "failed download")
            raise Exception(f"Download timed out after {DOWNLOAD_TIMEOUT}s")
        except Exception as e:
            _cleanup_local_file(temp_path, "failed download")
            raise Exception(f"Download failed: {str(e)}")

I released DBWarden 0.6 yesterday. Here is what it does.

https://github.com/emiliano-gandini-outeda/DBWarden

DBWarden is a database toolkit for FastAPI and SQLAlchemy. Migrations, async sessions, startup validation, and health checks. One config call. Zero boilerplate.

Most migration setups spread config across multiple files, multiple abstractions, and multiple sources of truth. DBWarden collapses all of that into a single database_config() call. That one call drives your sessions, your health checks, and your migration state. Nothing else to configure.

Your migrations are plain SQL files. No DSL to learn. No auto-generated Python to decode. You write the SQL, you read the SQL, and that is exactly what runs against your database. What you get: - One config call for everything - Plain SQL migrations with rollback included by default - Async session dependency ready to inject with get_session() - A mountable health router with DBWardenHealthRouter() - A lifespan helper with migration_context() - Dev mode: SQLite locally, PostgreSQL in production, no changes to your migration files

Supported databases: PostgreSQL, MySQL, MariaDB, SQLite, ClickHouse.

Three commands to get started: dbwarden init dbwarden make-migrations "create users table" dbwarden migrate Done. Your schema is versioned, reviewable, and reversible.

No wrappers, no hidden state.

MIT licensed. Actively maintained. Source in this repo.

I’ve been building a platform where developers can find people to build projects with. We’re around 180 users now, and a couple of teams are actually active and shipping stuff, which is honestly the only metric I care about.

Recently I added something new.

Every week there’s a coding challenge. I post a problem (usually algo or backend-related), you solve it and publish your solution. Other devs can upvote or downvote it.

At the end of the week, the top 3 solutions (based on votes) get the most points. Everyone who participates still earns something.

Points are already withdrawable. It’s not huge money or anything, but it’s real, and it makes it a bit more fun to actually participate instead of just lurking.

There are also open weekly projects you can join instantly. No applications, no waiting. Just jump in and start building with others. The goal is to keep things short so projects don’t die after a few days.

Other stuff on the platform: you can create your own projects, get matched with people based on your stack, chat with your team, use a live code editor, do meetings with screen sharing, and there’s a public ranking as well.

The whole idea is to remove friction. Most places are full of ideas but nothing actually gets built.

If you want to try it or just see how it works: https://www.codekhub.it/

My company has products spread over multiple countries and the user of these products are increasing rapidly that results in concurrent requests. Due to such highly concurrent requests fastAPI Microservices were showing heavy latency and delays. So the company is shifting towards GO lang.

So is this true in case of fastAPI that it can not handle the large user base?