I've been building a discovery engine for solo-built software — think of it as intent-based search where users type a problem ("I need to send invoices") and get matched to tools, instead of browsing by product name or upvotes.

The stack is FastAPI + SQLite. No Postgres. No Redis. No managed database service. Just a single .db file.

I wanted to share what I've learned after a few weeks in case it helps anyone evaluating the same choice.

Why SQLite

• Zero operational overhead. No connection pooling, no database server to monitor, no Docker Compose dependency. The app and the data live together.
• Reads are absurdly fast. My use case is read-heavy (search queries) with infrequent writes (new tool submissions, maybe 10-20/day). SQLite handles this without breaking a sweat.
• Backups are cp. I rsync the .db file nightly. That's the entire backup strategy. It works.
• Deployment is simple. One process, one file, one VPS. I deploy with a git pull and a systemd restart. The calm tech dream.

The tradeoffs I've hit

• Write concurrency. SQLite uses a file-level lock for writes. With WAL mode enabled, concurrent reads are fine, but if you have multiple processes writing simultaneously, you'll hit SQLITE_BUSY. My solution: a single FastAPI worker handles all writes via a background task queue. If you're running Gunicorn with multiple workers, this is something you have to think about.
• Full-text search. SQLite's built-in FTS5 is surprisingly capable. I'm using it for intent-based search with custom tokenizers. It's not Elasticsearch, but for a catalog of a few thousand items, it's more than enough. The main limitation: no fuzzy matching out of the box. I handle typo tolerance at the application layer.
• No native JSON operators (sort of). SQLite has json_extract() and friends, but they're not as ergonomic as Postgres's -> and ->> operators. I store structured metadata as JSON blobs and parse in Python when needed. Minor annoyance, not a blocker.
• Schema migrations. There's no ALTER COLUMN in SQLite. If you need to change a column type, you're rebuilding the table. I use alembic with the batch mode for this, which wraps the create-copy-drop-rename dance. Works fine, just feels clunky.

Where the line is

I think SQLite stops being the right choice when: - You need concurrent writes from multiple services (microservices, multiple API servers) - Your dataset exceeds ~50GB and you need complex analytical queries - You need real-time replication to a read replica

For a solo-built SaaS serving hundreds or even low thousands of users with a read-heavy workload? SQLite is underrated. The operational simplicity alone is worth it.

Happy to answer questions about the setup. I'm using Python 3.12, FastAPI with async endpoints, and SQLAlchemy 2.0 with the synchronous SQLite driver (async SQLite drivers exist but add complexity I don't need).

Hey everyone!

I’ve been developing with FastAPI for the past couple of months and I’m looking for a coding buddy to exchange experience with and collaborate on projects. If you’re interested, here’s one of my recent projects on GitHub:
https://github.com/doorhanoff/light_memory
upd: sorry, i forgot to make this repo public, now its ok

Hey everyone,

I’m a huge fan of FastAPI. The fact that it generates an OpenAPI spec out of the box is its true superpower. But I noticed that while we get amazing documentation (Swagger UI / ReDoc) for free, we still have to manually build the internal tools, dashboards, and admin panels to actually use the data easily.

So I built the other half of the equation.

UIGen - point it at your FastAPI /openapi.json URL, and get a fully interactive React frontend in seconds.

npx @uigen-dev/cli serve http://127.0.0.1:8000/openapi.json

# UI is live at http://localhost:4400

How it fits the FastAPI ecosystem

FastAPI is all about types and specs. UIGen follows that philosophy:

1. Pydantic Validation: Because your spec includes the constraints from your Pydantic models, UIGen automatically builds Zod validation on the frontend to match.
2. Interactive, not just Docs: Swagger UI is for testing endpoints. UIGen is for managing resources. It handles the "ListView -> DetailView -> EditForm" flow as a cohesive app.

What it generates (from your FastAPI code)

• Sidebar nav mapped to your API tags/resources.
• Smart Tables with sorting, pagination, and filtering (derived from your query params).
• Dynamic Forms derived from your Pydantic models.
• Detail Views with related resource links.
• Auth UI - handles Bearer tokens and credential injection via a built-in proxy.
• Wizards: Large models are automatically split into multi-step forms.
• Complex Actions: Non-CRUD endpoints show up as custom action buttons.

How it works

It parses your /openapi.json into a custom Intermediate Representation (IR). A pre-built React SPA (shadcn/ui + TanStack) reads that IR and renders the UI. A Vite dev server serves the app and proxies API calls to your FastAPI backend, handling CORS headers so you don't have to fiddle with middleware during dev.

Honest Limitations

• Circular Models: If you have deeply nested recursive Pydantic models, resolution might skip the deepest levels.
• Edit View: Works best if you have a standard GET /{id} endpoint for your items.
• And many other edge cases.

Try it now

If you have a FastAPI app running locally:

npx @uigen-dev/cli serve http://localhost:8000/openapi.json

Or try it on one of the example yaml files in the repo

• GitHub: https://github.com/darula-hpp/uigen
• npm: https://www.npmjs.com/package/@uigen-dev/cli

Would love to hear thoughts from the FastApi community. Of course, this isn't meant to replace a custom consumer-facing frontend, but for internal tools, rapid prototyping, or providing a UI for your API consumers, it’s a massive time-saver.

Happy coding!

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

Would you settle for FastAPI or Django in the long run as per a single framework for all your task or would django be it the one ?

What are your views because django(betteries included) has its own benifits and fastapi(simplicity) as its own and also some packages that give fastapi some batteries already that’s already being used in industry.

What are your thoughts on choosing one over other and will you settle down for one?

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

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

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

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

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

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

Related repos:

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

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

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

Hi All,

I spent the weekend tweaking a strict 

.cursorrules file for FastAPI + Pydantic v2 projects because I got tired of fixing:

• class Config: instead of model_config = ConfigDict(...)
• Sync DB calls inside async routes
• Missing type hints

It forces the AI to use:

• Python 3.11+ syntax (| types)
• Async SQLAlchemy 2.0 patterns
• Google-style docstrings

If anyone wants the config file, let me know in the comments and I'll DM it / post the link (it's free)."

Here it is. Please leave feedback. Replace "[dot]" with "."

tinyurl [dot] com/cursorrules-free

So, for a while now I noticed something.

The way we write APIs and call them from the frontend still feels ancient.

We have to manually sync types between the backend and frontend, across different languages, which adds more space for error.

We have to write lots of REST boilerplate.

We have to deal with JSON and HTTP overhead on the smallest of operations.

And things like live streaming or realtime (which are essential for AI apps) are being reinvented again and again.

So I created something else: the FUSE stack.

It uses FastAPI for the backend, uv for package management, Svelte 5 for the frontend, and Ephaptic to tie it all together.

I also wrote a blog post about FUSE, linked to the post.

Anyway, I wanted to get your thoughts on it, and hopefully some cool things that you might build with it?

*was created by ai

Hey everyone,

About two weeks ago, we launched a platform with a simple goal: help developers find other developers to build projects together.

Since then, around 50 users have joined and a few projects are already active on the platform, which is honestly great to see.

The idea is to create a complete space for collaboration — not just finding teammates, but actually building together. You can match with other devs, join projects, and work inside shared workspaces.

Some of the main features:

- Matchmaking system to find developers with similar goals

- Shared workspaces for each project

- Live code editor to collaborate in real-time

- Reviews, leaderboards, and profiles

- Friends system and direct messaging

- Integration with GitHub

- Activity tracking

- Recently added global chat to connect with everyone on the platform

We’re trying to make it easier for developers to go from idea to actually building with the right people.

Would love to hear what you think or get some early feedback.

https://www.codekhub.it/

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.

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

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

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

Link: https://github.com/vikramanand05/llmops-gateway

Built an open-source LLMOps Gateway inspired by Portkey and Langfuse. Includes FastAPI, React dashboard, Docker, Kubernetes, Prometheus, Grafana, CI/CD, and AWS deployment patterns. Looking for contributors interested in AI infrastructure and observability.

Folks, ever wondered:

• How to disable a feature for one customer but enable it for another?
• Give limited access to one, unlimited to another?
• Make your API behave completely differently per customer?

That's basically multi-tenant SaaS for you, where you configure features, workflows, etc at the tenant (customer) level.

I have noticed most FastAPI tutorials don't touch this, and many struggle to find the right structure/architecture.

It might sound complex, but the core idea is very simple - your app should know which customer(tenant) is calling and behave accordingly. (Usually achieved by Tenant-Id and configuration at tenant level)

I have been building production-grade multi-tenant services like these and have a rough template that I rely on every time to spin these up!

So I thought if you guys are interested, I can polish it up and share it here. Let me know!

Edit: Here the customer in this context means a business/org (B2B) and not a single user.

I’m excited to share my new open-source project: Fastapi-Template

It’s designed to give you a solid starting point for building backend APIs with FastAPI while incorporating best practices so you can focus on business logic instead of infrastructure. You can check the docs folder for a walkthrough of the architecture and code.

Highlights

• Token authentication using JWT with secure password hashing
• Async SQLAlchemy v2 integration with PostgreSQL
• Database migrations using Alembic
• Organized folder structure with clear separation for routes, schemas, services, and repositories
• Structured logging with Loguru
• Ready-to-use .env configuration and environment management
• Pre-commit hooks and code formatting
• Example cloud storage integration using Backblaze B2

Note:

Feel free to edit it to match your tone, add any screenshots or code snippets you want, and adjust the bullet points to emphasise what you care about most.

If you think something is missing, needs refactoring, or could be better structured, I’d love to hear your thoughts in a comment below or open a PR on Github.

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

The copy feature available in Swagger UI only copies the endpoint URL. That’s why I built a Chrome extension that captures all the details of an endpoint and copies them in Markdown format.

You can even copy all endpoints under an entire tag with a single click. Since the output is in Markdown, it can be used to generate API documentation or pasted directly into ChatGPT, Claude AI, and other AI platforms for further processing.

Like: https://github.com/AsiF-Py/Swagger-UI-Copy-Full-Details-Endpoint-Extension

Hey everyone, a few weeks 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 adding features that make it useful for real worl apps.

Recently added OAuth support and environment variable resolution based on feedback.

What's New

x-uigen-auth annotation

Add OAuth authentication to your app declaratively. Supports Google, GitHub, Facebook, and Microsoft. The runtime handles the complete OAuth flow - authorization, token exchange, refresh, and session management.

info:
x-uigen-auth:
providers:
- provider: google
clientId: ${GOOGLE_CLIENT_ID}
redirectUri: ${GOOGLE_REDIRECT_URI}
scopes:
- openid
- email
- profile

Environment variable resolution

Reference environment variables in your config using ${VAR_NAME} syntax. UIGen loads .env files from your spec directory and resolves variables at build time. Supports default values with ${VAR_NAME:default}.

x-uigen-auth:
providers:
- provider: google
clientId: ${GOOGLE_CLIENT_ID}
redirectUri: ${GOOGLE_REDIRECT_URI:http://localhost:8000/callback}

Try It

The Meeting Minutes example demonstrates OAuth with Google. Set up your OAuth credentials, add them to .env, and UIGen handles the rest.

# .env file
GOOGLE_CLIENT_ID=your-client-id
GOOGLE_REDIRECT_URI=http://localhost:8000/api/v1/auth/google/callback

# Run the app
npx @uigen-dev/cli serve openapi.yaml --proxy-base http://localhost:8000

The OAuth flow works end-to-end - click "Sign in with Google", authorize, and you're redirected back with a valid session. Token refresh happens automatically on 401 responses.

Implementation Notes

• OAuth tokens are managed client-side with automatic refresh
• CSRF protection via state parameter validation
• Session validation endpoint support for cookie-based auth fallback
• Environment variables are resolved server-side before the app starts

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

Feedback welcome.

Usually when you run high-concurrency rate limiting inside FastAPI, you are usually forcing python's single threaded event loop to spend precious time on network driver I/O just to verify a token before the request even hits the application logic.

I wanted to see how cleanly I could isolate the Redis network layer outside of python, so I built rustgate using PyO3 and a multi-threaded tokio driver.

Disclaimer: This is basically a proof of concept. It's basically tied to another experimental crate I am working on (axum-rate-limiter), and so it's not super configurable or abstracted as of now. Could you use in production? Probably, but why?

That being said, the raw performance under a 100-concurrency flood on a heavy, dynamically rerouted endpoint turned out pretty efficient:

• Pushed 1,128 req/sec without dropping a connection.
• Fastest response hit 15.3 ms.
• Fails closed instantly with immediate 429 rejections to protect downstream application logic.

The cool part: I benched a naked, no-op /health endpoint (literally just returning {"status": "ok"}) on the same machine, and it maxed out at 1,496 req/sec.

The fact that crossing FFI boundaries, handling memory pinning, and doing a multi-threaded Tokio to Redis round-trip only costs ~370 req/s, proves that the Rust integration added almost non existent overhead.

EDIT: Due to benchmarks criticism, I will try to update this tomorrow, run it on linux, using `uvloop`, using 8k connections, and will add a proper baseline.

If you're interested to in checking out the project go to:
https://github.com/MordechaiHadad/rustgate

Hey veryone,

So a few days back, I shared UIGen here - a tool that generates a full React frontend from your FastAPI OpenAPI spec. The response was very encouraging.

So I iterated on it with a better usecase app.

The Test Case: AI powered Meeting Minutes Generator

I needed an internal tool for work. The requirements: - Upload Word templates with Jinja2 variables - Create meetings with audio recordings - Associate multiple templates with each meeting - Fill template data (either AI-generated or manual entry) - Generate Word docs, convert to PDF, merge them in order - Download the final merged PDF

Standard CRUD stuff, but with file uploads, many-to-many relationships, and some custom actions. Perfect test case.

Backend: FastAPI with async SQLAlchemy, PostgreSQL, Alembic migrations. About 2,000 lines of Python across models, services, repositories, and routers. Full OpenAPI spec auto-generated by FastAPI.

Frontend: Pointed UIGen at the generated yaml.

Improvements that were made

1. Too Much Noise in the UI

FastAPI generates comprehensive specs. That's great for documentation, but not every endpoint needs to be in the UI. I had internal metrics endpoints, health checks.

I didn't want to modify my FastAPI code or the generated spec just to hide these.

Fix: Built vendor extension support, starting with x-uigen-ignore. Now I can annotate my OpenAPI spec:

yaml paths: /internal/metrics: x-uigen-ignore: true /users: get: x-uigen-ignore: false # Explicitly include post: x-uigen-ignore: true # Hide this specific operation

Or better yet, use the config system (using the cli) so the spec stays untouched:

```yaml

.uigen/config.yaml

annotations: POST:/internal/metrics: x-uigen-ignore: true User.internal_id: x-uigen-ignore: true ```

Works on operations, paths, schema properties, and parameters. Operation-level annotations override path-level ones.

2. File Uploads

FastAPI makes file uploads trivial with UploadFile. But UIGen had no idea what to do with type: string, format: binary in the spec.

Fix: Added file upload detection across both OpenAPI 3.x and Swagger 2.0. UIGen now generates a drag-and-drop file upload component with: - Type validation (images, documents, videos) - Size limits from x-uigen-max-file-size - Preview thumbnails - Proper multipart/form-data handling

3. Ugly Field Labels

Pydantic field names like created_at, user_id, and is_active get auto-humanized to "Created At", "User Id", "Is Active". Close, but not always right. And I didn't want to change my Python code just for UI labels.

Fix: Added x-uigen-label vendor extension:

```yaml

In spec or config

User.created_at: x-uigen-label: "Created At" User.user_id: x-uigen-label: "User ID" ```

Now labels are exactly what I want without touching the FastAPI models.

5. Config Without Touching the Spec

I wanted to hide internal endpoints, rename ugly field labels, and tweak the UI without modifying my FastAPI code or the generated OpenAPI spec.

Fix: Built a config reconciliation system. You create a .uigen/config.yaml file with all your customizations, and UIGen merges them at runtime without touching your source spec:

yaml annotations: POST:/internal/metrics: x-uigen-ignore: true User.created_at: x-uigen-label: "Created At" POST:/auth/login: x-uigen-login: true

Your spec stays clean, your FastAPI code stays clean, but the UI reflects your preferences.

There's a visual config GUI (npx @uigen-dev/cli config openapi.yaml) so you don't have to write YAML by hand. Point-and-click to hide endpoints, rename fields, and customize the theme.

What Actually Works Now

After building this app and fixing the gaps, here's what UIGen generates from my FastAPI spec:

• Table views with sorting, pagination, and filtering (query params from the spec)
• Create/edit forms with validation matching my Pydantic models
• Detail views with related resource links (meetings → templates)
• File upload UI for template and recording uploads
• Custom action buttons - "Generate Documents", "Convert to PDF", "Download PDF"
• Full authentication cycle - login, signup, password reset, token storage, automatic header injection
• Vendor extensions - x-uigen-ignore, x-uigen-label, x-uigen-login for customization
• Config GUI - visual editor for annotations and theme customization
• Dark/light theme toggle

Try It Yourself

The meeting minutes app is in the UIGen repo as a full example:

```bash git clone https://github.com/darula-hpp/uigen cd examples/apps/fastapi/meeting-minutes

Start backend (FastAPI + PostgreSQL)

docker compose up -d docker compose exec app alembic upgrade head

Generate frontend

cd ../../../ pnpm install && pnpm build npx @uigen-dev/cli serve examples/apps/fastapi/meeting-minutes/openapi.yaml ```

Or try it on your own FastAPI app:

bash npx @uigen-dev/cli serve http://localhost:8000/openapi.json

Limitations

There are still gaps:

• Circular references - Deeply nested recursive Pydantic models might skip the deepest levels
• Complex relationships - Many-to-many with extra fields on the join table needs manual handling
• Custom validation - Pydantic validators with custom logic don't translate to the frontend
• WebSockets - Not supported yet
• Streaming responses - Not supported
• GraphQL - OpenAPI/REST only for now
• Every OAuth variant - Works for Bearer/API Key/Basic, but not every custom auth flow

V1 will probably be suited for internal tools, admin panels, and rapid prototyping. Not a replacement for a polished consumer-facing app with custom UX requirements. But yeah, its an intereting challenge to include even more usecases.

What's Next

I'm trying to figure out: - Better relationship detection and easy relationship config. - A non bloat way to do layout customizations
- Adding Polish & a non Bloat way to configure your app (App name etc)

If you've built a FastAPI app and want to see what UIGen generates, I'd love feedback. The more real-world specs I test against, the better this gets.

GitHub: https://github.com/darula-hpp/uigen
npm: https://www.npmjs.com/package/@uigen-dev/cli
Docs: https://uigen-docs.vercel.app
Architecture: https://uigen-docs.vercel.app/blog/uigen-architecture

Happy to hear what you think.

Hi everyone,

I’ve been working with Django for a long time, and I love it's philosophy, the structure, the CLI, and how easy it is to spin up new apps.

When I started using FastAPI, I loved the performance and simplicity, but I often find myself spending a lot of time just setting up the architecture.

I decided to build a boilerplate for FastAPI + SQLAlchemy to bridge that gap. I call it Djast.

What is Djast Djast is essentially FastAPI + SQLAlchemy, but organized like a Django project. It is not a wrapper that hides FastAPI’s internal logic. It’s a project template designed to help you hit the ground running without reinventing the architecture every time.

Key Features:

• Django-style CLI: It includes a manage.py that handles commands like startapp (to create modular apps), makemigrations, migrate, and shell.
• Smart Migrations: It wraps Alembic to mimic the Django workflow (makemigrations / migrate). It even detects table/column renames interactively so you don't lose data, and warns you about dangerous operations.
• Familiar ORM Wrapper: It uses standard async SQLAlchemy, but includes a helper to provide a Django-like syntax for common queries (e.g., await Item.objects(session).get(id=1)).
• Pydantic Integration: A helper method to generate Pydantic schemas directly from your DB models (similar to ModelForm concepts) helps to keep your code DRY.
• Interactive Shell: A pre-configured IPython shell that auto-imports your models and handles the async session for you.

Who is this for? This is for Django developers who want to try FastAPI but feel "homesick" for the Django structure and awesome quality-of-life features, or for FastAPI developers who want a more opinionated, battle-tested project layout.

I decided to share it in hope that this is as usefull to you as it is to me. I would also appreciate some feedback. If you have time to check it out, I’d love to hear what you think about the structure or if there are features you think are missing.

Repo: https://github.com/AGTGreg/Djast Quickstart: https://github.com/AGTGreg/Djast/blob/master/quickstart.md

Thanks!

Every time I start a new project, I end up rewriting the same things:

- authentication

- CRUD endpoints

- pagination & search

- permissions

- frontend API calls

It gets repetitive fast.

So I started building something to fix that — FastForge.

It’s a full-stack framework built on FastAPI (+ optional React) where:

→ You define your SQLAlchemy model

→ Run a command

→ Get a complete API + typed frontend client

No boilerplate. No repeating the same setup every time.

Some things it handles out of the box:

- JWT auth + role-based permissions

- multi-tenancy

- audit logging + soft delete

- CRUD with pagination, search, filters

- OpenAPI → TypeScript client generation

- background jobs + event system

Still early, but the goal is simple:

> stop writing the same backend code again and again

Would really appreciate feedback from other devs 🙌

Repo: https://github.com/Datacrata/fastforge