Hey there, I am trying to build a multipage dash application.
I register the page with a variable path according to the docs https://dash.plotly.com/urls#variable-paths.
In the layout function of the page I’m using the variable url paramter to request an API to get a response based on that url parameter and store it in a variable data
. The variable logically must set here because only at a request to the page the necessary url parameter is available.
In a callback function I want to use the response data of the API call. My current solution to do that is to make the data
variable global, but due to https://dash.plotly.com/sharing-data-between-callbacks this is not good practise because another session would overwite the data
variable and affect other sessions.
My question is now, what is the best practise to make the variable available to the whole python module file (page.py).
Is the dcc.Store() component the solution?
Short abstract of the page code:
# pages/page1.py
dash.register_page(
module = __name__,
path_template = '/home/<parameter>'
)
def layout(parameter=None):
data = requestAPI(parameter)
return html.Div('some content')
@dash.callback(OUTPUTS, INPUTS)
def callback1(*paramters):
futher_fuction(data["somekey"])
Thanks in advance!
1 Like
Yes, you can make the variable available to the user’s session via the dcc.Store. To make it available to the whole application would take using global variables.
Is there a reason you want to do the API on the server side and not the client?
1 Like
Thank you for your answer. Honestly I never thought about doing the API call on the client side.
I still have a lot to learn about programming especially how to design performant (web) applications. If you have some advice for well structured material to study those topics I’d be grateful . Currently I’m using https://www.w3schools.com/ most of the time.
Due to my current state of knowledge I would not know how to put the API on the client side. I guess it would be a solution like providing a JavaScript which executes the request and updates the html elements with the content received. Am I right?
What are the advantages putting the API call on the client side? I would assume performance gains because the response from the dash web server would arrive faster due to less processing on the server side?
1 Like
Correct, plus unnecessary network traffic for the server.
If the server was hosting the api, it’d be different. But if external, better to do the api on client.
I don’t know if we can perform an asynchronous clientside callback, that’s best for fetch calls from JavaScript. That way you’re not blocking other events.
1 Like
Okay I understand. Thanks again.
I’m using docker to gain some experience about distrubuted systems. At the current implementation state the requested API is hosted on the same physical machine but in a different docker container than the dash app.
You can probably keep it the way it is currently then. I’ll check on the other way.
1 Like
Thank you for your effort!
1 Like