What should readers expect from this article?

In this article, I want to explain the core story and philosophy of backend systems.

The article is language-agnostic, so the principles can be applied to any backend system, whether it is built using Node.js, Python, Java, Go, PHP, or any other technology.

By the end of this article, readers should be able to understand:

• Why do we need a backend?
• What is the role of a backend system?
• How does the frontend communicate with the backend?
• What happens behind the scenes when we visit a website?
• How does a request travel from the browser to the actual application server?

How are we able to surf the internet?

Let’s start with a simple example.

Suppose a user wants to visit:

www.sofascript.com

When the user enters this domain in the browser, the browser does not directly know where this website is hosted. It has to go through a series of steps to find the correct server and send the request there.

Step 1: DNS resolves the domain name

The first step is DNS resolution.

DNS stands for Domain Name System. It works like the phonebook of the internet.

Humans remember domain names like:

www.sofascript.com

But computers communicate using IP addresses like:

203.0.113.10

So, when the browser wants to open www.sofascript.com, it first asks a DNS server:

What is the IP address of www.sofascript.com?

The DNS server checks the DNS records configured for that domain and returns the corresponding IP address.

For example, if you bought your domain using GoDaddy or any other domain provider, you can configure DNS records there.

Some common DNS records are:

Record Type Purpose A record Points a domain or subdomain to an IP address CNAME record Points one domain or subdomain to another domain

Example:

A Record:
www.sofascript.com → 203.0.113.10

CNAME Record:
api.sofascript.com → services.sofascript.com

One important point: DNS usually does not store the port number.

DNS only helps the browser find the destination IP address or another domain. The port is decided later based on the protocol being used.

For example:

HTTP  → Port 80
HTTPS → Port 443

So the corrected mental model is:

Browser asks DNS: What is the IP of www.sofascript.com?
DNS replies: 203.0.113.10
Browser sends the actual request to 203.0.113.10 using HTTP or HTTPS.

Step 2: AWS Security Group filters the request

Now let’s assume that the application is hosted on an AWS EC2 instance.

After DNS resolves the domain to an IP address, the browser sends the request to that IP address. Since the IP belongs to an AWS EC2 instance, the request reaches AWS networking controls.

In AWS, one of the most important controls is the Security Group.

You can think of a Security Group as a firewall attached to the EC2 instance.

The Security Group decides which types of traffic are allowed to reach the instance.

For example, you may allow:

HTTP  traffic on port 80
HTTPS traffic on port 443
SSH   traffic on port 22 only from your own IP

If the request comes on an allowed port, it is passed to the EC2 instance.

If the request comes on a blocked port, it is rejected.

For example:

Allowed:
HTTPS request on port 443

Blocked:
Request on port 3306 if MySQL port is not publicly allowed

By convention:

HTTP  uses port 80
HTTPS uses port 443

However, applications can also run on custom ports like 3000, 3001, or 8080. These custom ports are usually not exposed directly to the internet in production. Instead, we expose standard ports like 80 or 443 and then route the request internally.

Step 3: The request reaches the EC2 instance and Nginx

If the request passes the AWS Security Group rules, it reaches the AWS EC2 instance.

Inside the EC2 instance, we usually do not expose the application server directly to the internet.

Instead, we place a reverse proxy in front of the application server.

A reverse proxy is a server that sits in front of one or more application servers. It receives incoming requests and forwards them to the correct internal service.

A commonly used reverse proxy is Nginx.

Nginx helps us manage routing from one centralized place.

It can handle things like:

• Routing requests to different backend services
• Serving static files
• SSL/TLS termination
• Load balancing
• Redirecting HTTP to HTTPS
• Forwarding requests to internal application ports

For example, the public request may come to:

www.sofascript.com

But internally, the actual Node.js application may be running on:

localhost:3001

So Nginx acts as the middle layer between the public internet and the internal application server.

Step 4: Nginx proxies the request to the Node.js server

Inside Nginx, we configure rules that tell it what to do with incoming requests.

For example, we can configure Nginx so that whenever a request comes for:

www.sofascript.com

Nginx should forward that request internally to:

localhost:3001

Here, localhost:3001 is the port where our Node.js server is running.

A simplified Nginx configuration may look like this:

server {
    listen 80;
    server_name www.sofascript.com sofascript.com; 
    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

This means:

If request comes for www.sofascript.com,
Nginx receives it,
matches the server_name,
and proxies the request to the Node.js server running on localhost:3001.

One important distinction:

Nginx is not necessarily redirecting the browser to localhost:3001.

Instead, it is usually proxying the request internally.

A redirect means the browser is told to go to another URL.

A proxy means Nginx receives the request and forwards it internally without exposing the internal server address to the browser.

Complete request flow

The complete flow looks like this:

User enters www.sofascript.com in the browser
        ↓
Browser asks DNS for the IP address
        ↓
DNS returns the IP address
        ↓
Browser sends HTTPS request to that IP on port 443
        ↓
AWS Security Group checks whether port 443 is allowed
        ↓
If allowed, the request reaches the EC2 instance
        ↓
Nginx receives the request
        ↓
Nginx matches the domain using server_name
        ↓
Nginx proxies the request to localhost:3001
        ↓
Node.js backend processes the request
        ↓
Response travels back to the browser

So far, we have seen how a browser request reaches the backend server.

Now let’s understand why we need a backend in the first place.

Why do we need a backend? Why not just use frontend?

Frontend code runs on the client side, usually inside the user’s browser.

Backend code runs on the server side, usually on a machine controlled by the company or developer.

The frontend is responsible for the user interface and user interactions.

The backend is responsible for things like:

• Business logic
• Database communication
• Authentication
• Authorization
• API integrations
• Secure processing
• Data validation
• File handling
• Logging
• Background jobs
• Server-side computation

In simple terms:

Frontend = what the user sees and interacts with
Backend  = where secure processing, data handling, and business logic happen

Why can’t we write all backend logic in the frontend?

Technically, frontend applications can do a lot of things. But they are not suitable for everything.

There are several important reasons why we need backend systems.

1. Security

Frontend code is visible to users.

Anyone can open the browser developer tools and inspect frontend JavaScript code.

So we should not keep sensitive information in frontend code, such as:

• Database passwords
• API keys
• Payment gateway secrets
• Private business logic
• Internal service credentials

If this logic is written in the frontend, it can be exposed and misused.

The backend keeps sensitive logic and credentials on the server side, where users cannot directly access them.

2. Database access

Browsers are not designed to directly connect to production databases.

For example, your frontend should not directly connect to:

PostgreSQL
MongoDB
MySQL
Redis

Instead, the frontend sends a request to the backend API.

The backend then talks to the database securely.

Example:

Frontend asks:
Give me the user profile.

Backend does:
1. Check if the user is logged in.
2. Check if the user has permission.
3. Query the database.
4. Return only the required data.

This keeps the database protected.

3. Business logic

Most real applications have business rules.

For example:

Can this user place an order?
Is this coupon valid?
What is the final price after discount?
Is this user eligible for this feature?
Should this payment be approved?

These rules should usually be handled on the backend.

If business logic is written only on the frontend, a malicious user can bypass it by modifying the frontend code or sending direct API requests.

The backend acts as the final source of truth.

4. Authentication and authorization

Authentication answers:

Who is this user?

Authorization answers:

What is this user allowed to do?

For example:

A normal user can view their own orders.
An admin can view all orders.

The frontend can hide or show buttons based on the user role, but the backend must enforce the actual permission checks.

Never rely only on frontend checks for security.

5. Calling third-party APIs securely

Frontend code can call external APIs, but there are limitations.

First, many third-party APIs require secret keys.

These keys should not be exposed in the browser.

Second, browsers enforce security policies such as Same-Origin Policy and CORS.

This means frontend JavaScript cannot freely read responses from another domain unless that domain allows it.

So, in many cases, the backend acts as a secure middle layer.

Example:

Frontend → Backend → Third-party API

Instead of:

Frontend → Third-party API directly with secret key

What is CORS?

CORS stands for:

Cross-Origin Resource Sharing

It is a browser security mechanism.

Browsers follow the Same-Origin Policy, which means frontend JavaScript from one origin cannot freely read responses from another origin.

An origin is made of:

Protocol + Domain + Port

For example:

https://www.sofascript.com

and

https://api.sofascript.com

are different origins because the domain is different.

Similarly:

http://localhost:3000

and

http://localhost:3001

are different origins because the port is different.

CORS allows a server to explicitly say:

This frontend origin is allowed to read my response.

For example, the backend may send a response header like:

Access-Control-Allow-Origin: https://www.sofascript.com

This tells the browser that frontend code from https://www.sofascript.com is allowed to access the backend response.

Important point:

CORS does not stop the backend from receiving requests.

CORS mainly controls whether the browser allows frontend JavaScript to read the response.

Final mental model

A backend is needed because the browser is not the right place for secure and trusted processing.

The frontend should focus on user experience.

The backend should handle:

Security
Business logic
Database access
Authentication
Authorization
Third-party integrations
Server-side computation

When a user visits a website, the request flow usually looks like this:

Browser
  → DNS
  → Server IP
  → AWS Security Group
  → EC2 Instance
  → Nginx Reverse Proxy
  → Backend Application
  → Database / External Services
  → Response back to Browser

That is the core story of backend systems.

The backend is not just a place where APIs are written.

It is the trusted layer that connects the user interface with data, logic, security, and external systems.

What Really Happens When You Visit a Website? was originally published in 2469 Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

As an interior designer, my passion lies in creating spaces that speak to people. Yet, behind every beautifully realized room, there’s a process one that used to be filled with manual iterations, hours of back-and-forth, and software that felt more like a hurdle than a help. Over time, though, I found a set of tools that transformed that process and none has reshaped my work quite like SofaScript.

I remember the early days sifting through design magazines, cutting out color swatches, and trying to convey a vision with just a few pencil lines. Now, every morning, I open SofaScript (www.sofascript.com), and my day is different. It’s not just a tool; it’s a creative partner. Whether I’m uploading a quick sketch of a living room or a mood board from a cafe inspiration, SofaScript turns those raw ideas into polished, client-ready concepts within minutes.

But it’s not just SofaScript. I’ve curated a set of five indispensable tools that each play a crucial role in my daily work:

1. SofaScript: As I mentioned, it’s like a lightning bolt of creativity. It takes a simple sketch or image and helps me explore endless design possibilities, faster than I ever could before.
2. Notion: For project management and note-taking, Notion is my command center. I organize client briefings, timelines, and even mood boards so everything stays in one place.
3. Canva: Not just for social media Canva is a lifesaver for quick design presentations, client pitch decks, and even personalized design proposals.
4. Miro: For brainstorming sessions and collaborative mood board creation, Miro lets me map out spaces and ideas with my team in real time.
5. Loom: Not all feedback needs to be a meeting. Loom lets me record walkthroughs of designs, so clients can absorb details at their own pace.

These tools, combined, give me a rhythm I couldn’t have dreamed of years ago. But the magic is in how they interact SofaScript unlocks creative potential, while Notion, Canva, and Miro help me organize, communicate, and iterate like never before.

If you’ve ever struggled to bring a design vision to life especially in a fast-paced world, I encourage you to experiment. These tools won’t do the creativity for you, but they will give you the freedom to dream bigger, faster, and with more confidence.