Should I move backend logic out of Dash as the app scales?

Dash Python
1

Hey everyone,

I’m a big fan of Dash. I’ve been using it at our company to build an internal BI system, and honestly, it has ended up outperforming Power BI for our use case in pretty much every way — especially in terms of speed, flexibility of charts, and overall user experience. With DMC, the design side is also really solid.

The current stack is mainly:

  • Dash / Plotly
  • Dash Mantine Components
  • PostgreSQL
  • dbt
  • DuckDB
  • Airflow

The app has grown into a fairly serious internal platform. It uses Flask-Login for user management, roles and permissions. Besides the BI section, it also includes market research features and some other non-BI functionality.

The executive board and our sales team love it. Actually, they like it so much that they now want to scale it to other companies within our holding group.

That’s great, but it also makes me think more seriously about the long-term architecture.

The codebase is already around 110k lines of code, and it will obviously keep growing both horizontally and vertically. So far, performance is excellent and the development speed is still very good. Ideally, I would love to stay Dash-only for as long as possible.

My main concern is whether Dash is really built for this level of complex application long term, especially on the backend side. I’m wondering if at some point the Dash backend/callback layer could become limiting, and whether I should start thinking about moving some backend logic into something like FastAPI while keeping Dash as the frontend.

Has anyone here built or maintained a large Dash application at this scale?

I’d be really interested in your experience:

  • Did you stay Dash-only?
  • Did you eventually split the backend out?
  • What became painful first?
  • Any architecture patterns you would recommend for scaling this kind of app?

Thanks a lot for any advice or real-world experience.

2

Dash can use FastAPI, Quart or other backends now. Do you need async support, websockets, or will have an extensive API? You could look at Django too if you need an admin panel and various infrastructure. I have moved some of my apps out of Dash when the callbacks became too much to manage (Claude would often get tripped up too) and many were already client-side callbacks written in JS anyways. You can try to have Claude write your app up with FastAPI + TS/React + Mantine and see how they compare. I have generally found Claude to write TS very well, perhaps because its trained on so much of it on the web. However, if you don’t write in JS/TS, this may be too uncomfortable for you to continue with for an app you are already using with so many users and its not just an MVP. There is also reflex to look at as well, which is structured more like TS I think.. but I feel at that point, just write it with FastApi/TS or Django/TS than learn another python framework wrapping React.

You could point Claude to your repo and have a conversation on what makes sense given your background and direction of the app. Be sure to point Claude to the latest release of Dash with the FastApi/Quart support though.

3

The benefit of staying in Dash vs writing React by hand, is the dash eco-system. In React, you’d have to either manage the state or create the connections throughout the app. In dash, if you want something to update you just write a callback for it. You dont need to write the fetch request, create the logic to pass data from a child to a parent and vice versa.

The ability to bring your own backend is a game changer, honestly. It allows you to bring any (python server) and run the app from there, and they have pre-configured backends of FastAPI and Quart. With this said, you can still maintain a segmented directory structure. For me, I have a utils folder which houses my callbacks, common imports for pages, and shared functions across the app. You can segment these down further is you want, but these will help future you, new hires or AI.