As others mention, Flask has more batteries included in terms of built-in templating, ORM, etc, so it positions more as a backend webserver.
FastAPI is more focused on making it easy to make APIs, especially with the built-in Swagger docs generation (I don't believe Flask has this out-of-the-box).
So if your greenfield project is more web-based (clients are web browsers), Flask may be more suited. If your greenfield project is service-based (command line applications, or front end), FastAPI may be more suited.
In both cases, it's as easy to substitute one for the other. Personally I'll be trying out FastAPI since the dev experience seems a lot nicer (integration with `pydantic`).
That's not exactly accurate. When working with sync views FastAPI dumps them into a threadpool. It basically converts them to async on the fly. To quote the docs-
> When you declare a path operation function with normal def instead of async def, it is run in an external threadpool that is then awaited, instead of being called directly (as it would block the server).
FastAPI is more focused on making it easy to make APIs, especially with the built-in Swagger docs generation (I don't believe Flask has this out-of-the-box).
So if your greenfield project is more web-based (clients are web browsers), Flask may be more suited. If your greenfield project is service-based (command line applications, or front end), FastAPI may be more suited.
In both cases, it's as easy to substitute one for the other. Personally I'll be trying out FastAPI since the dev experience seems a lot nicer (integration with `pydantic`).