sub-applications

14 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Mounting sub-applications with root_path

FastAPI intelligently handles mounting sub-applications when using a proxy with root_path. The root_path is used internally by FastAPI, and sub-application mounting works as expected without requiring additional configuration.

Sub-applications with independent OpenAPI and docs

You can have a main FastAPI application and mount one or more sub-applications, each with their own independent OpenAPI and docs UIs.

Definition of mounting a sub-application

Mounting means adding a completely independent application in a specific path, which then takes care of handling everything under that path using the path operations declared in that sub-application.

Sub-application is a standard FastAPI application

A sub-application that will be mounted is just another standard FastAPI application, created the same way as any other FastAPI app.

Mounting syntax for sub-applications

To mount a sub-application in a top-level application, use the mount method: app.mount(path, subapi) where path is the route like '/subapi' and subapi is the sub-application instance.

Sub-application docs access path

When a sub-application is mounted at a path like '/subapi', its automatic API docs can be accessed at the corresponding docs URL, for example http://127.0.0.1:8000/subapi/docs.

Each sub-application has independent docs

Each mounted sub-application has its own automatic API docs UI that shows only its own path operations, and all path operations are shown with the correct sub-path prefix.

ASGI root_path mechanism for sub-applications

FastAPI uses the ASGI specification's root_path mechanism to communicate the mount path to sub-applications. The sub-application uses this path prefix for its docs UI and automatically handles everything correctly.

Nested sub-applications with root_path

A sub-application can have its own mounted sub-applications, and FastAPI handles all root_path values automatically, so nested sub-applications work correctly without manual configuration.

Sub-applications interact correctly from browser

When interacting with the user interfaces of a main app and its mounted sub-application, both work correctly because the browser can talk to each specific app or sub-app at their respective paths.

Using WSGIMiddleware to mount WSGI applications

You can mount WSGI applications like Flask and Django using the WSGIMiddleware. Import WSGIMiddleware from the a2wsgi package (not from fastapi.middleware.wsgi which is deprecated), wrap your WSGI application with the middleware, and then mount it under a path using FastAPI's mounting system.

a2wsgi package requirement for WSGIMiddleware

The a2wsgi package must be installed to use WSGIMiddleware. Install it with a command like 'uv add a2wsgi' or using your preferred package manager.

Deprecated WSGIMiddleware import location

Previously, WSGIMiddleware was imported from fastapi.middleware.wsgi, but this is now deprecated. The correct import is from the a2wsgi package instead. The usage and API remain the same.

Mounting WSGI application example with Flask

Example of mounting a WSGI application: import WSGIMiddleware from a2wsgi, create a FastAPI app, wrap a Flask application with WSGIMiddleware, and mount it under a path like '/v1/'. Requests to '/v1/' will be handled by Flask, while other paths are handled by FastAPI.

Give your agent this brain