Open Amiga501 opened 1 day ago
This issue has been mentioned on HoloViz Discourse. There might be relevant details there:
https://discourse.holoviz.org/t/panel-app-in-fastapi-router/8414/3
I'm not a regular fastapi user.
Can you explain why you need it to be within the router
. What is the purpose?
I'm not a regular fastapi user.
Can you explain why you need it to be within the
router
. What is the purpose?
If you have multiple, related items but want to keep separation of code then use of routers is a convenient way to go.
Say you have (for a particular subject matter) prototype/research endpoints, development endpoints and production endpoints. Each comes with different levels of review, V&V and (the dreaded!) paperwork - but all may very much focus around a particular topic. In that case, the different routers neatly separate along the lines of degree of overhead required for each router codebase to be changed.
Maybe you'd place them all on separate actual FastAPI services, probably even on separate machines/VMs. In which case switch the above out for several subject matters hosted on the (for example) development method service API.
That means any particular subject matter (for latter example) or a stage (proto/dev/production for former example) can be adjusted with complete independence from all others.
It also avoids too much code residing in the main.py (or wherever module the "app = FastAPI()" line would go into)
If your a flask user (?), then consider it akin to blueprints. Pretty sensible to use that, or an equivalent, when doing anything of substantial size.
That help?
[As said in original post, being able to structure the source code in separate routers, even if the actual url isn't "routered" is a good step in allowing good code structuring. Just it'd be even better if it were able to do the full thing and the fix was something simple that I wasn't grasping.]
I'm currently travelling so I haven't worked through all the details but broadly I agree we should enable this use case. The initial work will likely have to happen in bokeh-fastapi and then we have to if there's anything we need to change in Panel.
[Originally posted here and raising as issue on recommendation from @ahuang11 ]
Hi all,
Was trying Running Panel apps in FASTAPI and have the example up and running. But in a more real world use case, I would need to run it within routers - even if just for source code structuring.
Taking Marc's example and extending it as below:
On initial running, there were complaints within the bokeh_fastapi.application.BokehFastAPI class because a Router instance has been supplied rather than a FastAPI app instance.
I then tried to dummy this module by modifying as code snip below (only top to tail of section that changed shown). Basically I mapped the Router onto a dummy representation of a FastAPI app.
This worked... but only if prefix="/test_router" does not exist when specifying the app.include_router() line in main.py While this in itself is useful - it does allow source code structuring - it would be neater if it did align with the router paths, so onward the investigation went.
When specifying the prefix, while the endpoint is visible on the openAPI /docs page, attempting to access the endpoint will return multiple failures to access .js files in paths: /test_router/static/extensions/panel/.. ../es-module-shims.min.js /test_router/static/js/bokeh.min.js /test_router/static/js/bokeh-gl.min.js /test_router/static/extensions/panel/panel.min.js /test_router/static/js/bokeh-widgets.min.js /test_router/static/js/bokeh-tables.min.js
Circled around it a few times now from different directions trying to specify StaticFiles and mount the app - but to be honest not really knowing what I'm doing its akin to pinning the tail on a donkey! :smile: So putting this infront of the experts who do actually understand the library and see what you all think.
bokeh_fastapi\application.py