Backend (Day 2), endpoint (Day 7), request and response (Days 8 and 9), status code (Day 10), port (Day 28). The server is the thing all of those happen on. Two meanings, both correct: The hardware: a computer that stays on and is reachable over a network. Often in a data center, sometimes just a laptop on localhost. The software: a program that listens on a port, accepts requests, runs your backend code, and sends responses. A web server (nginx, Apache) mostly hands out files and forwards requests. An application server runs your code. A database server answers queries. One machine can run all three. When you type npm run dev and it says "Listening on port 3000", you've started a server. The difference between that and production is who can reach it and whether it stays up. Quick check: Your app's backend crashed, but you can still ping the machine it was on. Is "the server" down? ## SPOKEN LINES - The feed takes twenty seconds and you blame your phone. The machine doing the work sits in a building you will never see. - - SERVER - - A server is a computer whose job is to wait for requests and answer them. Your phone asks for the feed, and the server sends the posts back. - - Instagram runs on machines in a data center that never switch off. Your laptop running a program on port 3000 is a server too. And the server is down can mean the machine or the program. - - So a server is a computer or program that answers requests. Tomorrow: Hosting, where that server lives once it is not your laptop. - ## NEXT - Day 30: Hosting

An address gets a message to the right machine. A port gets it to the right program on that machine. Every endpoint (Day 7) you've called had a port in it, even when you couldn't see it: https://api.example.com/users is really https://api.example.com:443/users http://localhost:3000/users says the 3000 out loud A few worth recognizing: 80: http 443: https 5432: Postgres 3306: MySQL 6379: Redis 3000 / 5173 / 8080: common dev servers Two rules explain most port errors. One program per port, so a second copy of your app on 3000 fails to start. And the port in your frontend's request has to match the port the backend is listening on, or you get a "connection refused" error that looks scarier than it is. Quick check: Your backend says "Listening on port 4000" but your frontend is calling http://localhost:3000/api/users. What happens? ## SPOKEN LINES - The terminal says port 3000 is already in use, and nothing loads. Your laptop is juggling a browser, Spotify, a video call and your app, and two of them wanted the same number. - - PORT - - A port is a number that says which program on a machine a message is for. Localhost is the building with one street address, and the port is the apartment number. - - Websites use 443 for https, Postgres listens on 5432, and development servers grab 3000, 5173 or 8080. - - So a port is the number that picks out one service on a machine. Tomorrow: Server, the computer on the other end of all these requests. ## NEXT Day 29: Server

localhost is a hostname that always means "this machine". It maps to the IP address 127.0.0.1, which the network stack treats as a loop back to itself. That's the development environment (Day 25) in practice. When you start a backend with something like npm run dev, it prints a line such as: Listening on http://localhost:3000 Your browser sends a request to that address, the request never leaves your computer, and your code responds. Same request, response, and status codes as the real thing (Days 8 to 10), with no server rented anywhere. Things that confuse people the first week: Two people can both be "on localhost" and be looking at completely different apps. It's each person's own machine. A localhost link in a text message goes nowhere for the recipient. Your phone on the same wifi can't open localhost either. It needs your computer's network address instead. Quick check: Your teammate sends you http://localhost:3000/dashboard and says "look at this". What do you see when you open it? ## SPOKEN LINES - Your friend opens the link you sent, localhost port 3000, and texts back a blank page. It works in your browser. That address points somewhere different on their machine. - - LOCALHOST - - Localhost is the name your computer uses for itself. It points to the number 127.0.0.1, which always means this machine. While you build, the frontend, the backend and often the database all run there before anywhere else. - - Localhost 3000 is your app in the browser, localhost 5432 is the database on your laptop, and yesterday's database URL probably says localhost. - - So localhost is your own computer acting as the server. Tomorrow: Port, what the 3000 means. ## NEXT Day 28: Port

An environment variable is a name and a value that live in the environment (Day 25), outside the code. Two jobs. Config that differs per environment: DATABASE_URL, the API base URL, whether debug output is on. Secrets that must never be in the repository: API keys, passwords, signing tokens. The code reads them by name. In Node it's process.env.DATABASE_URL, in Python it's os.environ["DATABASE_URL"]. Same code, different value depending on where it runs. Locally, a .env file holds them, and .gitignore keeps that file out of commits. Push an API key to a public GitHub repository and bots scanning for exactly that will find it fast. Quick check: Where should your Stripe secret key live: in the code, or in an environment variable? ## SPOKEN LINES - You push the code and the real database password goes to GitHub with it. Now it sits in the history for anyone to read. - - ENVIRONMENT VARIABLE - - An environment variable is a named value the operating system hands to the program when it starts. The code reads the name and gets whatever value that environment set. - - A variable called database URL points at your laptop in development and the database in production, stripe key holds the payment secret, and port says which number to listen on. - - So an environment variable is a setting kept outside the code and read in at startup. Tomorrow: Localhost, the address your own computer uses for itself. ## NEXT Day 27: Localhost

One of the biggest mistakes I see people making when building software with LLMs is assuming that because their agent says something works, it actually works. We've all done it. You ask Claude Code or Codex to build a feature. It writes the code, tells you everything is working, and gives you a nice summary of what it accomplished. You open the application, click around a little, and move on to the next feature. But did you actually test it? Does the form save the correct information? What happens when someone enters invalid data? Can one user access another user's records? What happens when the network fails halfway through a request? These are the kinds of questions a quality assurance (QA) tester asks. And you don't need to know how to write code to start asking them. There's an open-source tool called **Playwright** that can help you turn your coding agent into a much more useful testing assistant. ## What is Playwright? Playwright is a browser automation framework developed by Microsoft. It allows software to control a real browser, interact with websites, complete forms, click buttons, and verify what happens afterward. With **Playwright MCP**, you can connect those browser capabilities directly to Claude Code, Codex, or another compatible agent. MCP stands for Model Context Protocol. Think of it as a standard way of giving your LLM access to external tools. Instead of just reading your application's source code, your agent can now open the application in a browser and interact with it. It can: - Navigate between pages and test links. - Fill out forms and submit information. - Test authentication and protected routes. - Check whether buttons perform their intended actions. - Inspect browser errors and failed network requests. - Capture screenshots to help diagnose problems. - Compare the application's actual behavior against your requirements. Playwright MCP primarily uses a structured representation of the webpage, called an accessibility snapshot, to understand its controls and content.