# What is a Backend?

Do you folks really know what a Backend is?  
Why do we need a separate backend server?  
Why don't we put everything on the frontend side- all DB-related logic, validation, and so on?

And yeah, many folks can think these are childish questions   
If you are thinking the same, then you can skip this post and feel free to go.

So let's start with a simple question: what is a backend?

Let's understand with an analogy:  
Suppose you are using Instagram and you see your friend's post. You hit the like button, and then, on the other side, your friend receives a notification mentioning, "X liked your post." The same goes for your friend as well: when he likes your post, you will get a notification as well.

You can clearly see that between you and your friend, there is something that is managing these things, like sending notifications, updating data, etc.

That something is what we call a backend. (Of course, there are more components involved, but let that go and try to understand it from the top view.)

OK, we understood at this point what a backend is  
"But wait — why do I even need a separate backend? My frontend is also being served from a server, right? In my case, my frontend files are hosted on an EC2 instance. So why can't I simply put my database logic, validation, authentication, etc. there as well?

Before answering these question lets see how the frontend works behind the scenes  
. When you open something in a browser, for example, I am taking the example of my custom-made frontend website -> [https://frontend.amitx.tech](https://frontend.amitx.tech)

then the browser first sends a request to the DNS server to get the corresponding IP because on the internet we can identify by IP, not domain; it's just an easy way to remember that applications

![](https://cdn.hashnode.com/uploads/covers/671789bcaad19ef4cc0fd18a/02776de4-a100-4c9d-a50c-9d690dafb4a7.png align="center")

  
Ok, now the browser has the IP; now it send req to that IP  
Here, my frontend server is hosted on AWS; I will talk in that context; no need to know about AWS. For now, listen and understand what I am saying

So when my request lands on my EC2 instance, there is a concept of security groups in AWS. If I allow those ports, then it hits my EC2 machine

![](https://cdn.hashnode.com/uploads/covers/671789bcaad19ef4cc0fd18a/39128069-4a95-48f3-b89c-bf79074137db.png align="center")

you can see i have opened port 443 which is for https that why when i send req from browser it goes on my ec2 machine ok now i am on ec2 machine then i am using a reverse proxy which is nginx in this case whose configuration is looked like this ( forgot about what is reverse proxy for now).

![](https://cdn.hashnode.com/uploads/covers/671789bcaad19ef4cc0fd18a/69f5c316-5f1e-4aaf-ae01-c9d328ccb26e.png align="center")

You can see that I am routing my request, which is coming on the domain - `frontend.amitx.tech` to `http://127.0.0.1:3000`.

Which is running on my EC2 localhost, and when the request goes there, then in the response my frontend server returns all the HTML, CSS, and JS to the browser

This is a high-level and short overview of how the frontend loads on your browser. I am telling you this is only one way; it is one of the ways you can understand

Here one thing you should notice when the browser receicved those code ( html , css, js ), its just simply render on my screeen technically paint my screen and so on

so you can clearly see those code are executed by my browser so in case of frontend the runtime is browser

So, coming back to the original question: why don't we put backend code on the frontend? As you know, my frontend code is executed by the browser, and for your info, the browser works in a closed/isolated environment; it has no access to your system, file system, etc.

But on the backend, sometimes we need to create log files- save them on the server. There we can do this because we can access the file system. But on the other side, if we put backend logic on the frontend, this code never works because it does not have access to fs

![](https://cdn.hashnode.com/uploads/covers/671789bcaad19ef4cc0fd18a/15903f8e-ae19-46f9-8cf3-b154df3c9ce5.png align="center")

This is one reason why we need a separate backend process in our application.

### CORS :

For your info, **CORS (Cross-Origin Resource Sharing) is a browser security mechanism**. When our frontend JavaScript tries to communicate with an API running on a different origin (different origin means the frontend and API are being accessed from different scheme/host/port combinations. We'll cover this properly in another blog. ), the browser applies CORS rules to determine whether our frontend is allowed to access the response.

```plaintext
https://frontend.example.com
https://api.example.com
```

These are different origins because the host differs.

If that API does not allow our origin, the browser will prevent our frontend JavaScript from accessing the response.

If you are hearing about this for the first time, then it might be difficult to understand, but don't go deep into it right now ( we will see CORS in some other blog ).

On the backend, this particular browser CORS restriction doesn't apply because the request is being made server-to-server. We get two benefits when we move to a separate backend

1.  CORS is no longer an issue
    
2.  Secrets/API credentials can stay on the backend (because for accessing some APIs we need some kind of authorization, so we as an engg ofc don't want to expose that secret or key on the frontend by putting backend-related work on the frontend ).
    

### Computation:

Another reason is **computing power**.  
If I put backend logic on the frontend and suppose my application has some feature that takes a lot of processing, for example, image processing

If we put that processing entirely in the frontend, the computation will happen inside the user's browser, which means it will use the user's own CPU and RAM.

User 1 → Browser → CPU/RAM of User 1

User 2 → Browser → CPU/RAM of User 2

User 3 → Browser → CPU/RAM of User 3

This means our application performance can depend on the user's device. One user might have a monster PC with 64 GB RAM, a 1 TB SSD, and an Intel 9th-gen processor, etc on the other hand, another might be using a low-spec device. So the difference is clear: our app will perform great on that monster PC compared to a low-spec pc

In this approach, the backend isn't doing the computation — the user's device is.

On the other hand, if I move that heavy processing to our backend:

Then I can simply control the whole computation infra,

If our application grows and one server is no longer enough, we can add more servers and divide or technically distribute the workload.

I am not gonna here to explain the horizontal / veritcal scaling i know some of you are expecting that thing at this point, but in this blog I want to keep things simple.

### Trust:

And this is a more important thing because here we are talking about keeping our backend on the frontend side.

There is one thing you should know

> The frontend is controlled by the user

```javascript
if (user.isAdmin) {
   showDeleteButton();
}
```

We cannot rely on this. The user owns the browser; they can :

*   modify JavaScript
    
*   modify requests
    
*   call your API directly
    
*   use Postman/curl
    
*   manipulate frontend state
    

### Database Connectivity:

We all know we use one database on the backend to store all data, and to connect with that database, we need some drivers.

Suppose I am using PostgreSQL; for that, I need a PostgreSQL driver to communicate with the Postgres DB.

"In Node.js, you can use a PostgreSQL driver such as`pg`, or higher-level tools such as Prisma and Drizzle that provide abstractions for working with databases."

These libraries communicate with PostgreSQL using the database's network protocol.

But browsers don't normally have access to arbitrary TCP/network protocols needed by database drivers.

Your browser mainly gives JavaScript APIs such as:

```plaintext
fetch()
WebSocket
WebRTC
```

It doesn't say:

```plaintext
connectTCP("postgres.example.com", 5432);
```

for arbitrary database communication.

So this:

```plaintext
React
  ↓
Prisma
  ↓
PostgreSQL
```

is generally **not how browser applications work**.

SOME EXTRA KNOWLEDGE :

But there is a way we can communicate with a DB using HTTP APIs because browser JavaScript doesn't provide arbitrary raw TCP socket access that typical PostgreSQL drivers expect, but we can make HTTP requests

You **can** communicate with some databases/services through HTTP.

For example:

```plaintext
Browser
   ↓ HTTPS
Supabase API
   ↓
PostgreSQL
```

That's possible because you're not directly talking to PostgreSQL's database protocol.

You're talking to an **HTTP API**.

That's why services such as:

*   Supabase
    
*   Firebase
    
*   some hosted database APIs
    

can be used directly from frontend applications.

But there's still an important question:

Those services need their own browser-safe authentication and authorization mechanisms, such as:

*   public/anonymous keys
    
*   user authentication
    
*   row-level security
    
*   scoped permissions
    

So it's not that "frontend can never access a database."

It's:

> The frontend should not have unrestricted direct access to your database.

So I hope you guys understand the importance of the backend in an application.

### Summary:

We need a trusted server-side environment for responsibilities that shouldn't or can't be handled by the browser. We commonly call the application running in that environment the backend. And it should be responsible for validating the user, controlling which user can do what, and communicating with the DB and saving data into the DB.

Perform heavy processing by itself rather than offloading to the client, that help mt application work on low-spec machines as well

Yeah, I think it is quite a good overview of what the backend is and why we need it.

See you guys next time with some new interesting topic

~ Amit