Understanding Backend Architecture: How Requests Travel and Why Backends Matter

let's picture it back end in its traditional definition is a computer which is listening for HTTP or websocket

or grpc or any other kind of request through an open port whether it is 0 or 443 which is accessible over the

Internet so that clients or other front ends can connect to it send data to it or receive data depending on the kind of

request and we call it server because it provides or it serves some kind of content whether it is static files like

images or JavaScript files or HTML files or it could be Json and it also accepts data if this

client sends something now that is a fair definition of what a back end is and how it works but I want you to get a

holistic view to actually see the components physically how they work behind the scenes so let's go through

this whole flow now I have a backend server which is deployed in AWS so let's take that as an

example demo users and this is some sample data the

back end is serving so let's do it one more time and this time open the network toolbar and if we refresh one more time

let's disable cache so that we get the appropriate status code all right so this is the request which starts from a

browser and reaches our server and we receive this response now we will cover request and response in a later video

for now let's look at how the whole flow looks like so let's trace it out let's Trace how our request starts from our

browser and reaches our server so the first thing that you can see is the domain name so if you can see it this is

the domain name Senus doxyz and this is a subdomain so the first thing that comes to mind is we should take look at

our DNS server now this is my DNS server and this part is the important part where we have defined different types of

Records now DNS itself is a huge topic so instead of going too deep into that I'll just give the basics here now to

oversimplify it DNS has different types of Records you can use a records to point to a particular IP and you can use

C Name Records to point to a particular domain name or subdomain right so along with my other existing domains and

subdomains the thing to focus here is this part now if you see here we have two a records and one of them is backend

demo and it is pointing to a particular IP address and where is this IP address coming from so this IP address is of an

E2 instance which is in a s now this is my AWS console let's go to ec2 and then let's go to

instances and this is the deployed instance now if you see here this is the public IP address that that we just saw

in our DNS config so that particular subdomain which is backend demo points to this IP address and our request

reaches here to our ec2 instance through this IP and before it reaches our server or the particular computer it goes

through a firewall which is the AWS native firewall the firewall has to allow some kind of request to go through

now if you look here this is the security group that is assigned to our AWS instance uh which basically means

that using this we can specify what are the ports we want to allow uh what are the ports that we want to be accessible

over the internet right so you can see we have allowed three different kinds of ports and we use this port to log into

our AWS instance to terminals or command front so that we can do different kinds of operations and the https and HTTP

ports now this is the important part our request goes to the domain server which points to our AWS instance IP and

through the IP it reaches the instance and before going into the computer it passes through these firewalls so if we

don't allow these two ports like 443 for allowing https traffic or 802 allow HTTP traffic if you don't allow it the AWS

will block it right here and our request won't be able to reach our server so this is an important part and finally

after this our request reaches to our computer now after our request reaches here into our a instance we are using

something called a reverse proxy which basically means it is a server which sits in front of other servers so that

we can manage different types of redirects or configs from a centralized space instead of changing the configs in

every single server so for that we are using enginex and this is how our config looks like there are a lot of stuff here

but the parts to focus here is we're using something called sbot to assign SSL certificates automatically but not

something to worry about in this demo the parts to focus here is it is listening for Port 80 in our AWS

instance and it is redirecting that request to Port 443 so which is an https request so that part

is managed by sbot and the part that we have configured is this so what we're saying is this is my domain name so we

can Define it using the field server name this is our subdomain back in demo and whatever request that comes to this

domain so which is already routed by DNS server so it will reach this instance so that is not something you have to worry

about and what we are saying is whatever request that comes to this domain our engx config will redirect those requests

to our Local Host 3001 which is the port our server is running on our node server is running on and this is the final

redirection so if we take a look at our processes Let's Do pn2 List we are using pn2 to manage our

processes so we can see here that we have two processor running one for front end and

another for back end and this is a node server so this is the final hop and if you want we can also check this if you

just do call Local Host 2001 SL users and we will get the same response

so from the point of view of this instance our server our node server is running in Local Host and we using

engine and domain names to Route requests to our local server over the Internet so if we were to summarize our

request starts here in the browser it goes to our DNS server then that goes to our AWS servers and it goes through a

firewall and that reaches our AWS instance right and that request is then reaches

ngx and that finally forwards that request to our Local Host 3001 our final server so it

goes through all these hops until it finally reaches our server so when we're developing in our Local Host you can

just open your browser and go to Local Host 3000 / users and you'll see the same response and we saw that in our AWS

instance also if you call to our server we get the same response now you should have a fair idea of how a request looks

like and how a request travels over the internet and reaches server but why exactly do we need these backends I'll

give an example imagine you're scrolling through your Instagram feed and you come across your friends posts as usually you

like them you click on the like button and on the other side your friend gets a notification that you like their post so

between you clicking on the like button and your friend getting the notification what exactly happened now that is where

the concept of backend comes into play you click on the like button the app send a request to the server the server

passes that request and sees who is the user and it finds your name or your ID or whatever and then it persists and

save that the data the action of you liking it it has the server has to save it in some kind of way usually in a

database it saves that information and then it checks who is the user the user who's post you like and it finds that

user's ID and it sends a notification it triggers some kind of action that sends a notification to that user and the user

gets a notification in their phone so all these interaction that happened between you clicking on the like button

and your friend receiving the notification there has to be some kind of server a centralized computer that

has to have all kinds of information about all the users because if you look at your app it is designed it is

customized according to your needs and your profile and all the people you follow right and all the actions that

you can perform on your account similarly that is the case for your friend they only receive the

notification that is intended for them but a server has to have all kinds of information right all kinds of

information of all kinds of state so it has to be centralized and from whatever we have seen till now if you try to

condense down and if you try to strip it down the responsibility and the use of backend to a single word it will be this

data right the need to fetch data the need to receive data and the need to persist data somewhere and any kind of

actions and every kind of action that deals with data and if you ask me why not just do everything on the front end

right since that is also some kind of device or some kind of computer depending on what you are using so why

not do it here why not connect to the database here and why not do every kind of actions that servers do and since

everything is distributed everywhere we'll have better performance right technically and that is an excellent

question so in order to understand that why can't we use all those functionalities in front end we have to

see how front ends actually work behind the scenes now like our earlier backend demo let's do a demo for how front end

works from end to end this is a nextjs application that I have deployed in the same aws2 instance open the network

toolbar again and let's hit the refresh and what we see here is the first document that the browser fetches we

look at this it calls this domain name and if you look at the response it is an HTML file the browser fetches the HTML

file and all the resources for example all these JavaScript and all the images the fonts and the CSS files all of those

different things are fetched in different different requests after we have our primary HTML file and in our

record we see that we have an entry for this subdomain which is front end demo and it points to this particular IP

address and if you trace that we land here which is the a E2 instance and we can see that this is the same public IP

address next as usual the port 443 and the port 80 has to be allowed for https and HTTP traffic to get through to our

server and finally the request land here our ec2 instance and if you look at the engine config this is what it looks like

again most of the things are the same same as it was in our backend server we have the same Serb configs but the thing

that is different is here we are listening for this domain which is the front end demo and whatever traffic that

comes to here we are redirected to the Local Host 3000 instead of redirecting to 3001 we are redirecting to Port 3000

and finally the request reaches our frontend nextjs server which serves the files which is the JS file the CSS file

and the HTML file which are sent over the network to our browser and after going through all of that after we

receive our main HTML file what the browser does is it goes through all these resources the JavaScript files the

CSS files and the fonts and it fetches them one by one once it fetches all the CSS which you can see here it paints our

window that's how we get all these Styles the background black and these fonts and these button Styles and once

the browser fetches all the JavaScript files that's when it hydrates all the event listeners for buttons and all any

kind of interactions that we have in this page for example if you click on this button this is what it happens it

redirects to another page that happened because the browser fetched all the JavaScript added all the event listeners

and that's how the button started working so what do we notice here whatever front end logic that you have

written whatever the JavaScript that you have written is all fetched by the browser from our server and it is

executed by the browser in our machine in client's machines right so the browser is our runtime compared to our

traditional backends which we saw earlier the one in AWS ec2 instance where we sent a request the server

processed the request and sent us the result so the actual processing happened on the server right and it is exactly

the opposite for front end where it sends us the code but the browser runs the code whatever logic that is run it

is run by the browser so that is a key difference to notice here now there are a couple of issues that we find here

right because browser run times are often sandbox environments which means they are isolated from our operating

systems the processes and the file system everything is an isolated environment which means the code can

only access limited amount of resources for example the Dom which is the document object and browser apis for

example local storage or cookies and external apis but only if the external API has the all the required amount of

headers we have not covered course yet which we will in a future video in much more depth but you can imagine course as

a policy a security policy of browsers which restricts JavaScript code to call external apis which is not the same as

the current domain for example we have this frontend app in this domain which is frontend demo

doxyz so we can only call resources or can only fetch resources and call external apis which are in the same

domain if we try to call a different domain then the browser will block the request because of course policy and

there are ways to get around that which are through HTTP headers which we will explore later and if you think about it

all these sandboxing and security restrictions make sense because essentially what a browser is doing is

it is fetching code from a remote server and executing it in the the users browser and if it's not careful enough

or isolated enough the remote code can easily access data or files from users's computer which is not a good thing for

example imagine you go to a website and you have no idea what is the prent code of that website and if browsers did not

isolate environments that code can easily get access to your file system copy all your files your sensitive

details and send it to their servers right so that is a very scary idea that's why browsers have all these

security policies now coming back to our original question why can't we write backend logic in front end so the first

thing obviously is security reasons security reasons because the security policies of

browsers are so restrictive and often times a back needs to access underlying file system whether it's to write to a

log file or access environment variables and browsers won't allow that that is a huge restrict

for a backend server the second thing is you cannot call external apis whenever you want unless that API has all the

appropriate cor headers and since we don't have control over all the external apis this is also a big deal breaker

because backend servers often need to connect to other servers and fetch data from multiple places so we cannot have

this restriction now the third thing is databases now the server runtime has access to all

Native database drivers for example PG for postgis and mongodb and that allows it to communicate efficiently with

databases these drivers are written to work in environments that can handle socket connections handle binary data

and maintain persistent connections things that browsers cannot do and we will explore later how backend servers

communicated with databases but to simplify it backend servers maintain a list of connection

uh which is often called a connection pool to our database server so that it does not have to create and Destroy

connections again and again because backend servers receive thousands and thousands of requests in seconds and if

they do the connecting and destroying logic with each request the data server is going to get overwhelmed and it

cannot handle that load so drivers are written in a way that can maintain a list of connections and browsers are not

designed to maintain persistent connections to databases and even if they were each user would need to open

their own delete connection to the database overwhelming the database server with too many connections there

is also no easy way to manage connection pooling or efficient query execution from the browser environments now the

last thing is computing power front end

applications as we use them are everywhere it could be a smartphone it could be be a desktop it could be a

laptop and any kind of environments that we can imagine even a computer which has a 256 mbf RAM and with a single core

processor and the user might not have enough computing power to perform some heavy business logic and things will

start to lag and sometimes break because of the load so for that reason if it's a centralized backend server which serves

and CS to a large number of clients we can easily increase its memory and and CPU whenever we want and we can easily

deal with the load we can continue this list as long as we want but this should give you a fair idea that keeping

backend logic in front end is not a good idea uh that is assuming if we can do it in the first place great now we have

seen what a backend is why do we need it and how does it work on a very high level now this is a very good place to

be in before we start our journey of learning backend engineering now let's explore what are these principles and

why we should learn in this particular way