APIs, data flow, static vs dynamic, dev vs production
Last episode we met the four parts:
frontend, backend, database, UI/UX.
Knowing the parts is not enough.
You also need to know
how they work together.
Without that,
you end up in the "second outcome" from EP.1.
The site runs,
and you have no idea why it runs.
This episode covers four ideas.
80% of the walls vibe coders hit come back to them.
The frontend and the backend are two separate things,
and they do not go looking for each other.
They need a walkie-talkie.
That walkie-talkie is the API.
API stands for Application Programming Interface,
which sounds complicated.
In plain words it is just "the way they talk".
That whole round trip
is one API request.
Every app and every website you open
is firing API requests nonstop behind the scenes.
Scrolling IG, scrolling Threads, pressing buttons, scrolling a page,
most of those actions are talking to a backend.
When you talk to AI, remember just one thing:
when you say "after this button is pressed, do X",
AI writes you an API.
Four parts plus an API,
strung into one complete action. What does that look like?
Here is a real case from NaLi Match.
What happens when a customer presses "send request" on NaLi Match?
Behind one button,
six things are running.
You do not need to write any of it,
you just need to know the six exist.
When something breaks,
that is how you know which step to ask AI about.
Know the flow
and your debugging gets precise.
This idea saves you a pile of work.
Not every site needs a backend and a database.
The key idea:
"Static" does not mean nothing on the site moves.
It means there is no backend server of your own running code.
You can still use third-party services (Supabase, Firebase, Disqus)
to give a static site dynamic features.
The mistake vibe coders make most:
what they need is a landing page,
and they open by asking AI for a database, a login system and APIs.
Three days later it is still not live.
Do not use a sledgehammer on a nut.
If static works, do not go dynamic.
You can just ask AI straight out:
"Does this product need a backend, or is pure frontend enough?"
Let AI make the call.
You will hit this one 100% of the time,
so I want to cover it now.
Your site actually lives in two worlds:
They are separate worlds.
Change something on your computer
and nothing changes online by itself.
You have to deploy
before the live version updates.
Why does that happen?
Because the two worlds have different setups:
different file paths,
different URLs,
different API keys,
different databases.
So "it runs in dev"
does not mean "it runs in production".
EP.6 covers deploying on Vercel in practice.
But the "two worlds" idea
is one to hold onto right now.
These three are not core,
but every vibe coder trips over them sooner or later.
Here is a first impression,
later episodes go into detail.
Next time you start a project,
on top of the architecture discussion from EP.2,
you can also ask AI these:
Ask those five questions
and you will understand 80% of how your own product works.
These two are a bit more advanced.
They will not stop you from building,
but knowing them makes you sharper.
As a rule, yes.
But a few keys are designed to be public.
Supabase's anon key, for example.
It is meant for the frontend,
because Supabase uses a mechanism called Row Level Security (RLS)
to control who can read and write each row at the database level.
So whether a key can go in the frontend
is not about whether it is called a "key",
it is about whether something is protecting it.
The safe habit for vibe coders:
if you are not sure, keep it in the backend.
Put it in the frontend only when the service's docs say "safe to expose in browser"
or "public anon key".
I wrote "http://localhost:3000" above.
That is the default URL when you develop with a framework like Next.js, Vite or React.
localhost means "your own computer",
and 3000 is the port this service is using.
If you only wrote a plain HTML file,
double-clicking it opens a URL that starts with file:// ,
which is the path to a file on your own machine.
Both count as a "dev environment",
and they share one trait:
only you can see it, nobody else can reach it.
Once it is online it becomes a real domain starting with https://,
and that is production.
EP.2 was the parts, EP.3 was how they run.
The map is drawn. Next episode we start building.
Next episode covers
how to build your first web page with AI.
HTML, CSS and JavaScript,
what each of them does,
all in one episode.
An API is the walkie-talkie between frontend and backend. The full name is Application Programming Interface. The frontend says "give me this member's order list", the backend fetches it from the database and sends it back, and that whole round trip is one API request. Every app and website is firing API requests constantly.
A static site is one with no backend server of its own running code. Pure frontend is enough: landing pages, portfolios, guides. If what you are building has no member system, orders, comments or chat, pure frontend does the job and saves you a pile of work. leoaido.com itself is a pure static site.
Because your site lives in two worlds, the dev environment (the version on your computer) and production (the version online). File paths, API keys and databases all differ between them. After a change you still have to deploy before anything online updates.
As a rule, yes. A few keys are designed to be public, though. Supabase's anon key is meant for the frontend, because Row Level Security protects things at the database level. The test is whether the official docs say "safe to expose in browser".
Usually six things run in order: the frontend catches the event, the frontend calls the API, the backend doorkeeper checks it, the backend writes to the database, the backend returns a result, the frontend shows it to the user. Knowing the flow is what lets you pinpoint which step broke when you debug.