You can deploy FastAPI apps with the command fastapi deploy, or connect your GitHub repo, with logs, metrics, custom domains, teams, and managed deployments.
We are the same team behind FastAPI, building FastAPI Cloud.
We're looking for a Design Engineer who can also code frontend (or is learning to), to help us (mainly) make the dashboard the best developer experience possible for deploying FastAPI apps.
We prefer candidates with strong design skills over only strong frontend skills.
Astral's tools (Ruff, uv) are awesome, I'm a big fan. I'm using them every time I can and recommending them everywhere. I use them for my open source projects (FastAPI, Typer, SQLModel, etc.) and also for private things, small and big, even small scripts, everything. Also, they have great docs, and I'm kinda picky with docs. I'm looking forward to whatever they build next, I'm pretty sure I'll like it. By now, it's not just by chance that they built one great thing, it's a trend, they build great stuff.
I don't have chocolates for you all, but you might like this.
Migrating from Flask to FastAPI, Part 2.
This is the juicy part, all the main code changes from Flask to FastAPI, including some auth and dependencies.
From Forethought with love.
For the advanced stuff, including the g pseudo-global variable, more techniques migrating from Flask to FastAPI, and mixing async and await with blocking code, wait for the next part.
Hey! FastAPI author here. I do have a bunch of issues and PRs to review across the projects. But as I personally review and in most cases fine-tune and update each one of the PRs (if you check the history, almost no PR is directly merged, most of them require updates) it's taking me a bit to handle them all, but I'm on it. I even changed my working structure to optimize for more open source. Sadly, new issues and new discussions like that one linked asking why the other issues are not solved, don't really help, as they just add another issue for me to read and take care of. I'm also prioritizing the work that can have the most impact. For example recently I was helping a bit with AnyIO and Trio, as they are used underneath by FastAPI. And now I'm working on something for Pydantic, that would be used by SQLModel and FastAPI.
One of the things that consumes time the most is handling issues by others. If you go and help them and they close those issues, that's a lot of minutes (in some cases hours) that you save me, and that I can then dedicate to review the other issues and PRs.
Nice! Yeah, it should work well with Starlette, Flask, or anything else. And yeah, I plan on adding docs and a thin layer on top of Alembic, but yeah, it's just SQLAlchemy so it will be just the same Alembic behind the scenes.
Yep, but not secret, it's the in-progress dataclass_transform draft spec, already implemented in (open source) Pyright, and Pylance re-uses Pyright, so it gets that support.
As Pyright already supports it, and Pylance is built on Pyright, they can use it directly. Hopefully more editors will use it and hopefully it will be part of the standard Python (in a PEP, with typing.dataclass_transform, and with mypy support).
And just in case you're wondering, there's no downside to having the dataclass_transform, anything that doesn't support it is unaffected, and nothing else would have completion either way.
The main benefit is actually being able to have statically typed models instead of dynamic, to get autocompletion, error checks, etc.
In fact, I made a small utility library some time ago to create dynamic Pydantic models from SQLAlchemy models (https://github.com/tiangolo/pydantic-sqlalchemy), but that's only useful in a few cases, e.g. for response_model in FastAPI.
I just released it yesterday, so almost no one is using it in prod (I bet there's a couple using it already).
But it's all SQLAlchemy underneath, the most wiidely used Python SQL library, with tons of years of usage, so that gives some safety.
And the test coverage is at 97%. I will release 0.1.0 once test coverage reaches 100% and I have the main docs I want there.
The only caveat with the version is upgrades, as, as of now, anything could change (probably I won't change anything, just add stuff). But you can solve it by pinning the version, writing tests, and upgrading the version only after tests pass.
The only other issue you might have is that you really want to do some very advanced trick with SQLAlchemy and in some way it's still not supported. In that case you might want to use SQLAlchemy directly for that model, you can mix SQLAlchemy and SQLModel (although I haven't documented that yet).