Argument `fastapi_kwargs` does not cascade down FastAPI object stack

[ptomasula]

Describe the bug
The fastapi_kwargs argument added with PR #9, is intended to allow users to set kwargs for the FastAPI instance created by the create_app function.

However, this library appears to be spinning up additional instance of FastAPI without provide those instances those keyword arguments. This leads to incorrect behavior, for example setting a root_path when behind a proxy; The root FastAPI instance will correctly handle url prefixes, but nested endpoints (handled by one of these other FastAPI instances) will not.

To Reproduce
Steps to reproduce the behavior:

1. Run application behind a proxy.
2. Set root_api parameter using fastapi_kwargs arugment.
3. Issue call against docs (/{root_path}/docs/ to verify proxy correctly serves JS.
4. Issue call against item in catalogs (/{root_path}/docs/{catalog}).
5. Reroute from catalog pathway will not have root_path included..

Expected behavior
The root_path (prefix) should be included in urls handled by the other FastAPI instances.

cc: @aufdenkampe @sjordan29

[sjordan29]

I updated the code and the root_path is now adopted within the Xpublish Rest app. I can successfully access the following with these changes:

• http://localhost:8000/api/xpublish/conus404-daily/catalogs
• http://localhost:8000/api/xpublish/conus404-daily/parent_catalog
• http://localhost:8000/api/xpublish/conus404-daily/yaml
• http://localhost:8000/api/xpublish/conus404-daily/json

However, still cannot access the datasets (get a 404 -- not found).

Running locally in debug mode, I can see the following:

The four routes that work (at the bottom) are added in Catalog-to-Xpublish via the stac_router, which just take an APIRouter() and use the add_api_route method. The ones that don't work appear to be added with Xpublish directly, so perhaps this leads to something we need to fix there. Can investigate more tomorrow -- just set up a call with @ptomasula

[sjordan29]

@ptomasula - can this issue be closed?