flask_jsondash ships a compose file that publishes Mongo and stores nothing

Three routes in, one database requirement

The quickstart gives three ways to get it running. The first uses the Flask app that ships with the repository, which also installs the package into a fresh virtual environment:

git clone https://github.com/christabor/flask_jsondash.git
cd flask_jsondash
virtualenv env
source env/bin/activate
python setup.py install
cd example_app
python app.py

That example app comes up on port 8080. The second route is a single pip install of flask-jsondash for an application you already have, where your job is to import and register the blueprint and add the template tags it needs, with a working example in the example app's base layout. The third route is Docker, and it is the one with the most moving parts.

Mongo has to exist before the first dashboard

Dashboards are saved, not computed, so a database is a hard requirement rather than an optional extra. Five environment variables configure it: the host, which defaults to localhost, the port, which defaults to 27017, the database name, which defaults to charts, the collection name, which defaults to views, and the backend selector, whose only listed option is mongo and whose default is mongo. The instructions are explicit that you start the database yourself, that mongod will work, and that the collection has to be created inside your Mongo instance and named through the collection variable. That last step is the one that bites, because nothing in the library creates the collection for you. The setup file pins the Mongo driver at a single version and adds a validation library to the core requirements.

The compose file publishes the database and stores nothing

The Docker route is a make target that builds a base image and then brings up the compose services, and the file it uses has three of them. The database service is named jsondash-db, runs the mongo image with the latest tag, and maps port 27017 straight through to the host. It has no volume. The other two services build from the repository's own Dockerfiles, the endpoints app on 5004 and the dashboard app on 8080, both bound to all interfaces and linked to the database by name. So a default Docker deployment exposes an unauthenticated database on your host's port 27017 and keeps no data across a container replacement, which is the exact opposite of the README's own advice further up: for any serious usage you will always want external volumes for Mongo so your data is persisted outside of Docker.

Three pieces of package metadata contradict each other

The setup file is worth reading against the rest of the project. It declares version 6.3.3, while the newest published release is 6.2.3 from 2017-06-13, preceded by 5.0.0 and 4.0.0 in 2016, so the number in the manifest was never released under that tag. It declares the licence as MIT and then lists a classifier naming the BSD licence as the approved one. And it lists a single programming language classifier, Python 2.7, while the README documents a parallel set of Python 3 commands using a Python 3 virtualenv and the python3 executable. The last commit on the default branch is dated 2026-06-26 and the repository is not archived, so the code is being touched nine years after the last release, with metadata that still describes the 2016 packaging.

The word cloud chart is an extra, not a dependency

The core install requirement list is four entries: a command line library pinned to an exact old version, Flask itself, a validation library, and the Mongo driver at a single pinned version. Everything else is either optional or absent. One extra group exists, named for the word cloud utilities, and it pulls in an HTTP client, a query helper and a request mocking library, which means the word cloud chart type cannot work from a plain install. The test requirements tell a different story about age: the test runner is pinned to a recent major version while the coverage plugin sits on a much older major line in the same list. The frontend libraries follow the same split, described as either something you are expected to have already or something bundled on the odds you do not.

The Makefile targets a 2016 workstation

The build file is a good archaeology layer. The test target shells out to tox. The coverage target runs pytest with an HTML report and then opens the report with the open command, which is the macOS one and fails elsewhere. The dockerize target builds the base image and then calls docker-compose, the version 1 spelling, and the compose file itself declares version 2 with legacy service links rather than networks. The publish target calls setup.py sdist upload against PyPI, a command path that later setuptools removed, and the sort target passes isort a recursive flag that later isort versions dropped. The fixtures and test data targets call a module inside the package with switches for dumping, loading and deleting records, which is also how the example dashboards get into the database.

Charts are declared as JSON and the library formats nothing

The configuration is a JSON object with a modules array, and each module names a chart type, a name, a width, a height, the endpoint to read from and an order:

{
    "modules": [
        {
            "type": "timeseries",
            "name": "name3",
            "width": 510,
            "height": 400,
            "dataSource": "http://localhost:5001/test1",
            "order": 0
        }
    ]
}

The README is explicit that the power comes from the charting libraries it defers to, so your endpoint has to return a payload shaped the way those libraries expect, documented per chart type. From version 4 you can also declare custom inputs per chart, which map to query parameters on your endpoint, with button styling, a submit label and an options array; the order you declare the inputs in is the order they appear on the page. That second example stops in the middle of its options array, at a key that begins with input, and the README says the full set of options lives in the example configs.

Seeing the charts means running a second app

The demo instructions ask you to start the endpoints Flask app that ships with the repository alongside your own app, create a dashboard, and then choose the edit raw json option and pick one of the example configuration files. The note under it says this was tested using MongoDB. That is the whole demo path, and it is a fair description of the project's shape: a blueprint that renders whatever the charting libraries can draw, fed by endpoints you supply, with layouts stored in a database you provision. Drag-and-drop layout editing, grid or freeform placement, and templates and iframes for embedding all sit on top of that, and the repository keeps the example app, its templates, its example configurations and a separate JavaScript test directory alongside the package itself.

Editorial conclusion

flask_jsondash suits an existing Flask application that already has an endpoint returning correctly shaped JSON and a Mongo instance to store dashboards in, and it will cost you an afternoon if either is missing. Check four things first: whether your endpoint payload matches the documented schema for your chart type, because the library defers formatting entirely to the charting libraries it wraps, whether you create the Mongo collection by hand before the first save, whether you add a volume for the database yourself since the shipped compose file does not, and whether the version you install matches the metadata, since the setup file, the release tags and the classifier list do not agree with each other. The interactive chart inputs are the feature worth checking on a trial.

Frequently asked questions

Official sources

1. christabor/flask_jsondash on GitHub
2. Issues
3. License: MIT
4. README
5. Releases