Craft · Glossary
Web app anatomy — the words you actually need
You don’t need a computer science degree to build with AI, but a handful of words carry real weight when you’re describing what you want or reading back what the studio built. This glossary is sortable and filterable by which layer of the app each word belongs to.
What you’re browsing for vs. what you need to know: you’re probably here to look up one term. What’s actually useful is the “common misunderstanding” column — that’s where a generated app quietly disappoints people who didn’t know to check.
The glossary
Eleven terms, by layer
Click a column header to sort; click a layer chip to filter.
| Why it matters when building | Common misunderstanding | ||
|---|---|---|---|
| Frontend (client-side) | The part that runs in the visitor’s own browser — what they see and click, built from HTML, CSS and JavaScript. | It’s the only part a visitor directly experiences, but it runs on their device — you don’t control it once it’s loaded. | Assuming hiding something in the frontend (a button, a check) “protects” it — anyone can view a page’s delivered code. |
| Backend (server-side) | The part that runs on a server you control, not the visitor’s device — it handles data, rules and anything that must be trusted. | This is where real enforcement happens; a rule that only exists in the frontend isn’t actually enforced. | Thinking “the app” is only the part you can see — a page with no backend can’t safely store or verify anything. |
| API | A defined contract of requests and responses letting one piece of software ask another to do something. | It’s the seam where your frontend, backend and any third-party service connect — most bugs live at this seam. | Assuming “the AI added an API” automatically means it’s secured or rate-limited — a contract isn’t a safety guarantee. |
| State | The data that persists across a visitor’s interactions — what’s in a cart, whether they’re signed in — as opposed to something recomputed fresh each time. | You must decide, explicitly, where state lives (a browser tab, a cookie, a database) — each has a different lifetime. | Assuming a value held only in a page’s JavaScript will “still be there” after a refresh — it won’t, unless it was saved server-side. |
| Database | Structured, durable storage the backend can read and write on every request — not a spreadsheet only you can see. | If “your data” only lives in the browser, it’s tied to one device and can vanish if storage is cleared. | Believing an app “has a database” just because it was described that way — check the data survives a refresh and a new device. |
| Deploy / deployment | Making a build available at a real public address, instead of only running on your own machine or a preview window. | A preview that “works” isn’t yet reachable by anyone else; deploying is the step that makes it real and shareable. | Treating “it previews correctly” and “it’s deployed” as the same milestone — they’re different steps with different failure modes. |
| Domain name | A website’s human-readable address (like example.com), standing in for a numeric network location. | It’s what you put on a business card or an ad, and it carries your reputation and search ranking over time. | Confusing owning a domain with having it live — you still need to point it at wherever the build actually runs. |
| DNS | The hierarchical system that translates a human-readable domain name into the numeric address computers use to find it. | DNS changes (like pointing a new domain at a deployment) take time to spread across the internet. | Expecting a DNS change to be instant everywhere — it propagates gradually as cached records expire. |
| HTTP request & response | The basic exchange of the web: a client sends a request, a server sends back a response. By design, HTTP doesn’t remember previous requests on its own. | This statelessness is exactly why “staying signed in” needs an explicit mechanism rather than happening automatically. | Assuming the server “remembers” a visitor between requests by default — it doesn’t unless something adds that memory back. |
| Session & cookie | A small piece of data the server asks the browser to hold and resend on later requests, faking continuity on top of stateless HTTP. | It’s the standard mechanism behind “stay signed in” and shopping carts — and a real security surface if mishandled. | Assuming a cookie is inherently unsafe or inherently safe — it depends entirely on how it’s set and what’s stored in it. |
| Environment variable / secret | Configuration or credentials (like an API key) kept outside the code itself, supplied to the running app rather than written directly into it. | A secret written directly into frontend code is visible to every visitor; kept server-side, it isn’t. | Assuming an API key “hidden” in JavaScript is actually hidden — anyone can view a page’s delivered code. |
Showing 11 of 11 terms.
Once the words make sense, the next question is usually whether what got built actually uses them properly — a real backend, a real database, real auth.
Sources
- MDN Web Docs, “API” — Glossary. developer.mozilla.org/en-US/docs/Glossary/API. Accessed 27 Jul 2026.
- MDN Web Docs, “Client-Server overview” — Learn web development. developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Client-Server_overview. Accessed 27 Jul 2026.
- MDN Web Docs, “Domain name” — Glossary. developer.mozilla.org/en-US/docs/Glossary/Domain_name. Accessed 27 Jul 2026.
- MDN Web Docs, “DNS” — Glossary. developer.mozilla.org/en-US/docs/Glossary/DNS. Accessed 27 Jul 2026.
- MDN Web Docs, “Overview of HTTP” — HTTP's stateless design. developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview. Accessed 27 Jul 2026.
- MDN Web Docs, “Using HTTP cookies.” developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies. Accessed 27 Jul 2026.
FAQ
Good to know
Do I need to know all this to use an AI app builder?
No, but knowing these words helps you ask sharper questions and notice when a generated build has quietly skipped one of them — like having no real backend, so “your data” only ever lives in your own browser.
What’s the difference between “the frontend” and “the whole app”?
The frontend is only the part that runs in a visitor’s browser. A real app usually also has a backend handling data and rules on a server you control — a page with no backend at all can’t safely store or verify anything.
If the AI says it added a database, how do I know it’s real?
Check that the data actually survives a refresh, a closed tab, and ideally a second device or browser. If it only survives within the current tab’s memory or the browser’s local storage, it isn’t a real, durable database yet. See the readiness checklist.
Why doesn’t my new domain work immediately after I point it at my deployment?
DNS changes propagate gradually as different networks’ cached records expire, rather than updating everywhere instantly — this is normal and expected, not a sign something is broken.