Dynamic, User-Specific Dash App Layouts and Callbacks

Dash Python
1

I am planning to deploy a Dash web app through my Flask server that supports multiple “different” web apps with entirely unique layouts and callbacks. Each web app layout should be user specific. I’ve built out most of this functionality that I will provide thorough context about. My hope is that others have been faced with similar use cases or may be able to provide some suggestions about how I may be able to better design my system as production Dash applications are still very new to me and I come from a very Python focused background.

My Current Implementation and Use Case
I set up my Flask server with my single Dash application attached like so:

app = Flask(__name__)
app.secret_key = service_constants.SESSION_SECRET_KEY
dash_app = Dash(
    __name__,
    server=app,
    url_base_pathname=C_GLOBAL_DASH_APP_PATH,
    on_error=websmith_error_handler,
    assets_folder=DASH_ASSETS_DIR,
)
# Initialize the layout with handling for stylesheet updates and placeholder content
dash_app.layout = html.Div(
    children=[
        create_default_layout(),
        html.H1("Placeholder content."),
    ]
)

create_default_layout includes a couple components that all “different” possible web apps should include, like a Modal to display errors that may have occurred in callbacks.

Now I will explain what I mean by the “different” web apps I have. In my repo, I have a registry of Python objects abiding by an Abstract Class interface defined by my IDashApp class that has abstract methods layout(self) → html.Div and register_callbacks(app: Dash). register_callbacks has function definitions within it containing the @app.callback() definitions. I have several different implementations of the IDashApp class for things like tracking status of batch jobs that are running, analyzing results of models generated from those jobs, among a few others. Each of these concrete implementations of IDashApp has entirely different layouts and callbacks, and should also have user-specific states. So I may want to track the execution status of Job #1, but my coworker may want to track the execution status of Job #2… we both should be able to view this web app independently of each other at the same time.

Now to explain how these different IDashApp classes get initialized and tie back to the original dash_app on my Flask server. I have an @app.before_request handler on my Flask service that will check for get requests with paths containing my dash app base url of C_GLOBAL_DASH_APP_PATH. If it does, then I’ll pick off the relevant URL and query parameters to initialize the concrete IDashApp the user is requesting. Once I have the initialized object, I update the layout method of the dash_app and ensure the callbacks are registered from the concrete web app: dash_app.layout = concrete_web_app.layout(), and concrete_web_app.register_callbacks(app=dash_app).

This largely works as expected when testing locally and as a single user, but some problems quickly arise with more users and just with the underlying design of my system. A side point worth noting is that I have IdP authentication going on behind the scenes, so I have authenticated users “logged in” or maintaining an active valid session when these web apps are requested. I store this session info in my database using FlaskSQLAlchemy and flask_sessionstore.

My Concerns Needing Addressing with this Approach

  • One of the main concerns I have here is the lack of statelessness of these web apps. I initialize Python objects in memory that I am expecting to be unique to users and persist across requests. I find that one user (or a single user with multiple browsers) can effect the callbacks and layouts of another when the “same” web app is requested.
  • I am wondering if there may be able to store some of these session specific objects in my database to be sure the correct ones are referenced.
  • Or maybe I need to switch to multi page layouts which it seems like may play nicer with session specific callbacks?
  • Is the idea of initializing these objects from a registry based on the request entirely foolish and unnecessary if it could be solved with multi page applications?

I would very much appreciate any input or feedback others have about my use case. This community is so great and I appreciate any and all input from you guys!!

Noteworthy References I have Looked Into

2

Hello!

Do you * really * need to have multiple (different) dash apps served under the same server ?
There are easier alternatives:

  • host multiple apps under the same server but different ports
  • multi page apps
  • attaching all callbacks to the app and using a layout function e.g. app.layout = load_user_layout where load_user_layout is a function, that will load the right layout for the right user. (that’s kind of what multi pages is doing…)

If yes, “How to embed a Dash app into an existing Flask app” is what you are looking for, and you should just use Flask as a router to dispatch the requests between your dash apps. But each dash app should have its own callback list and own layout (which is why your attempt failed).

But this is not that easy and there are a lot of side effects, to my knowledge.
And most of the time you don’t need this solution.

If you never used multi app pages, you should investigate this first I think :slight_smile:

3

Hello @evanras9,

I have multiple users, different permissions accessing the same app and have different layouts and try can configure the app to their needs.

You cannot add callbacks to a running app as these are sent on initialization and the renderer registers looking for the props to change and sends a request to the backend.

I use a layout function to build mine out, even based upon the referrer I switch whether there is navigation or not.

I also use flask and dash, this can make for some really neat interactions, but can also be a little tricky sometimes.

4

Hi @jinnyzor,

I appreciate your input here! This makes sense and is helpful to know. I have messed around with the Dash.callback_map previously and it does seem possible to update callbacks on a running app, but maybe there are some concerns with this that I have not yet run into.

I have a couple follow up questions for you:

  • Do you utilize a multi page web app or is your layout function alone responsible for dynamically creating the layout based on the user’s request?
  • What sorts of triggers or identifiers do you use to know what the user is looking for in your web app? For example, do you use url or query parameters to change what contents are generated from your layout method? I have a need to make things very customizable through the usage of url and query parameters.
  • Are you saying you use a layout function to build out your callbacks? I’m not sure I’m following what you mean or what that looks like.
  • Would you be able to provide any code snippet examples for inspiration?

I really appreciate the helpful tips here, thank you!!

5

Hi @spriteware,

Thank you kindly for the quick response!

I do really have a need to have multiple different apps (or at least layouts) under the same server and port, unfortunately I don’t have a way around this one.

I definitely need to do some more exploration with multi page web apps, so thanks for the tip there.

Regarding your load_user_layout function, I’m curious how you know who the “right user” is? Are you able to pass arguments in directly to your layout function? If so, where are those initially coming from?

I’ll keep doing some digging around and testing things out in the meantime. Thanks again for the helpful words here!

6

I have a multi page app, this is restricted based upon the user logged in. The user identified by the session cookie. flask_login

You can check discussion here on a slightly outdated topic with using flask_login and dash.

7

Thanks again!

I think you may have forgotten to include a link, but my guess is you were referring to this post.

This is a fantastic post with some excellent examples. It’s clear you know your stuff pretty well, so I am very grateful for your support. I am curious specifically about the usage of current_user as it relates to authentication. For some more context, I am using server-side database Flask Session storage using Flask-SQLAlchemy and flask-sessionstore. I have authentication occurring currently outside of Dash using an Identity Provider which redirects users to SSO and back to my Flask server where authentication details are stored in my database. I do still use LoginManager to init_app my Flask server, so my question is… do I still need to use the curent_user and implement a UserMixin and user_loader? Or, since I have authentication handled outside of Dash, does this change anything with how I should implement my multi-page Dash app?

Again, thank you so much for your guidance.

8

As long as there is a cookie that ties to the user you should be good. Even if it’s server side, it is still associated with something that can be done on the request. At least this is my understanding, otherwise how you keep them separated?

Thing to watch out for are the background callbacks. However, with dash 3 you can now add custom data to the callback context, this is always in scope of the request, so I recommend loading the user info into that and then you can pull it whenever. Even in background callbacks.

9

Great, thank you! I did end up building this out and it appears to be working as expected.

I have a follow-up question about some of your original comments here:

You cannot add callbacks to a running app as these are sent on initialization and the renderer registers looking for the props to change and sends a request to the backend.
I use a layout function to build mine out, even based upon the referrer I switch whether there is navigation or not.

I’m curious what you mean when you say “I use a layout function to build mine out”? Is there a way to set / add callbacks within your layout function? I have the need to be able to register callbacks dynamically that are unknown at Dash renderer initialization time, so any additional information you have about whether this is possible would be incredibly helpful!

10

No, there isn’t a straightforward way to add callbacks because it is done when the layout is first rendered.