https://github.com/jvllmr/fastapi-deferred-init
Improve start-up time for FastAPI apps with many nested routers
https://github.com/jvllmr/fastapi-deferred-init
fastapi speedup
Last synced: 5 months ago
JSON representation
Improve start-up time for FastAPI apps with many nested routers
- Host: GitHub
- URL: https://github.com/jvllmr/fastapi-deferred-init
- Owner: jvllmr
- License: mit
- Created: 2023-10-21T21:18:41.000Z (over 2 years ago)
- Default Branch: master
- Last Pushed: 2025-04-01T06:11:27.000Z (about 1 year ago)
- Last Synced: 2025-04-01T07:24:08.388Z (about 1 year ago)
- Topics: fastapi, speedup
- Language: Python
- Homepage: https://jvllmr.github.io/fastapi-deferred-init/dev/bench/
- Size: 291 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 2
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# fastapi-deferred-init

[](https://github.com/jvllmr/fastapi-deferred-init/blob/master/LICENSE)

## The Problem
When using nested routers in a FastAPI project its start-up time can get long quite fast.
That is because every router re-calculates the routes defined by a nested router when including it and the pre-calculated values by the nested router never get used. In short: values in nested routers are calculated although they will never be used.
## The Solution
This library provides a modified APIRoute that defers the calculation of values to the first actual attribute access. A router which uses the route as a default is also provided.
## Caveat
When using the deferred APIRoute on every layer of the app, startup errors are deferred to the first time a route is called. So errors related to route registration might go undetected if the route is not tested at least once.
## Pull Request
I created a pull request to merge this change back into FastAPI: https://github.com/tiangolo/fastapi/pull/10589