We’re back! After a long hiatus, @adamschroeder and I are excited to bring you Dash Club Dispatch #6. Adam joined us in the Fall as Plotly’s Community Manager and you may know him as Charming Data from his Dash Youtube Channel.
We also have this Dash Club newsletter on Medium, in case you prefer to read or share it there.
Dash Club brings essays and updates to your inbox every 8 weeks. Sign up to stay in touch!
- Version Check
- WebAssembly in Dash Essay
- App of the month
- Component of the month
- Coming soon in Dash
- June Community App Challenge
- Things happen
- Dash Enterprise Platform 4.3 (announcement, request a demo)
- Dash Open Source Framework 2.5.1 (announcement coming soon!)
- Dash Open Source Framework 2.4 (announcement)
- Plotly.py 5.8 (announcement)
- Plotly.js 2.12 (Our 200th release! See the changelog)
Yes, WebAssembly Dash apps! Almost two years ago, community member Itay Dafna published WebDash, a WASM-powered interface to Dash, as part of a research project at Bloomberg. In WebDash, the Python callbacks and variables are compiled to WASM and executed in the app visitor’s browser client without making any additional network requests (Dash callbacks are typically executed on the server which requires sending data from the browser over the network and running on one of the available server CPUs).
Are statically hosted, self-contained executable data apps the future? Not everywhere. Static websites have their own set of inherent limitations that can become especially apparent for data-intensive web apps.
The network cost tradeoff. In a self-contained WASM-ified Dash app all callback requests are made within the browser without a server. The entire dataset, Python code, and runtime needs to be transported over the network in the initial request that loads the executable. Consider a Dash app where a 1GB dataset is loaded into memory when the app starts and all subsequent callbacks filter, aggregate, or run derived computations on that dataset. In “regular” Dash, the original dataset is held in Python memory on the server or memory mapped to disk and only the derived computations are sent to the client. These derived computations can be small; if the app is displaying a sum of a column it’s only sending a single number (8 bytes!) over the network to the client. In the WebDash model, the entire 1GB dataset is sent to the client along with the WASM-ified callback code on page load. Summing that column is done in the client instead of the server (no network request!) but you’re trading a 8 byte network request at runtime for a 1GB network request on page load. That’s going to be a heckuva lot slower. And we’re only talking about data so far, not even the cost of shipping the WASM-ified Python callback code, runtime, and dependencies.
Another challenge is fetching the data to begin with. Almost no databases allow connections from a browser; there is (almost) always server code involved in the middle that handles database authentication and authorization (not all viewers of the app should be able to view all of the data in the database!). The exchange between the browser and the database is typically done by custom server code packaged as an HTTP API. You could do the same with WebDash by writing an external HTTP API that the WASM-ified Dash app makes requests to, but then we’re back where we started with a Python server and we might as well just let the Dash framework abstract away all of this complexity for us.
Refreshing the data presents another challenge. With traditional Dash, your callbacks can fetch data from the original or cached data source on-the-fly in callbacks. And if fetching that data is too slow to do on-the-fly then you can deploy a background job queue to periodically fetch the data and cache the data nearby in Redis. When everything is self-contained in a WASM executable you can’t employ the same techniques.
So there’s a sweet spot for the self-contained WASM app. First, the data must be relatively small and it can’t load from databases on-the-fly. Second, the time saved by running callback computations in the browser must be greater than the time lost by sending the dataset to the browser on page load.
There’s a middle ground, though! Imagine a world where some but not all callbacks are compiled to WASM; think
Will this make its way into the general code editing experience? Definitely in the global education market. The costs of serving a self-contained IDE in a WASM executable is so much lower than spinning up servers on-the-fly and, crucially, students don’t need to download anything! They only need a browser. But it’s less useful for app development in a company setting because you need that server in-the-loop to connect to databases, aggregate large datasets, and store your code. In Dash Enterprise Workspaces, we provide an in-browser IDE where the Python code is written in the browser but is executed on the server hosting the platform. You get the benefit of writing code in your browser (don’t need to download Python!) without the limitations of WASM (you can connect to databases!). Plus, the environment that’s executing the code in development is almost identical to the environment running the deployed applications; you have the same network access to data sources, same container with the same version of linux, same Python versions, same packages, same disk, same Python package server, same security proxy, etc. dev = prod.
When we started Plotly almost 10 years ago we had a vision that data science would move from desktop platforms to the browser and it’s really exciting to see the community’s effort in pushing this boundary.
If any of this sounds interesting to you and you’d like to contribute to this effort, let us know by responding to this email. We have a Dash Ambassadors program with availability to mentor community contributions to Dash. In fact, Dash 2.5’s latest feature, pages, was built by our community member @AnnMarieW under this program.
@jhupiterz 's Dash app enables users to search for a research topic, just like you would do on your favorite academic search engine. We love the interactive network graph for citations. Gorgeous design, too!
See more Dash apps or share your own in the Community Forum’s Show and Tell tag. If you would like your app to be considered for the August edition of the Dash Club newsletter, please message Adam on the Forum.
We’re busy removing various limitations of app.long_callback by re-engineering the underlying polling mechanism. Long callbacks provide an API for long-running computations that would otherwise exceed most web servers’ 30-second timeout. Dash’s long callback API abstracts away all of the complexities in making long computations in data apps work at scale into a simple decorator so that you don’t need to worry about implementing polling, progress bars, background job queues, intermediate data caching, and more.
We challenge the community to build a Dash app that will support people working in animal shelters in understanding their data better and allow for higher rates of animal adoption.
This data set was provided to Kaggle by the Austin Animal Center, the largest no-kill animal shelter in the United States. The data set contains statistics and outcomes of cats entering the Austin Animal Services system.
To enter the Community Challenge please, download the dataset, create an app, and share it by replying to this Forum topic. The goal is to raise awareness around the data and predict methods to increase adoption rates. The winners will be highlighted in the next Dash Club Dispatch and will receive a package of this season’s Plotly swag.
We’re working with UserEvidence, a survey research firm, to collect feedback from Dash users. If you have a few minutes, we would greatly appreciate you filling it out.
Kansas City Chiefs share how they use Dash Enterprise
Plotly makes it on the DBTA 100
New community forum emojis
Dozens of Dash job postings ( we’re hiring too!)
TypeScript comes to Dash
Community member, Tolga, publishes Raspberry Pi x MQTT tutorial
Staff member @Celia presents at PyData Madrid
@Alex Johnson presents The Physics of Data at Boston Data Summit
Adam and @Kathryn Hurchla present Dash community development at Pycon US
Bruno Rodrigues shares a calendar heatmaps recipe
IQT publishes a general purpose network graph visualizer called Atlas
Kathy gives Dash a shout-out on Anaconda’s blog
ECOSTORE builds an awesome Dash app for battery storage in Germany
@Muntakim is working on Dash-ThreeJS for interactive 3D visualizations
@Leonardo contributes a double-side sidebar template to the community
All the best,