Heavy or Sensitive data


So far we've dealt with small, fully public datasets. Most of the time stored in a data.js file, and more recently fetched from somewhere else on the internet.

But what if the dataset is too big for the browser? Or if you need to get private data with authentication? Or if you need to run some heavy statistical models? It's time to set up a server.

Members only
5 minutes read

❌ The problem

So far, this course has always been based on static applications: we write some JavaScript code that is executed by our readers' browsers. All the logic runs on their computer!

⚠️ The concept of static vs dynamic website is crucial. It's described in module A, together with other core concepts about web development. Read it again!

Building static applications is powerful and comes with a lot of advantages. It's free, it's fast, and your app can handle millions of concurrent users without breaking a sweat.

But it also comes with big limitations:

❌ Everything is public

Every file you ship, including your data, is downloaded by the browser. Anyone can open the Network tab and read it. There is no way to hide an API key, a credential, or a proprietary dataset.

❌ No authentication

Every visitor gets the exact same files. Without a server, you cannot check who is asking, so you cannot serve per-user content or protect a private page behind a login.

❌ Limited computational power

The whole dataset is shipped to the client, and the client has to do everything. Transferring a large file can be slow, and wrangling it in the browser can freeze the tab, especially on a phone.

❌ Everything is frozen

The data is baked in at build time. It only changes when you rebuild and redeploy the site, so you cannot display data that updates often, like a live price or the latest sales.

❌ Read only

There is no database and no server to write to, so a static site cannot store a form submission or any user input on its own.

✅ Solution: you need a server

The fix is always the same: split the app in two.

The frontend (the React code you already know) only displays things. A backend (a server you control) does what the browser cannot or should not do: query a database, crunch a huge dataset, run a model, or hide a secret. It then sends back a short, clean dataset, ready to plot.

Frontend

Runs in the browser

  • HTML, CSS, JavaScript
  • What users see & interact with
  • React, Vue, Angular

Backend

Runs on the server

  • Node.js (JavaScript), Python, Ruby, Go
  • Business logic, security
  • Database access, authentication

The good news? Your React code barely changes. It is still the exact fetch and loading state pattern from the previous lesson. The endpoint just points to a server you wrote instead of a public API.

Building that backend is a fullstack job, beyond the scope of this course. But you should know the architecture and the keywords, so here are two common setups you might meet at work.

Oh no! 😱

It seems like you haven't enrolled in the course yet!

Join many other students today and learn how to create bespoke, interactive graphs with d3.js and React!

Enrollment is currently closed. Join the waitlist to be notified when doors reopen:

Or Login