🚀 Roadmap

[tiangolo]

Description

This is a tentative roadmap, I will update it as things evolve. Some things might be discarded, others might be added later. I didn't want to make it fully public as it could raise expectations, but it seems it would be more beneficial for the community to know all the ideas and objectives.

Work on this is alternated (and sometimes mixed) with work on Typer, SQLModel, Asyncer, and others.

Answering questions, issues, and PRs is also intermixed with this, but as in some cases one of these features would solve several issues or questions, or potentially solve something done by one or more PRs, in many cases I focus on this a bit more than on answering specific issues, questions, PRs.

Other Tools

FastAPI gets a lot of help from the underlying tools and the people behind them, Pydantic, Starlette, Uvicorn. A lot of the work done there reflects in FastAPI, so they are helping FastAPI, in some way helping maintaining it too, because it's all connected.

Maintenance

The word "maintenance" or "maintainer" doesn't have a very strict definition, and it probably varies a lot from perspective.

A lot of the work related to maintaining FastAPI is done by contributors, you can see the current team here: https://fastapi.tiangolo.com/fastapi-people/#team

And you can learn about how the project is managed here: https://fastapi.tiangolo.com/management/

I also receive a lot of help from others like the FastAPI Experts: https://fastapi.tiangolo.com/fastapi-people/#fastapi-experts

A lot of the maintenance work is done by this amazing community.

If I suddenly died being hit by a bus, there are already mechanisms in place for code inheritance, there are others with GitHub rights to take over, etc. but I have requested to still review each PR myself.

You can help me ensure each existing PR is in shape (has tests, solves the problem, etc.). Make sure you filter out the translation PRs (most of them) unless you speak the language and can review them.

Security

When there are security issues, those are handled with the highest priority, normally involving all the projects and the people from them (FastAPI, Starlette, Pydantic, Uvicorn). Those are normally not handled in issues and PRs but in emails, it's not public until the security disclosure is made, in most cases (always, up to now) with the version that fixes them.

Roadmap

Now, here's the current high-level tentative roadmap:

• Code reference, for functions, classes, parameters, etc. (✨ Add reference (code API) docs with PEP 727, add subclass with custom docstrings for BackgroundTasks, refactor docs structure #10392)
  • This required additional tooling and methods that didn't exist before.
• Pydantic v2 used for serialization and parsing (increasing performance).
• Upgrade Starlette.
• FastAPI CLI
• Explore supporting Pydantic v1 and v2 on the same app.
• Refactor routers, to re-use router instances insteaad of cloning path operations. This will allow several things like:
  • Middlewares per router.
  • Custom router classes.
  • Dependencies per router, including for handling 404 (replacing most of the middleware functionality).
• Support for Pydantic models for Query(), Form(), etc.

Probably similar to:

class Common(BaseModel):
    token: str
    skip: int = 0
    limit: int = 100


@app.get("/items/")
def read_items(commons: Annotated[Common, Query()]):
    ...

• Additional security and authentication tools to simplify common tasks.
  • Auth2 with a third party.
  • Buildling an OAuth2 single sign-on server.
  • Cookie-based auth.
  • More docs for Bearer tokens.
• Improved dependency overrides for testing.
• Clearer server errors and tracebacks.
• Docs for liveness and readiness for Kubernetes and others.
• Customization of parsing and serialization (to support more than JSON).
• Errors based on RFC 9457.
• Refactors and simplifications of internal code.
• Improved lifespan support/API.
• Improved middleware support/API.
• Updated SQL tutorials (sync and async) based on SQLModel.
• New NoSQL tutorial.
• Refactor for dependencies, end before response.
  • Improves performance.
  • Could allow response modification.
  • Better connection pool handling (e.g. for databases).
• Performance optimizations.
• Experiments with internal batch processing.
  • E.g. for batch ML inference in the same app.

Note

This issue is just to keep anyone interested updated. For individual conversations, comments, requests, questions, please create a separate discussion question. Otherwise, we would end up with a single issue to cover everything and that's not the idea. 😅

[iudeen]

This is lovely!

A suggestion...will it be possible to have a list of PRs mapped with these roadmap items, so that we can check and contribute to those which are not started.

[elsakeirouz]

Don't you plan on adding RefreshUrl to the OAuth2 Password Flow?

[wangxin688]

Is there any plans to add class based view natively support by fastapi?

[antonrh]

Small comment regarding Errors based on RFC 7807: it has already been obsoleted by RFC 9457 - https://www.rfc-editor.org/rfc/rfc9457.html.

[afallou]

A note on the maintenance section.

I have requested to still review each PR myself.

That is a major issue IMO. We've deployed a FastAPI app in production for one of our microservices, as an exploratory project to switch over from Flask. We started hitting issues like MagicStack/asyncpg#978, which #5707 is attempting to fix (see also related issue #8424).

I consider that issue be a major one, because it really touches on what makes async programming in Python hard and a little risky without a good framework on top – the errors you get are somewhat probabilistic, the stracktraces cryptic and the issues hard to debug. That PR is almost a year old, and there has been no activity of any kind on it from you, and that worries me. Because of that, my current conclusion from this exploratory project is that FastAPI isn't something I want to rely on in a production environment yet.

Your project is awesome and I love it, like many others. I have a lot of respect for your work here. But with 64k stars it's far beyond a "one-man shop" OSS project, and having your review every PR isn't realistic anymore. Maybe you could start with a 2nd core reviewer, and see how that works?