Frontend and Backend: The Full Picture

Before You Study (5 mins)

Lesson focus: Every web application — Instagram, your bank, Netflix, the small e-commerce shop your cousin runs — is a system with three roles split across at least two physical machines: a frontend that runs in the user's browser or app, a backend that runs on a server you control, and (in Lesson 14) a database that persists data. Today we cleanly separate these roles. By the end, you will have built a Node.js + Express backend running alongside your Snake game frontend, and you will be able to articulate, with no fuzziness, why certain code lives on the server and certain code lives in the browser.

What you should have ready:

• Node.js installed (node --version should print 18 or higher)
• Your Snake game (the frontend you've been building)
• Lesson 11's ai.js from yesterday — we'll reuse the LLM call from a backend route
• About 60 minutes
• An npm init -y ready to run in a fresh backend/ directory

The Concept

A web application's code lives in at least two places, and the boundary between them is one of the most important architectural distinctions you will learn:

  ┌────────────────────────┐                          ┌────────────────────────┐
  │      FRONTEND          │   HTTP requests (JSON)   │       BACKEND          │
  │  (browser / mobile)    │  ◀─────────────────────▶ │   (your server)        │
  │                        │                          │                        │
  │  • HTML / CSS / JS     │                          │  • Node.js + Express   │
  │  • What user sees      │                          │  • Business logic      │
  │  • User input handling │                          │  • Auth & sessions     │
  │  • Visual rendering    │                          │  • Talks to DB         │
  │  • Lives on the user's │                          │  • Calls 3rd-party APIs│
  │    device              │                          │  • Lives on a server   │
  │                        │                          │    you control         │
  └────────────────────────┘                          └────────────────────────┘
       Public — anyone can                                  Private — only you
       view source code                                     and your team see it

The reason this split exists is simple: anything you put in the frontend is visible to every user. If you write your LLM API key into a <script> tag, someone can open DevTools, copy your key, and burn through your provider quota by tomorrow morning. If you compute a "10% off" discount in JavaScript, anyone can change it to 100%. If you check if (user.role === "admin") in the browser, the user can edit user.role in DevTools and become an admin.

The inverse is also true: the backend cannot run on the user's screen. It has no DOM, no clicks, no visual rendering. The server's job is to execute logic, talk to other servers, and return data. The frontend's job is to render that data and capture user intent.

Three categories of code, and where each one belongs:

The two halves communicate over HTTP, almost always with JSON bodies. The frontend sends a request (POST /api/scores with { "name": "Divyanshu", "score": 100 }), the backend processes it (validates, stores in DB, computes a response), and sends back JSON ({ "rank": 4, "topScores": [...] }). This is the same request-response cycle from Lesson 09 — but now you control both ends.

The third role — database — is the persistence layer. The backend talks to it; the frontend never does directly. We add this in Lesson 14.

The most common architectural mistake in early full-stack work is putting backend code in the frontend (exposing API keys, computing prices in JavaScript, checking auth in the browser) or putting frontend code in the backend (returning HTML strings instead of JSON). The boundary is the contract; respect it and the system stays clean.

Quick Concepts

What We Will Build

By the end of this lesson, you will have done these specific things:

1. Created a backend/ directory alongside your Snake game's frontend, ran cd backend && npm init -y to initialize a Node.js project. Inspected the resulting package.json.
2. Installed Express: npm install express and npm install --save-dev nodemon. Read the package.json dependencies field — recognize that this is JSON (Lesson 08's lesson paying back).
3. Wrote your first server in backend/server.js:
   javascript

   Copy

   import express from 'express'
   const app = express()
   app.use(express.json())                       // parse JSON bodies
   
   app.get('/', (req, res) => {
     res.json({ message: 'Hello from your backend!' })
   })
   
   app.get('/api/health', (req, res) => {
     res.json({ status: 'ok', uptime: process.uptime() })
   })
   
   const PORT = 3001
   app.listen(PORT, () => console.log(`Backend running on http://localhost:${PORT}`))
   

   (Note: in package.json add "type": "module" so the import syntax works.)
4. Ran the server with node server.js. Visited http://localhost:3001 in your browser. Saw the JSON response. Used curl http://localhost:3001/api/health to confirm from the terminal.
5. Set up nodemon for hot reload: in package.json, add "dev": "nodemon server.js" to the scripts, then run npm run dev. Edit a string in your route handler. Watch the server auto-restart.
6. Added your first cross-origin call from the frontend. In your Snake game's HTML, add a button "Test backend" that calls fetch('http://localhost:3001/api/health') and displays the result. Discovered the CORS error in the browser console (Cross-Origin Resource Sharing — the browser blocks frontend-on-port-3000 from calling backend-on-port-3001 by default).
7. Solved CORS by installing cors and adding two lines to your server:
   javascript

   Copy

   import cors from 'cors'
   app.use(cors())
   

   Reloaded the page. Watched the call succeed. Noted that this is the precise moment most full-stack newcomers get stuck — and now you've solved it deliberately.
8. Moved the LLM call from Lesson 11 into a backend route: created POST /api/ai-tip that takes { prompt: "..." }, calls the Gemini API server-side (with the API key safely on the server, not exposed to the browser), and returns the response. Added a "Get AI tip" button on the game's loading screen that calls this endpoint.

Step 8 is the architectural moment. The browser sends a prompt to your backend. Your backend uses your secret key to call the model. The browser never sees the key. This is the shape of every production AI app.

Think About

Before studying, consider:

1. If your Snake game's leaderboard saved scores in localStorage (the browser's local storage), every player sees only their own scores — there is no shared leaderboard. What would have to be true for two players on different devices to see each other's scores? (A shared place where both browsers can write. That place is the backend talking to a database. Module C lessons 13-15 build it.)
2. Imagine your backend is on a different continent — Tokyo, while your user is in Mumbai. The HTTP round trip is ~150ms. How does that change what kind of work you'd want on the backend vs. inline in the browser? (Hint: things that don't need to feel instant — like saving a score — are fine on the backend; things that need to feel instant — like rendering the snake's next position — must be in the frontend.)

By the End

After this lesson, you'll:

• ✅ Have a Node.js + Express backend running on port 3001
• ✅ Have a frontend (your game on port 3000) successfully calling that backend
• ✅ Have solved your first CORS error deliberately
• ✅ Be able to articulate which code belongs in the frontend vs. backend
• ✅ Have moved your LLM call to the backend so your API key is server-side
• ✅ Understand what req and res are in an Express handler
• ✅ Be ready for Lesson 13 — making your backend into a real REST API

Two halves, one application. The boundary is the contract. 🧠

What We Learned

• A web app is at least two programs, in two physical places, talking over HTTP. The frontend lives in the user's browser; the backend lives on a server you control; the network between them is the contract.
• Anything in the frontend is public. API keys, business rules, auth checks, prices — none of these can be trusted client-side. The frontend is for rendering and capturing intent.
• The backend is for everything that must not be tampered with. Auth, billing, sensitive third-party calls, database access. The browser cannot reach into a server it can only talk to via HTTP.
• Express.js is a small, well-understood framework that turns Node.js into an HTTP server. The mental model: routes (URL + verb) → handler functions (req in, res out) → JSON response.
• CORS exists for a reason. By default, the browser refuses to let http://localhost:3000 call http://localhost:3001 because they're different origins. The cors middleware is how you opt-in to allowing cross-origin calls — and in production, you opt-in only to the specific origins you trust.
• nodemon is the developer-experience upgrade that auto-restarts the server when you save a file. Without it, you Ctrl+C and node server.js after every change. With it, you save and the server is live again in under a second.

Commands We Used

# In a fresh backend/ directory
mkdir backend && cd backend
npm init -y                         # creates package.json with defaults

# Install runtime dependencies
npm install express cors dotenv

# Install dev-only dependencies
npm install --save-dev nodemon

# After adding "type": "module" to package.json, run with hot reload
npm run dev                          # if you wired "dev": "nodemon server.js"

# Without nodemon, just run once
node server.js

# Test from the terminal (no browser needed)
curl http://localhost:3001/api/health
curl -X POST http://localhost:3001/api/ai-tip \
     -H "Content-Type: application/json" \
     -d '{"prompt":"give me one snake-game improvement idea"}'

A complete starter server.js:

import 'dotenv/config'
import express from 'express'
import cors from 'cors'

const app = express()
app.use(cors())                          // allow frontend on different port
app.use(express.json())                  // parse JSON request bodies

// ─── Routes ─────────────────────────────────────────────────────────

app.get('/api/health', (req, res) => {
  res.json({ status: 'ok', uptime: process.uptime() })
})

// LLM call — runs on the server, NEVER on the browser
app.post('/api/ai-tip', async (req, res) => {
  const userPrompt = req.body.prompt || 'give one tip'
  try {
    const url = `https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=${process.env.GEMINI_API_KEY}`
    const apiResponse = await fetch(url, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        contents: [{ parts: [{ text: userPrompt }] }]
      })
    })
    const data = await apiResponse.json()
    const text = data.candidates?.[0]?.content?.parts?.[0]?.text || ''
    res.json({ tip: text })
  } catch (err) {
    console.error('AI call failed:', err)
    res.status(500).json({ error: 'AI service unavailable' })
  }
})

// ─── Start server ───────────────────────────────────────────────────

const PORT = process.env.PORT || 3001
app.listen(PORT, () => {
  console.log(`Backend running on http://localhost:${PORT}`)
})

Frontend code (in your Snake game's HTML/JS) calling the backend:

async function getAITip() {
  const res = await fetch('http://localhost:3001/api/ai-tip', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ prompt: 'one Snake-game design tip in 1 sentence' })
  })
  const data = await res.json()
  document.getElementById('ai-tip').textContent = data.tip
}

Notice the asymmetry: the frontend sends the prompt; the backend uses the API key the user never sees.

Why It Matters

The frontend-backend boundary is the most important architectural decision in any web project. Get it right and the system stays maintainable for years. Get it wrong — leak a key, do auth in JavaScript, recompute prices client-side — and you're either rewriting the whole stack or paying the security debt forever.

The skill that separates beginners from senior engineers in full-stack work is not "knowing which framework." It's the discipline of asking, for every line of code: can the user tamper with this? If yes, that line either does not matter, or it doesn't belong in the frontend. This question, asked thousands of times, builds the architectural intuition that takes years to develop and is what makes someone trustworthy with production systems.

Three patterns you'll meet next:

• API gateways and reverse proxies — Cloudflare, Nginx, AWS API Gateway. The single front door that routes requests to whichever backend service handles them.
• Microservices vs. monolith — split your backend into many small services or one big one? Both are valid; the answer depends on team size, complexity, and operational maturity.
• Serverless functions — AWS Lambda, Cloudflare Workers, Vercel Functions. The "backend" without managing a server. Same architectural role; different deployment shape.
• Auth and sessions — JWT tokens, session cookies, OAuth flows. The protocol that turns "I'm logged in" into a verifiable fact your backend can trust.

What this lesson glossed over but you'll meet in production:

• Environment configuration — .env for development, environment variables in production hosting. We touched it; production-grade config management gets richer (Vault, AWS Secrets Manager, etc.).
• Logging and observability — console.log is fine in development; production uses structured logs (JSON), centralized log aggregators, and tracing.
• Rate limiting — every public endpoint needs rate limits to prevent abuse. express-rate-limit is the simplest start.
• CORS in production — app.use(cors()) allows everything, which is dangerous in production. The right config is a specific allowlist of origins.

For the architectural model behind all of this, the What is an API and How Do APIs Actually Work blog post is the deeper read. Today's lesson made you the API provider for the first time; the article frames the contract from both sides.

Checklist

• I created a backend/ directory with npm init -y
• I installed express, cors, dotenv, and nodemon
• I wrote server.js with at least two GET routes
• My server starts with npm run dev and auto-reloads on file save
• My frontend (Snake game) successfully calls /api/health and shows the response
• I hit a CORS error and solved it with the cors middleware
• I moved the LLM API call from frontend (Lesson 11) to a backend route (POST /api/ai-tip)
• I can articulate why business logic belongs on the backend, not the browser

Quick Quiz

Q1: Where does frontend code run?

• A) On the server
• B) In the user's browser ✓
• C) In the database

Q2: Why must API keys live on the backend, not the frontend?

• A) Frontends are too slow to make API calls
• B) Anything in the frontend is visible to every user — they can read your code in DevTools and steal the key ✓
• C) Browsers don't support HTTPS

Q3: What is the role of CORS?

• A) A faster way to compress JSON
• B) A browser security mechanism that blocks cross-origin requests by default; you opt-in via the cors middleware on your server ✓
• C) A type of database query

Q4: What does app.use(express.json()) do?

• A) Sends a JSON response automatically
• B) Tells Express to parse incoming JSON request bodies into req.body ✓
• C) Validates that all responses are JSON

Q5: Why is nodemon useful in development?

• A) It speeds up your CPU
• B) It auto-restarts the server when you save a file, eliminating Ctrl+C and node server.js cycles ✓
• C) It encrypts your code

Bonus Challenge

Add a route GET /api/now that returns the current timestamp on the server:

app.get('/api/now', (req, res) => {
  res.json({ serverTime: new Date().toISOString() })
})

Then add a small clock to your Snake game's loading screen that fetches /api/now once and displays the server's time. Compare it to the time on your phone. Notice they're aligned (both NTP-synced) — but conceptually, this is the server's clock, not the user's. For things like "this offer expires at 8pm IST," the backend's clock is the authority.

Next Lesson

Lesson 13: Create Your Own API

You'll learn: Today you wrote one or two routes. Tomorrow we make your backend into a real REST API — with GET, POST, PUT, DELETE for a leaderboard, request validation, error handling, and the conventions that make APIs feel professional. You become the chef the world's clients order food from.

The boundary is drawn. Two halves, one product. 🏗️