tiangolo

Nice to hear! :)

Hi HN, I’m Sebastián, creator of FastAPI.

We just opened the public beta of FastAPI Cloud.

You can deploy FastAPI apps with the command fastapi deploy, or connect your GitHub repo, with logs, metrics, custom domains, teams, and managed deployments.

Announcement: https://fastapicloud.com/blog/fastapi-cloud-public-beta/

FastAPI Labs | Design Engineer | Remote

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.

Please include your portfolio link or PDF and CV.

Email jobs@fastapilabs.com

FastAPI Labs | SRE / DevOps | REMOTE

I created FastAPI, now I'm doing interesting new things and want extra help.

I'm looking for tons of skills and knowledge in SRE / DevOps / Platform / Cloud / name-it ...and FastAPI.

Email jobs@fastapilabs.com

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.

Here it is! The last part of the Forethought blog post series, migrating from Flask to FastAPI.

This includes:

Concurrency, async and await, and how to mix it with blocking code.

request and g pseudo-global variables.

Advanced refactoring.

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.

Part of the work I've done with Forethought is lead an effort to migrate from Flask to FastAPI.

Here's the first blog post out of 3, with all the tips and tricks to migrate a real-life, huge, production code base.

I hope it's useful!

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.

If you want to see faster progress, there are several ways to help, they are all documented here: https://fastapi.tiangolo.com/help-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.

Thanks! :D

Hehehe thanks for the trust! :D

I'm glad to hear that!

Yep, exactly. SQLAlchemy now has async support, so does SQLModel. But I haven't documented it yet.

Yep, SQLAlchemy now has async support, so does SQLModel :)

But I haven't documented it yet.

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.

https://github.com/microsoft/pyright/blob/main/specs/datacla...

Yep it uses the in-progress draft-spec dataclass_transforms https://github.com/microsoft/pyright/blob/main/specs/datacla...

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

Thanks Simon! It means a lot, even more coming from you (I might screenshot this comment and frame it in my living room). :D

Yep, I wanted to build it on top of SQLAlchemy to inherit all it's robustness and to be compatible with it, as it has the biggest widespread. SQLAlchemy now supports async too, so SQLModel inherits that as well.

And in particular, other libraries have done a great job, but I wanted to take advantage of the features that editors can provide, with autocompletion, inline errors, etc. SQLModel has lots of tricks to provide the best developer experience possible, e.g. autocompletion while creating a new model instance.

For example, the style of querying stuff, for example: https://sqlmodel.tiangolo.com/tutorial/where/#where-and-expr...

You can use it with anything you want, it's independent of any framework.

But as @tomnipotent says below, a SQLModel is also a Pydantic model, so, you can use the same model to do automatic API data validation, serialization, documentation, filtering... and now, also define the database.

There's no more integration, apart from the fact that I built it to do just that, and I made sure everything works just right with FastAPI.

But for any other framework that doesn't have automatic data validation, documentation, serialization, etc. (and you are just doing that by hand) it's an even simpler problem, so SQLModel will work just right, as any other ORM.

Yep, less code duplication between Pydantic and SQLAlchemy, autocompletion and inline errors in editors (e.g. when creating new instances and when fetching data from the database), because it has several type annotation tricks.

It's all just SQLAlchemy, so the same migrations with Alembic would do it, I plan on documenting that in the future and probably adding a thin layer on top.

Yes of course! It is based on (and depends on) SQLAlchemy and Pydantic.

And SQLModel, the same as those two dependencies, are independent of any framework, so you can combine them with anything you need.

Hey all! Author here!

Thanks for sharing!

This is the biggest thing I've built since FastAPI and Typer...

SQLModel is a library for interacting with SQL DBs, based on Python type hints.

Each model is both a Pydantic and SQLAlchemy model, and it's all optimized for FastAPI.

GitHub here: https://github.com/tiangolo/sqlmodel

More info in this Twitter thread: https://twitter.com/tiangolo/status/1430252646968004612

And the docs are here: https://sqlmodel.tiangolo.com/

Thanks, it would be great if you could create an issue with a simple way to replicate the problem so that I can check it out properly.

Thanks!

The system in big part thanks to Tom Christie (https://twitter.com/starletdreaming) for creating MkDocs (the documentation system) and to Martin Donath (https://twitter.com/squidfunk) for creating the Material for MkDocs theme.

Here's the favicon URL: https://fastapi.tiangolo.com/img/favicon.png

The docs are here: https://fastapi.tiangolo.com/

Anyway, I'm glad FastAPI is being useful!

I'm glad you liked it that much! ...I hope the refactor is not too bad.

Yep, that's the intention. But it's a frontend written by hand, and has to be updated by hand.

An automatic admin UI based on OpenAPI is one of the plans I have for the future. :)