Frontend vs. Backend: The Practical Difference

Welcome back! In the last module, we successfully took a project from your local computer and published it to the world, even giving it a custom, professional domain name. You now have a static "storefront" on the internet. But what happens when you want that storefront to actually do something, like manage a budget, save user preferences, or show real-time data?

This lesson marks a shift from getting your app online to making it functional. We'll start by exploring one of the most fundamental concepts in all of app development: the separation between the frontend and the backend. As a designer, you are already an expert in one of these domains. This lesson will demystify the other half, explaining in practical terms what's happening "behind the curtain" when your LLM assistant starts generating code for databases or server logic.

The Restaurant Analogy: Dining Room vs. Kitchen

Imagine you're at a restaurant. You are seated in a beautifully designed dining area (the ambiance, the decor), you're handed a well-organized menu, and a waiter comes to take your order. A little while later, your food arrives, perfectly cooked.

In this scenario, everything you see and interact with—the dining room, the menu, the waiter—is the frontend. It’s the user experience.

The kitchen, hidden from view, is the backend. It's where the chefs take your order (the request), use various ingredients (the data), follow recipes (the logic), and prepare your meal. The kitchen is what makes the whole operation work, but you never see it.

Web applications work in precisely the same way. The following video offers a fantastic overview of this concept.

Defining the Roles

Now that you have the core analogy in mind, let's formalize the definitions. The article below provides a clear, written breakdown.

To summarize and build on what you just read:

The Frontend (The "What You See")

• What it is: The user interface (UI) and user experience (UX). It's everything that runs in the user's browser or on their device. As a designer, this is your primary domain: the layouts, colors, typography, buttons, and interactions.
• Its Job: To present data and user options in a clear, interactive way and to capture user input (clicks, form submissions, etc.).
• Technologies: HTML (structure), CSS (style), and JavaScript (interactivity). You'll often see this bundled into frameworks like React or Next.js, which Claude likely uses when building your web apps.

The Backend (The "How It Works")

• What it is: The server, application logic, and database. This part lives on a computer on the internet (like the ones Vercel uses) and is never directly seen by the user.
• Its Job: To receive requests from the frontend, execute "business logic" (e.g., check if a user is logged in, calculate a total price, save a new budget entry), manage data in a database, and send the results back to the frontend.
• Technologies: Server-side languages like Node.js or Python, and databases like Firebase or Supabase (which we'll cover soon).

Why This Matters for "Vibe Coding"

In the traditional coding workflow, a developer might spend significant time building both the frontend and backend. In your "vibe coding" workflow, this separation becomes even more pronounced and strategic.

When you prompt an LLM like Claude with "Describe Your Vision," it often excels at rapidly generating a visually appealing frontend. This part is becoming increasingly easy to create and modify. However, the core, durable value of your application often lies in its backend.

As the article notes, the modern approach is a decoupled architecture. Your backend exists independently and communicates with any frontend through a universal "waiter" system called an API (Application Programming Interface). This is incredibly powerful. It means the same backend logic and data can power:

• A web app built with React (which you might generate with Claude).
• An iOS app built with Swift.
• An Android app built with Kotlin.
• Even an integration with a completely different service.

By building a solid backend, you are creating a stable foundation that can support many different user experiences, which you can rapidly prototype and change on the frontend.

A Practical Example: Booking on Airbnb

Let's see this entire flow in action. The following video walks through what happens when a user performs a simple search on a site like Airbnb.

This request-response cycle is the heartbeat of nearly every modern application. Every time you see a feed update, submit a form, or "like" a post, you are initiating this conversation between the frontend and the backend.

Conclusion

Understanding the distinction between the frontend and backend is crucial for demystifying what your AI coding assistant is doing. You're no longer just watching it generate code; you're seeing it build the two fundamental halves of an application.

Key Takeaways:

• Frontend is the presentation layer—the part the user sees and interacts with. Think of it as the restaurant's dining room and menu.
• Backend is the logic and data layer—the hidden engine that processes requests and manages information. This is the restaurant's kitchen.
• In "vibe coding," frontends can be generated and changed rapidly. The backend often represents the more stable, long-term core of your application's functionality.
• A decoupled architecture allows a single backend to power multiple frontends (web, mobile, etc.), making it a highly efficient model.

Now that we've established these two separate worlds, our next lesson will focus on the bridge that connects them. We'll explore what an API is and how it acts as the universal messenger, allowing the frontend and backend to communicate effectively.