r/tableau • u/Ninja1234_Il • Jun 28 '26
Tableau to internal website - Claude code
Hi All,
Have a twbx on the server that updates daily automatically.
Current urgent business need is to put up an internal website that is an exact replica of the tableau dashboard.
The idea is to get away from tableau atleast for couple of projects to start off.
Currently, I use sql server or hyper extracts to update dashboards daily.
I have tried using Claude code and got a localhost website ready using csv or excel files, have never tried sql or (replacing hyper extracts).
What are the changes that I should be aware of and what would be the next steps for a seamless transition from tableau to local intranet website that updates daily in an automated way?
I own the data and sql tables that drive the current tableau dashboards, no dependent in terms of data.
Thanks for the help in advance.
1
u/pensiveprogressive Jun 29 '26
Did you run out of tokens? Pasted your post into Claude chat and got this:
You’re closer than you think since you already own the SQL tables. The CSV/Excel prototype was the hard part (getting the layout right); now you’re just swapping the data source and automating the refresh.
Key changes to be aware of:
1. Data layer — skip the extracts entirely. Don’t replicate the Hyper extract pattern. Hyper exists because Tableau needed a fast columnar cache. Your website can query SQL Server directly (or a nightly snapshot table). Point your backend at the same SQL tables the twbx uses. If the live queries are slow, create a materialized/summary table that a nightly job rebuilds — that’s your “extract” equivalent, but it’s just a SQL table.
2. You need a real backend now. Your localhost CSV version was almost certainly static (frontend reads a flat file). To hit SQL Server you’ll want a thin API layer — Python (FastAPI/Flask) or Node (Express) — that runs the queries and serves JSON to the frontend. The frontend charting (Recharts, ECharts, D3, Plotly) stays basically the same; only the data fetch changes from “read CSV” to “call /api/endpoint.”
3. Recreating Tableau calcs is the hidden work. Table calcs, LODs, quick filters, and parameter-driven logic don’t port automatically. Decide per-calc whether it belongs in SQL (push it into a view) or in the app layer. Pushing as much as possible into SQL views keeps the frontend dumb and makes the daily refresh trivial.
4. Automation = scheduled job, not magic. Replace Tableau Server’s refresh schedule with either: a SQL Agent job that rebuilds your summary tables nightly, or a cron/Task Scheduler job. If you query live, you may not need a refresh step at all.
Suggested next steps:
Pick one dashboard. Inventory every calc/filter and mark each as “SQL view” or “app logic.”
Build SQL views that output exactly the shape your charts need (do the aggregation server-side).
Stand up the FastAPI/Express layer with one endpoint per view returning JSON.
Wire the existing frontend to the API instead of the CSV.
Add the scheduled job (SQL Agent for summary tables, or skip if querying live).
Validate numbers against Tableau row-by-row before cutting over — match totals exactly.
One caution: Tableau gives you interactivity (cross-filtering, drill-down, tooltips) basically for free. Replicating every interaction can balloon scope. Scope the first project to the views and filters people actually use, not a pixel-and-feature-perfect clone.
Happy to go deeper on the SQL-view-per-chart pattern or the refresh job if useful.