YT YouTube2Text

YouTube2Text → Transcripts → 3. What is a Backend, how do they work and why do we need them?

3. What is a Backend, how do they work and why do we need them? — Transcript

by Sriniously · 3,276 words · 464 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00let's picture it back end in its
0:01traditional definition is a computer
0:03which is listening for HTTP or websocket
0:06or grpc or any other kind of request
0:09through an open port whether it is 0 or
0:12443 which is accessible over the
0:16Internet so that clients or other front
0:19ends can connect to it send data to it
0:22or receive data depending on the kind of
0:24request and we call it server because it
0:27provides or it serves some kind of
0:30content whether it is static files like
0:32images or JavaScript files or HTML files
0:35or it could be
0:38Json and it also accepts data if this
0:41client sends something now that is a
0:43fair definition of what a back end is
0:46and how it works but I want you to get a
0:49holistic view to actually see the
0:51components physically how they work
0:53behind the scenes so let's go through
0:55this whole flow now I have a backend
0:57server which is deployed in AWS so let's
1:00take that as an
1:02example
1:08demo
1:13users and this is some sample data the
1:16back end is serving so let's do it one
1:18more time and this time open the network
1:21toolbar and if we refresh one more time
1:24let's disable cache so that we get the
1:26appropriate status code all right so
1:28this is the request which starts from a
1:31browser and reaches our server and we
1:34receive this response now we will cover
1:36request and response in a later video
1:38for now let's look at how the whole flow
1:40looks like so let's trace it out let's
1:43Trace how our request starts from our
1:45browser and reaches our server so the
1:47first thing that you can see is the
1:49domain name so if you can see it this is
1:52the domain name Senus doxyz and this is
1:56a subdomain so the first thing that
1:58comes to mind is we should take look at
2:00our DNS server now this is my DNS server
2:03and this part is the important part
2:06where we have defined different types of
2:07Records now DNS itself is a huge topic
2:10so instead of going too deep into that
2:13I'll just give the basics here now to
2:15oversimplify it DNS has different types
2:17of Records you can use a records to
2:19point to a particular IP and you can use
2:22C Name Records to point to a particular
2:24domain name or subdomain right so along
2:27with my other existing domains and
2:30subdomains the thing to focus here is
2:32this part now if you see here we have
2:34two a records and one of them is backend
2:36demo and it is pointing to a particular
2:39IP address and where is this IP address
2:41coming from so this IP address is of an
2:43E2 instance which is in a s now this is
2:46my AWS console let's go to
2:51ec2 and then let's go to
2:54instances and this is the deployed
2:56instance now if you see here this is the
2:58public IP address that that we just saw
3:00in our DNS config so that particular
3:03subdomain which is backend demo points
3:05to this IP address and our request
3:07reaches here to our ec2 instance through
3:09this IP and before it reaches our server
3:14or the particular computer it goes
3:16through a firewall which is the AWS
3:18native firewall the firewall has to
3:20allow some kind of request to go through
3:22now if you look here this is the
3:25security group that is assigned to our
3:27AWS instance uh which basically means
3:29that using this we can specify what are
3:32the ports we want to allow uh what are
3:35the ports that we want to be accessible
3:38over the internet right so you can see
3:40we have allowed three different kinds of
3:42ports and we use this port to log into
3:44our AWS instance to terminals or command
3:47front so that we can do different kinds
3:49of operations and the https and HTTP
3:52ports now this is the important part our
3:54request goes to the domain server which
3:56points to our AWS instance IP and
3:58through the IP it reaches the instance
4:00and before going into the computer it
4:02passes through these firewalls so if we
4:04don't allow these two ports like 443 for
4:08allowing https traffic or 802 allow HTTP
4:11traffic if you don't allow it the AWS
4:13will block it right here and our request
4:15won't be able to reach our server so
4:17this is an important part and finally
4:19after this our request reaches to our
4:21computer now after our request reaches
4:23here into our a instance we are using
4:27something called a reverse proxy which
4:30basically means it is a server which
4:33sits in front of other servers so that
4:36we can manage different types of
4:38redirects or configs from a centralized
4:40space instead of changing the configs in
4:42every single server so for that we are
4:44using enginex and this is how our config
4:46looks like there are a lot of stuff here
4:49but the parts to focus here is we're
4:51using something called sbot to assign
4:53SSL certificates automatically but not
4:55something to worry about in this demo
4:57the parts to focus here is it is
4:59listening for Port 80 in our AWS
5:02instance and it is
5:05redirecting that request to Port 443 so
5:08which is an https request so that part
5:11is managed by sbot and the part that we
5:13have configured is this so what we're
5:16saying is this is my domain name so we
5:19can Define it using the field server
5:21name this is our subdomain back in demo
5:24and whatever request that comes to this
5:27domain so which is already routed by DNS
5:30server so it will reach this instance so
5:32that is not something you have to worry
5:34about and what we are saying is whatever
5:37request that comes to this domain our
5:39engx config will redirect those requests
5:41to our Local Host 3001 which is the port
5:44our server is running on our node server
5:46is running on and this is the final
5:48redirection so if we take a look at our
5:51processes Let's Do
5:55pn2 List we are using pn2 to manage our
5:58processes
6:00so we can see here that we have two
6:02processor running one for front end and
6:05another for back end and this is a node
6:08server so this is the final hop and if
6:11you want we can also check this if you
6:13just do call Local
6:16Host 2001 SL
6:19users and we will get the same response
6:22so from the point of view of this
6:24instance our server our node server is
6:27running in Local Host and we using
6:29engine and domain names to Route
6:31requests to our local server over the
6:33Internet so if we were to summarize our
6:36request starts here in the browser it
6:38goes to our DNS server then that goes to
6:42our AWS servers and it goes through a
6:46firewall and that reaches our AWS
6:50instance right and that request is then
6:54reaches
6:55ngx and that finally forwards that
6:58request to our
7:00Local Host 3001 our final server so it
7:04goes through all these hops until it
7:06finally reaches our server so when we're
7:09developing in our Local Host you can
7:11just open your browser and go to Local
7:13Host 3000 / users and you'll see the
7:15same response and we saw that in our AWS
7:18instance also if you call to our server
7:21we get the same response now you should
7:23have a fair idea of how a request looks
7:26like and how a request travels over the
7:28internet and reaches server but why
7:31exactly do we need these backends I'll
7:34give an example imagine you're scrolling
7:37through your Instagram feed and you come
7:40across your friends posts as usually you
7:43like them you click on the like button
7:45and on the other side your friend gets a
7:47notification that you like their post so
7:49between you clicking on the like button
7:51and your friend getting the notification
7:53what exactly happened now that is where
7:55the concept of backend comes into play
7:57you click on the like button the app
7:59send a request to the server the server
8:01passes that request and sees who is the
8:03user and it finds your name or your ID
8:06or whatever and then it persists and
8:10save that the data the action of you
8:13liking it it has the server has to save
8:15it in some kind of way usually in a
8:17database it saves that information and
8:21then it checks who is the user the user
8:23who's post you like and it finds that
8:25user's ID and it sends a notification it
8:28triggers some kind of action that sends
8:30a notification to that user and the user
8:33gets a notification in their phone so
8:35all these interaction that happened
8:37between you clicking on the like button
8:38and your friend receiving the
8:39notification there has to be some kind
8:42of server a centralized computer that
8:45has to have all kinds of information
8:47about all the users because if you look
8:49at your app it is designed it is
8:51customized according to your needs and
8:54your profile and all the people you
8:56follow right and all the actions that
8:59you can perform on your account
9:01similarly that is the case for your
9:03friend they only receive the
9:04notification that is intended for them
9:07but a server has to have all kinds of
9:10information right all kinds of
9:12information of all kinds of state so it
9:15has to be centralized and from whatever
9:17we have seen till now if you try to
9:21condense down and if you try to strip it
9:23down the responsibility and the use of
9:25backend to a single word it will be this
9:30data right the need to fetch data the
9:33need to receive data and the need to
9:34persist data somewhere and any kind of
9:37actions and every kind of action that
9:39deals with data and if you ask me why
9:42not just do everything on the front end
9:45right since that is also some kind of
9:48device or some kind of computer
9:49depending on what you are using so why
9:52not do it here why not connect to the
9:54database here and why not do every kind
9:56of actions that servers do and since
9:58everything is distributed everywhere
10:00we'll have better performance right
10:02technically and that is an excellent
10:05question so in order to understand that
10:07why can't we use all those
10:09functionalities in front end we have to
10:11see how front ends actually work behind
10:13the scenes now like our earlier backend
10:15demo let's do a demo for how front end
10:18works from end to end this is a nextjs
10:20application that I have deployed in the
10:22same aws2 instance open the network
10:24toolbar again and let's hit the refresh
10:32and what we see here is the first
10:34document that the browser fetches we
10:37look at this it calls this domain name
10:40and if you look at the response it is an
10:43HTML file the browser fetches the HTML
10:45file and all the resources for example
10:47all these JavaScript and all the images
10:51the fonts and the CSS files all of those
10:54different things are fetched in
10:55different different requests after we
10:57have our primary HTML file and in our
10:59record we see that we have an entry for
11:02this subdomain which is front end demo
11:04and it points to this particular IP
11:06address and if you trace that we land
11:08here which is the a E2 instance and we
11:10can see that this is the same public IP
11:12address next as usual the port 443 and
11:14the port 80 has to be allowed for https
11:17and HTTP traffic to get through to our
11:19server and finally the request land here
11:21our ec2 instance and if you look at the
11:24engine config this is what it looks like
11:27again most of the things are the same
11:29same as it was in our backend server we
11:31have the same Serb configs but the thing
11:34that is different is here we are
11:37listening for this domain which is the
11:39front end demo and whatever traffic that
11:41comes to here we are redirected to the
11:43Local Host 3000 instead of redirecting
11:46to 3001 we are redirecting to Port 3000
11:49and finally the request reaches our
11:50frontend nextjs server which serves the
11:53files which is the JS file the CSS file
11:56and the HTML file which are sent over
11:58the network to our browser and after
12:00going through all of that after we
12:01receive our main HTML file what the
12:04browser does is it goes through all
12:05these resources the JavaScript files the
12:08CSS files and the fonts and it fetches
12:10them one by one once it fetches all the
12:12CSS which you can see here it paints our
12:15window that's how we get all these
12:17Styles the background black and these
12:19fonts and these button Styles and once
12:21the browser fetches all the JavaScript
12:23files that's when it hydrates all the
12:25event listeners for buttons and all any
12:27kind of interactions that we have in
12:29this page for example if you click on
12:31this button this is what it happens it
12:33redirects to another page that happened
12:35because the browser fetched all the
12:36JavaScript added all the event listeners
12:38and that's how the button started
12:39working so what do we notice here
12:42whatever front end logic that you have
12:44written whatever the JavaScript that you
12:47have written is all fetched by the
12:50browser from our server and it is
12:53executed by the browser in our machine
12:56in client's machines right so the
12:59browser is our runtime compared to our
13:03traditional backends which we saw
13:05earlier the one in AWS ec2 instance
13:08where we sent a request the server
13:11processed the request and sent us the
13:13result so the actual processing happened
13:15on the server right and it is exactly
13:18the opposite for front end where it
13:20sends us the code but the browser runs
13:23the code whatever logic that is run it
13:25is run by the browser so that is a key
13:27difference to notice here now there are
13:29a couple of issues that we find here
13:32right because browser run times are
13:35often sandbox environments which means
13:38they are isolated from our operating
13:40systems the processes and the file
13:43system everything is an isolated
13:45environment which means the code can
13:47only access limited amount of resources
13:49for example the Dom which is the
13:52document object and browser apis for
13:55example local storage or cookies and
13:57external apis but only if the external
14:01API has the all the required amount of
14:04headers we have not covered course yet
14:06which we will in a future video in much
14:08more depth but you can imagine course as
14:11a policy a security policy of browsers
14:14which restricts JavaScript code to call
14:17external apis which is not the same as
14:19the current domain for example we have
14:21this frontend app in this domain which
14:23is frontend demo
14:24doxyz so we can only call resources or
14:29can only fetch resources and call
14:31external apis which are in the same
14:34domain if we try to call a different
14:37domain then the browser will block the
14:39request because of course policy and
14:41there are ways to get around that which
14:43are through HTTP headers which we will
14:45explore later and if you think about it
14:48all these sandboxing and security
14:50restrictions make sense because
14:52essentially what a browser is doing is
14:55it is fetching code from a remote server
14:57and executing it in the the users
15:00browser and if it's not careful enough
15:03or isolated enough the remote code can
15:05easily access data or files from users's
15:08computer which is not a good thing for
15:10example imagine you go to a website and
15:12you have no idea what is the prent code
15:15of that website and if browsers did not
15:17isolate environments that code can
15:20easily get access to your file system
15:22copy all your files your sensitive
15:23details and send it to their servers
15:26right so that is a very scary idea
15:28that's why browsers have all these
15:30security policies now coming back to our
15:32original question why can't we write
15:34backend logic in front end so the first
15:37thing obviously is security
15:40reasons security
15:43reasons because the security policies of
15:46browsers are so restrictive and often
15:48times a back needs to access underlying
15:50file system whether it's to write to a
15:52log file or access environment variables
15:56and browsers won't allow that that is a
15:58huge restrict
15:59for a backend server the second thing is
16:02you cannot call external apis whenever
16:05you want unless that API has all the
16:08appropriate cor headers and since we
16:10don't have control over all the external
16:13apis this is also a big deal breaker
16:15because backend servers often need to
16:18connect to other servers and fetch data
16:21from multiple places so we cannot have
16:23this restriction now the third thing is
16:26databases
16:30now the server runtime has access to all
16:32Native database drivers for example PG
16:35for postgis and mongodb and that allows
16:38it to communicate efficiently with
16:40databases these drivers are written to
16:42work in environments that can handle
16:44socket connections handle binary data
16:46and maintain persistent connections
16:48things that browsers cannot do and we
16:50will explore later how backend servers
16:52communicated with databases but to
16:54simplify it backend servers maintain a
16:57list of connection
16:59uh which is often called a connection
17:00pool to our database server so that it
17:04does not have to create and Destroy
17:06connections again and again because
17:09backend servers receive thousands and
17:11thousands of requests in seconds and if
17:14they do the connecting and destroying
17:16logic with each request the data server
17:18is going to get overwhelmed and it
17:20cannot handle that load so drivers are
17:24written in a way that can maintain a
17:27list of connections and browsers are not
17:29designed to maintain persistent
17:31connections to databases and even if
17:33they were each user would need to open
17:35their own delete connection to the
17:37database overwhelming the database
17:38server with too many connections there
17:40is also no easy way to manage connection
17:42pooling or efficient query execution
17:44from the browser environments now the
17:46last thing
17:48is computing
17:51power front end
17:53applications as we use them are
17:55everywhere it could be a smartphone it
17:58could be be a desktop it could be a
18:00laptop and any kind of environments that
18:03we can imagine even a computer which has
18:05a 256 mbf RAM and with a single core
18:08processor and the user might not have
18:10enough computing power to perform some
18:12heavy business logic and things will
18:15start to lag and sometimes break because
18:17of the load so for that reason if it's a
18:20centralized backend server which serves
18:23and CS to a large number of clients we
18:26can easily increase its memory and and
18:28CPU whenever we want and we can easily
18:31deal with the load we can continue this
18:33list as long as we want but this should
18:36give you a fair idea that keeping
18:38backend logic in front end is not a good
18:40idea uh that is assuming if we can do it
18:43in the first place great now we have
18:45seen what a backend is why do we need it
18:48and how does it work on a very high
18:50level now this is a very good place to
18:52be in before we start our journey of
18:54learning backend engineering now let's
18:56explore what are these principles and
18:58why we should learn in this particular
19:00way

About this transcript

This page contains the full transcript of 3. What is a Backend, how do they work and why do we need them? by Sriniously, generated from the public captions YouTube serves with the video. The transcript has 3,276 words across 464 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.