What Happens When You Click a Link - Part 2

In Part 1, your browser packaged up a request and sent it across the internet. It found the right address, set up a secure line, and placed its order. Now that request has arrived somewhere. A computer received it. What happens next?

The Server Is Just a Computer

A server is not some mysterious machine in the clouds. It's just a computer that's always on, waiting for requests. That's it. It's not magic. It's a machine running your code, ready to respond when someone shows up.

During development, your own laptop is the server. When you deploy your app to the world, it runs on someone else's computer in a data center. Same idea, different location. The concept doesn't change, only where the machine sits.

Think about it this way. When you type a prompt into Claude, some computer somewhere receives it and starts working on a response. Your server does the same thing. Someone visits your app, your server receives the request, and it gets to work.

Matching Requests to Code

Not every request asks for the same thing. When someone visits /home, they want the homepage. When they visit /dashboard, they want the dashboard. When they submit a login form, they're sending credentials. The server needs to figure out which piece of code should handle each request.

This process is called routing. You define the routes in your code. You're basically telling the server: "When someone asks for this URL, run this code."

Claude does something similar. When you ask it a coding question, it approaches it differently than when you ask it to write a poem. It figures out what kind of question you're asking and routes to the right approach. Your server does the same thing with URLs. Different request, different code.

Where Your App Comes to Life

Once the server finds the right code to run, it executes it. This is where things get interesting.

The server might check if you're logged in. It might verify whether you have permission to see a certain page. It might query the database for your specific data. It might apply some business rules, your special sauce, the thing that makes your app yours. Then it prepares a response to send back.

This is the "brain" of your app. When Claude processes your prompt, it draws on its training and context to generate a response. Your server draws on your code and your database to do the same. Same pattern. Input comes in, logic runs, output goes out.

Your Server's Memory

Most requests need data. "Show me my dashboard" means the server needs to look up your specific information. Where does it find it? The database.

The database is where your app stores everything. User accounts, posts, orders, comments, settings. It's the server's long-term memory. Without it, your app would forget everything the moment a request finishes.

The database can live on the same machine as your app or on a separate one. Either way, the server talks to it, asks for what it needs, and uses that data to build a response.

Think of it like Claude drawing on its training data to answer your questions. Your server draws on its database to answer requests. The data source is different, but the idea is the same.

What YOU Are Actually Building

Here's the thing that changes your perspective.

When you vibe code, you're building the thing that answers the request. You're not building the browser. You're not building the internet. You're building everything on the other side. The pages people see, the routes, the logic, the database queries, the responses. That's your app. From the screen someone sees in their browser to the data stored in your database, all of it is what you're creating.

When someone visits your app and clicks a button, your code is what responds. You're building the thing on the other end of the line.

---

So far:

A request arrives at your server. The server matches the URL to the right code (routing). That code runs, checks permissions, queries the database, and applies your logic. Then it prepares a response.

But the job isn't done yet. That response still needs to travel back to the browser. In Part 3, we'll see how the server sends its answer back and how the browser turns it into the page you actually see.