DataChart: A Dashboard Builder That Got Bigger Than a Dashboard Builder

Most reporting tools have the same shape. You pull data out of somewhere, you pick a chart, you arrange a bunch of charts on a page, and then somebody asks for it as a PDF. I wanted to see how much of that I could build myself, end to end, as one app.

datachart is the result. It's an open-source, multi-tenant dashboard builder with a FastAPI backend and a React front end, and it's MIT licensed. It also grew well past "put a chart on a page," which I'll get to.

What it does

The core idea is a dashboard builder: drag widgets onto a grid, point each one at a data source, and see it update as you go. Around that, the README lists a handful of bigger pieces:

Feature	What it means here
Dashboard Builder	Drag-and-drop chart and widget placement with a live preview
Data Sources	Connectors for pulling data from databases and services
APM Monitoring	Application performance dashboards and alerts
Multi-Tenant	Separate tenant workspaces with role-based access
Export	PDF, Excel and CSV from any dashboard
Billing	Stripe-based subscription tiers (Starter, Professional, Enterprise)
AI Agents	Automated analytics and anomaly detection

The file tree backs most of that up. There's an export service, a Stripe service, an ai_agents service module, and a whole folder of front-end components for the APM dashboard, including a draggable widget, a masonry grid, a KPI renderer and modules for things like license harvesting, renewal timelines and vendor consolidation. That last group is where the project wandered from generic charting into application portfolio management. I let it.

How it's put together

The backend is FastAPI with SQLAlchemy models, Pydantic schemas and Alembic migrations. Routes live under a versioned api/v1 folder: dashboards, data sources, exports, billing, monitoring, onboarding, users. There's a WebSocket route too, for pushing live updates to open dashboards.

Data comes in through connectors. Each one extends a shared base class, and the repo has four of them today: PostgreSQL, Snowflake, Oracle and Salesforce. Azure and ServiceNow show up as service modules rather than connectors. The README also mentions REST APIs as a source, but I don't see a dedicated connector for that yet, so call it a goal.

Multi-tenancy is handled in middleware. A multi_tenant middleware sits in front of the API alongside a rate limiter, so tenant isolation isn't something each route has to remember to do.

The front end is React 19 and TypeScript, with Recharts, Chart.js and Tailwind for the charts and styling. Deployment configs cover Docker Compose, a Kubernetes manifest, Nginx, and a Prometheus and Grafana setup with its own alert rules. Yes, the dashboard builder ships with dashboards for monitoring the dashboard builder.

Using it

You can run the two halves separately. Backend first:

cd backend
pip install -r requirements.txt
cp .env.example .env   # fill in your values
alembic upgrade head
uvicorn app.main:app --reload

Then the front end:

cd frontend
npm install
cp .env.example .env   # fill in your values
npm start

Or skip all that with docker-compose up -d.

Heads up

The backend needs at least DATABASE_URL, SECRET_KEY for signing JWTs, and a Stripe key before it'll behave. Use your own test values, and keep them in .env, never in the repo.

Rough edges

I'd rather be upfront about this one, because the feature list reads bigger than the codebase is mature.

A fair amount of it runs on mock data. There's an APM mock service, a demo data service and a mock Snowflake dataset, which is great for clicking around and less great if you're expecting every screen to hit a live source. The tests are thin: a conftest, an API test and an auth unit test. There's some duplication I haven't cleaned up yet, like apm.py sitting next to apm_refactored.py, and two different customer models. The README also lists Redis and Elasticsearch in the database layer, and I'd treat those as planned rather than wired in.

Note

The billing code exists to model subscription tiers. It's plumbing, not a storefront.

If panels in a layout like this ever refuse to scroll, I wrote up the flexbox min-height: 0 fix separately. And if you'd rather see an app idea at the other end of the maturity scale, FlowDrive is still on paper, while Terminal News sits somewhere in the middle.

What's next

Mostly consolidation. Fold the duplicate modules together, grow the test suite, and swap mock services for real connectors one at a time. The code is all on GitHub if you want to poke at it.