Working with Databases and APIs

Two things every app eventually needs: somewhere to keep information, and a way to talk to other services. Both have a beginner trap in them.

Where your data lives

If your app "remembers" things, ask where. There are two very different answers.

Browser storage keeps data on the visitor's own device. It is instant, free, and needs no setup — which is why AI tools reach for it constantly.

It is also, and this catches everyone:

• Only on that device, in that browser. Your phone will not see what your laptop saved.
• Gone if they clear their browser data. Permanently.
• Small, and it holds text only.
• Not private. Anyone using that device can read it. Never put anything sensitive there.

That is perfect for a personal timer. It is wrong for anything with accounts, shared data, or anything you would be upset to lose.

A real database lives on a server. Every device sees the same data, it survives a cleared browser, and it can be backed up. It costs a little and takes setup. When your app has real users, this is the answer.

The trap: an AI asked to "save the tasks" will usually pick browser storage without mentioning any of the above. So ask directly — where is this data stored, and what happens if the user clears their browser?

The full version of this is in localStorage Is Not a Database.

APIs, in plain words

An API is how one program asks another program for something. Your app wants today's weather; it asks a weather service; the service answers with data. Like a waiter carrying an order to a kitchen you never see.

Two things go wrong for beginners, and they both have simple fixes:

The answer takes time, and might not come. The internet is slow and sometimes broken. Your app needs three states, not one: loading, worked, and failed. AI code often writes only the third-of-three — the happy path — so ask for the other two explicitly.

The key must not be in your app. This is the expensive one.

The API key rule

Many services give you a secret key that proves requests are yours — and that is also how they bill you.

Anything in a web page can be read by anyone who visits it. "Hidden" in a JavaScript file is not hidden; it takes about ten seconds to find. People run automated scans for exactly this, and a leaked key can be used until you notice the bill.

So the rule: a secret key never goes in code that runs in the browser. It belongs on a server you control, which talks to the service on your app's behalf.

If an AI ever puts a key directly into a web page for you — and it happens — that is not a style preference to accept. Ask for it to be moved server-side.

Security is where this comes up again — it opens the next phase, alongside the other things worth checking before real people use your app.