00:00 - 00:03
so in this video I want to give a little
00:01 - 00:05
progression of like how you
00:03 - 00:07
traditionally deploy an application and
00:05 - 00:09
how we've kind of reached a point where
00:07 - 00:10
we are now where we have like cdns that
00:09 - 00:12
are hosting all your static files we
00:10 - 00:15
have like Edge Computing we have
00:12 - 00:16
serverless Computing and stuff but let's
00:15 - 00:18
just take it a step back to like the
00:16 - 00:20
beginning of how do we deploy
00:18 - 00:22
traditional applications right so
00:20 - 00:24
traditionally you have a VM
00:22 - 00:27
and this could be like an ec2 instance
00:24 - 00:30
or a digital ocean droplet where you as
00:27 - 00:32
a developer or a system admin or
00:30 - 00:35
whatever you SSH into the box or you run
00:32 - 00:38
some type of like puppet scripts or
00:35 - 00:41
ansible scripts to basically install a
00:38 - 00:43
service so this is like your service I
00:41 - 00:45
could say it's Express JS since we're
00:43 - 00:46
kind of doing node on this channel right
00:45 - 00:49
so you have a VM and you want to
00:46 - 00:51
basically run your Express web API here
00:49 - 00:53
maybe you have some static files that
00:51 - 00:55
are hosted here but this is
00:53 - 00:57
traditionally how like you would kind of
00:57 - 01:00
and there's a lot of people who actually
00:58 - 01:02
do this they actually deploy Services
01:00 - 01:05
manually and kind of you know keep them
01:02 - 01:06
operational what you can also do is the
01:05 - 01:08
vm's big enough you can actually put a
01:06 - 01:11
database here too right you could put a
01:08 - 01:14
DB but this is like very very
01:11 - 01:15
manual work and a lot of people do not
01:14 - 01:18
have the expertise to actually like
01:15 - 01:20
exercise into a machine set up postgres
01:18 - 01:23
manually set up their service manually
01:20 - 01:26
have the you know the devops chops to
01:23 - 01:28
basically set up a pm2
01:26 - 01:30
um service so you don't know what pm2 is
01:28 - 01:31
basically it's a script you can use or
01:30 - 01:33
tool you can use to basically
01:31 - 01:35
continuously refresh and restart your
01:33 - 01:37
service if it were to crash for whatever
01:35 - 01:38
reason sometimes Services run out of
01:37 - 01:41
memory sometimes I throw exceptions they
01:38 - 01:42
have to be restarted but doing all this
01:41 - 01:45
and then managing this database by hand
01:42 - 01:46
it takes expertise right A lot of people
01:45 - 01:48
don't have the time to learn all this
01:46 - 01:50
but this is kind of how like we were at
01:48 - 01:51
for the longest time and this works for
01:51 - 01:54
small scale companies right this can
01:52 - 01:56
handle a lot of traffic especially if
01:54 - 01:58
you're using like AWS because you can
01:56 - 02:00
vertically scale you can start off with
01:58 - 02:03
like a nano and then you can go to like
02:00 - 02:05
a a micro I think I have these backwards
02:03 - 02:07
so like you could start with a nano and
02:05 - 02:08
see how that works and if that's not
02:07 - 02:10
enough memory you can go to micro and
02:08 - 02:12
then you go to small you can go to
02:10 - 02:14
medium you can go to a large and at some
02:12 - 02:16
point like you have a VM that has like
02:14 - 02:18
16 gigs of memory and can handle a
02:16 - 02:20
decent amount of traffic right but
02:18 - 02:22
there's an issue with vertically scaling
02:20 - 02:24
at some point you're going to need more
02:22 - 02:27
memory or you're going to need to be
02:24 - 02:28
able to handle more requests and this is
02:27 - 02:31
just not going to cut it right but again
02:28 - 02:33
if you're running a small little startup
02:31 - 02:34
company this I think will work pretty
02:33 - 02:36
well for the most part but again there's
02:34 - 02:38
a lot of costs hidden costs with like
02:36 - 02:40
managing the stuff yourself you don't
02:38 - 02:42
want to be sshing into a machine and
02:40 - 02:44
then also I would recommend like unless
02:42 - 02:45
you're working at a huge Enterprise you
02:44 - 02:46
don't want to be messing with puppet
02:45 - 02:48
chef and ansible like it's just a lot of
02:46 - 02:50
overhead to understand like how to set
02:48 - 02:52
up those orchestration tools on your
02:50 - 02:54
your cluster of VMS
02:52 - 02:55
so if that's out of the question for
02:54 - 02:57
like a beginner
02:55 - 02:58
what are the next steps well in terms of
02:57 - 03:00
scaling what you could do is you can
02:58 - 03:03
move the database
03:00 - 03:04
off into its own VM okay again we're
03:03 - 03:07
we're trying to show you the progression
03:04 - 03:09
of like okay let's split this out into
03:07 - 03:13
two VMS now so that my express service
03:09 - 03:15
is running on one VM and it communicates
03:13 - 03:18
with a database that is running on
03:15 - 03:19
another VM okay and again you can
03:18 - 03:21
vertically scale both of these
03:19 - 03:24
independently
03:21 - 03:26
okay so if your database has more needs
03:24 - 03:28
you scale it up if your service has more
03:26 - 03:29
needs you scale that up but again like I
03:28 - 03:31
said at some point with all this
03:29 - 03:33
vertical scaling you will hit a
03:31 - 03:35
threshold and you don't want to be
03:33 - 03:38
managing databases by hand so what we
03:35 - 03:41
typically do is we offload the database
03:38 - 03:42
to a third-party service so let's just
03:41 - 03:45
go ahead and put one here I'll just say
03:42 - 03:49
like we're using um Railway I've used
03:45 - 03:50
Railway a couple times on my service so
03:49 - 03:52
like basically you're saying I don't
03:50 - 03:54
want to manage this myself although this
03:52 - 03:56
is probably like one of the cheaper
03:54 - 03:58
options in terms of operational costs if
03:56 - 04:00
you know how to like manage and monitor
04:00 - 04:04
but for most of us we don't want to have
04:02 - 04:07
to do that stuff right so what we do is
04:04 - 04:09
we offload that responsibility to a
04:07 - 04:12
service who has experts that know how to
04:09 - 04:13
run a postgres database they know how to
04:12 - 04:15
monitor it and they know how to do
04:13 - 04:17
security patches and updates on it right
04:15 - 04:18
so you're going to pay a little bit more
04:18 - 04:24
typically because you're paying someone
04:22 - 04:26
for their expertise to take care of
04:24 - 04:28
managing this thing and then like you
04:26 - 04:30
know Amazon has a RDS instance you can
04:28 - 04:32
use you can use like Planet scale you
04:30 - 04:34
can use uh uh what's what's the other
04:32 - 04:36
one called you could use like super bass
04:34 - 04:37
Super Bass or whatever but the idea is
04:37 - 04:41
this allows you to scale better because
04:39 - 04:43
again typically this thing has the
04:41 - 04:45
ability to vertically scale as well and
04:43 - 04:47
it's usually like a one click a button
04:45 - 04:50
in the service to just scale it up to
04:47 - 04:52
accept more traffic but also remember as
04:50 - 04:53
you scale up they end up charging more
04:52 - 04:55
money right so keep that in mind that
04:53 - 04:57
these Services they work great in the
04:55 - 04:59
beginning but as you get more traffic
04:57 - 05:01
and as you have more data needs you need
04:59 - 05:03
to keep track of how much they're going
05:01 - 05:05
to end up charging you based on your
05:03 - 05:06
usage so that's one thing you split the
05:05 - 05:07
database out and you scale that
05:06 - 05:09
separately so what about the service
05:07 - 05:11
right what if your service ends up
05:09 - 05:14
needing to need more computational power
05:11 - 05:16
okay so what you can end up doing is you
05:14 - 05:18
can copy and paste all this stuff let's
05:16 - 05:20
just group it and copy and paste it and
05:18 - 05:22
you could make different instances of it
05:20 - 05:23
okay so this is called horizontally
05:23 - 05:28
horizontal scaling
05:26 - 05:31
where you just create copies of the same
05:28 - 05:33
service and so that when a user needs to
05:31 - 05:34
access this let's just go ahead and put
05:34 - 05:40
he needs to basically just randomly pick
05:38 - 05:43
one of these things to do its request
05:40 - 05:45
right so when he loads a browser up he
05:43 - 05:47
needs to hit something in front of all
05:45 - 05:50
this this is usually called a load
05:47 - 05:51
balancer you can use like nginx if you
05:50 - 05:54
want to kind of like set this up the
05:51 - 05:55
manual way which again not a fan of but
05:54 - 05:57
I do I do just want to kind of talk
05:55 - 05:59
about it so like you have some context
05:57 - 06:00
of how this all works what is a load
05:59 - 06:02
balancer a load balancer is basically
06:00 - 06:04
sitting in between your services and
06:02 - 06:08
your user so that the user says I need
06:04 - 06:09
to connect to your app.com right and
06:08 - 06:11
what the load balancer says is okay well
06:09 - 06:13
I have two different services that are
06:11 - 06:15
running and what I'm going to do is I'm
06:13 - 06:18
going to randomly pick one
06:15 - 06:19
to basically for that traffic to one or
06:19 - 06:23
there's different ways you can kind of
06:21 - 06:25
implement this forwarding you could do
06:23 - 06:29
like round robin I believe there's one
06:25 - 06:31
called like sticky sessions where based
06:29 - 06:32
on your IP it'll basically send you to
06:31 - 06:34
the same service every single time
06:32 - 06:37
there's a lot of different strategies
06:34 - 06:40
for Distributing the load but again the
06:37 - 06:43
purpose of the load balancer is to fan
06:40 - 06:45
out every request so that one server is
06:43 - 06:47
not overloaded with too many requests
06:45 - 06:49
you can keep the memory down and the CPU
06:47 - 06:51
down on these machines so as you get
06:49 - 06:54
more and more scale you need to
06:51 - 06:56
basically keep on adding these things to
06:54 - 06:59
this right you'd have to keep adding
06:56 - 07:00
more and more and more because in order
06:59 - 07:03
to handle the amount of traffic you need
07:00 - 07:05
you have to basically keep scaling up so
07:03 - 07:07
that brings us to basically services
07:05 - 07:10
that provide something called Auto
07:07 - 07:11
scaling groups okay so you've used like
07:11 - 07:17
or have you used um anything Amazon with
07:14 - 07:20
like ec2 or manage instances basically
07:17 - 07:22
what you do is you give it a definition
07:20 - 07:24
like this I'm going to say give it a
07:22 - 07:25
definition I'm going to go ahead and
07:24 - 07:27
just put like Auto scaling group I know
07:25 - 07:29
that's kind of like a convention that I
07:27 - 07:31
think Amazon uses a lot but basically
07:29 - 07:33
depending on where you're hosting your
07:31 - 07:36
service if you're using like um again
07:33 - 07:38
like kubernetes or I think fargate is
07:36 - 07:40
another one on Amazon you can use you
07:38 - 07:42
can set some numbers and I want to say
07:40 - 07:44
you know Min is one server
07:42 - 07:47
men of one server
07:44 - 07:49
and Max of five servers and what this
07:47 - 07:51
Auto scaling group basically does and
07:49 - 07:52
typically I think this also includes
07:51 - 07:53
your load balancer
07:53 - 07:56
you can kind of fact check me on this if
07:56 - 08:00
but now you have basically abstracted
07:59 - 08:02
away the need to manage all that stuff
08:00 - 08:04
yourself and instead you're saying hey
08:02 - 08:06
Amazon you get you take care of this for
08:04 - 08:08
me you basically inspect the traffic of
08:06 - 08:11
my load balancer and if you notice that
08:08 - 08:14
like I'm getting a lot of traffic Amazon
08:11 - 08:16
and other services will basically spin
08:14 - 08:17
up another instance for you
08:16 - 08:20
and do all that routing for you
08:17 - 08:22
automatically so let's talk about um how
08:20 - 08:24
do you actually like split up your API
08:22 - 08:25
from your front end because right now we
08:24 - 08:27
have like both of them bundled together
08:25 - 08:28
like this is your API in your front end
08:27 - 08:30
all being hosted from the same service
08:28 - 08:33
like again if this was like you manually
08:30 - 08:35
hosting a next application it would be
08:33 - 08:37
hosting your UI and your API right but
08:35 - 08:39
at some point depending on the size of
08:37 - 08:42
the project and the scale in the team
08:39 - 08:46
you might actually want to deploy your
08:42 - 08:48
API as a separate Standalone service and
08:46 - 08:49
because apis typically end up having
08:48 - 08:51
different needs
08:49 - 08:53
um you might have more complexity you
08:51 - 08:55
might need more computation and the UI
08:53 - 08:57
might not have as many needs as well
08:55 - 08:58
right so like the UI could be really
08:58 - 09:02
you might just need like one or two
09:00 - 09:05
servers in your auto scaling group but
09:02 - 09:07
the API let's say you do a lot of heavy
09:05 - 09:08
computation its Auto scaling group might
09:07 - 09:10
need to be a lot higher you might need
09:08 - 09:14
to say I need a Min of three servers and
09:10 - 09:16
a Max of 10 servers or you know
09:14 - 09:18
whatever and so the idea is you would
09:16 - 09:21
set this all up kind of separately and
09:18 - 09:23
deploy this separately you have probably
09:21 - 09:25
it could be in the same repo or a
09:23 - 09:28
different repo where when the user tries
09:25 - 09:32
to load the UI it's going to first fetch
09:28 - 09:34
the UI from this setup and then when the
09:32 - 09:36
user browser needs to fetch some data it
09:34 - 09:38
would basically hit this other load
09:36 - 09:40
balancer which should go over here
09:38 - 09:41
okay so just looking at this like you
09:40 - 09:44
can just tell the complexity is starting
09:41 - 09:45
to increase right this is not easy stuff
09:44 - 09:47
to figure out and it takes a lot of
09:45 - 09:48
expertise to like get good at it but
09:47 - 09:50
what we've seen at least with single
09:48 - 09:52
page applications is that hey you know
09:50 - 09:55
the UI doesn't really change that often
09:52 - 09:59
what we can actually do is we can deploy
09:55 - 10:01
our UI to a CDN so a CDN is basically a
09:59 - 10:04
way to take a bunch of static files
10:01 - 10:06
and let's just pretend this is like the
10:04 - 10:08
globe this is going to be a bad diagram
10:06 - 10:10
okay this is the globe let's just move
10:08 - 10:13
our database like back over here
10:10 - 10:15
like this let's just pretend our API is
10:13 - 10:17
connecting to this
10:17 - 10:22
so this is like a CDN and this is like
10:19 - 10:24
my example of like a the globe right
10:22 - 10:26
let's just put the world I'll just put
10:24 - 10:28
regions here the CDN basically is a
10:26 - 10:29
network of different machines across the
10:29 - 10:34
and every machine has its own like
10:31 - 10:36
caching system which is going to
10:34 - 10:39
basically take your UI and distribute it
10:36 - 10:40
to all of these different nodes now
10:39 - 10:42
typically there is something called An
10:40 - 10:44
Origin server
10:42 - 10:46
I'll just put like a square here and put
10:44 - 10:48
like origin and that could be like an S3
10:46 - 10:50
bucket which is holding your files so
10:48 - 10:55
like that's your compiled
10:50 - 10:57
HTML CSS and JS and the origin server
10:55 - 10:59
basically when a user makes a request to
10:57 - 11:01
your the CDN
10:59 - 11:02
there's some magic going on where
11:01 - 11:05
basically it's going to Route them to
11:02 - 11:08
the closest server based on geographical
11:05 - 11:09
location right so if I'm on if I'm in
11:08 - 11:11
Florida it's probably going to route me
11:09 - 11:13
to an East Coast node
11:11 - 11:15
and that node is basically going to
11:13 - 11:17
check hey do I have the files necessary
11:15 - 11:20
to host this UI if not I'm going to go
11:17 - 11:21
ahead and just make a request to this
11:20 - 11:23
origin server and I'm going to pull
11:21 - 11:25
those files over and then I'm going to
11:23 - 11:27
Cache them for some amount of time right
11:25 - 11:29
so this is how we basically scale up all
11:27 - 11:31
the static assets like all the images
11:29 - 11:34
all the front-end JavaScript the HTML
11:31 - 11:36
that stuff gets distributed to a CDN and
11:34 - 11:37
this stuff will live here for a certain
11:36 - 11:39
amount of time
11:37 - 11:42
based on whatever policies you have you
11:39 - 11:44
have set up so if the user decides to
11:42 - 11:46
hit this thing again this whole trip
11:44 - 11:48
here is basically not needed because the
11:46 - 11:50
files are already going to be cached so
11:48 - 11:53
that's the idea at least recently how
11:50 - 11:56
the front end has been kind of scaled up
11:53 - 11:57
and sped up we have a CDN which hosts
11:56 - 11:58
all the front-end files and I believe
11:57 - 12:01
that's how like versel and other
11:58 - 12:04
companies work they have like the same
12:01 - 12:05
concepts of your your static HTML now
12:04 - 12:07
what you can actually do as well if
12:05 - 12:11
you're doing like server-side rendering
12:07 - 12:13
is you can actually put your API behind
12:11 - 12:15
the CDN as well right so the user would
12:13 - 12:17
make a request to the CDN
12:15 - 12:19
the CDM will figure out what region you
12:17 - 12:21
need to hit and based on different
12:19 - 12:24
routing rules you could have a route
12:21 - 12:26
that goes to your API and again the same
12:24 - 12:28
concept is you can have different types
12:28 - 12:32
cash policies where if your API request
12:31 - 12:34
returns some data you can have a cached
12:32 - 12:36
for five minutes on data that doesn't
12:34 - 12:37
change that often but again this is how
12:36 - 12:39
we get more and more into like how do we
12:37 - 12:41
how do we handle more traffic how do we
12:39 - 12:43
handle more scale and again it's we're
12:41 - 12:45
just trying to reduce the load on the
12:43 - 12:48
servers that we can handle more traffic
12:45 - 12:49
this has trade-offs caching always has
12:48 - 12:51
um trade-offs because sometimes we need
12:49 - 12:53
cache data it's going to be stale and
12:51 - 12:55
depending on the type of application
12:53 - 12:58
your users might need 100 live data
12:55 - 13:00
other times they can work off of cache
12:58 - 13:02
data so you have to kind of keep that in
13:00 - 13:04
mind and figure out those trade-offs
13:02 - 13:06
but that's how we scale up the front end
13:06 - 13:11
we use a CDN and the back end this is
13:09 - 13:14
typically how we do it now we can take
13:11 - 13:16
this a step further because
13:14 - 13:19
even the database this is like a single
13:16 - 13:20
point of failure now right so we have to
13:19 - 13:23
be able to scale up the database and
13:20 - 13:25
what we typically end up doing are
13:23 - 13:27
Services end up doing for you is that
13:25 - 13:30
again kind of similar to the CDN they
13:27 - 13:32
will scale up your databases and
13:30 - 13:34
distribute them to various regions right
13:32 - 13:36
so for example you might have a primary
13:34 - 13:39
database here that's like in Us East one
13:36 - 13:42
but you may have replicas that are in
13:42 - 13:46
or I don't know the European Union or
13:44 - 13:49
something and what happens is that all
13:46 - 13:52
of the rights typically need to go to
13:49 - 13:53
like a primary database and then once
13:52 - 13:56
you write to that database it
13:53 - 13:57
distributes that data to other servers
13:56 - 13:59
in different regions so depending on
13:57 - 14:01
where the user made the request from
13:59 - 14:03
your API can actually fetch data from
14:01 - 14:05
the closest region to you and kind of
14:03 - 14:07
speed that up as well
14:05 - 14:10
now this is not a simple concept either
14:07 - 14:11
right so there's a lot of services that
14:10 - 14:12
do this for you I believe playing that
14:11 - 14:14
scale will do this stuff for you out of
14:12 - 14:17
the box like RDS will do this Auto
14:14 - 14:18
scaling replica stuff out of the box
14:17 - 14:21
um you could use something like dynamodb
14:18 - 14:24
that kind of takes care of this type of
14:21 - 14:26
large-scale needs out of the box but
14:24 - 14:27
keep in mind that this stuff is not easy
14:27 - 14:30
which is why you usually just end up
14:29 - 14:33
paying a service that takes care of this
14:30 - 14:34
if you need this type of scaling let's
14:33 - 14:37
progress this even more right now we're
14:34 - 14:38
just doing like hard-coded deployed
14:37 - 14:40
servers and again these could be like
14:38 - 14:42
Docker containers or these could all be
14:40 - 14:43
running on their own VMS
14:42 - 14:46
it doesn't really matter those those are
14:43 - 14:48
implementation details but a movement
14:46 - 14:50
that I think a lot of companies are
14:48 - 14:52
doing now is instead of having like your
14:50 - 14:55
Express server running on a dedicated
14:52 - 14:57
machine we're actually moving over to
14:55 - 14:59
serverless computations let's talk about
14:57 - 15:01
serverless so that's also another thing
14:59 - 15:03
that's like helping with scale where
15:01 - 15:05
instead of you having like multiple
15:03 - 15:08
Express applications
15:05 - 15:10
you know behind a load balancer you
15:08 - 15:12
actually have a function that function
15:10 - 15:15
is basically scaled up based on your
15:12 - 15:17
needs right so like Amazon has AWS
15:17 - 15:21
um I'm sure Google has one I'm sure
15:19 - 15:23
Azure has one
15:21 - 15:24
but basically you have a function and
15:23 - 15:26
that thing's going to scale up based on
15:24 - 15:28
your data needs the cool thing about AWS
15:26 - 15:31
Lambda is that like these things can
15:28 - 15:33
scale up super easily like if you have a
15:31 - 15:34
a burst of traffic where you have like
15:33 - 15:36
thousands of requests that come in
15:34 - 15:38
you'll see your Lambda functions just
15:36 - 15:40
scale up like instantly and handle all
15:38 - 15:43
that load so instead of you having to
15:40 - 15:44
like wait for this Auto scaling stuff to
15:43 - 15:46
provision a VM
15:44 - 15:48
set up your service or if you're using
15:46 - 15:50
kubernetes provision a new container and
15:48 - 15:52
let that load
15:50 - 15:54
which takes a little bit of overhead
15:52 - 15:55
this stuff is like almost pretty
15:54 - 15:57
instantaneous right it takes like a
15:55 - 16:00
second or two seconds based on the cold
15:57 - 16:02
star so these land is coming up and that
16:00 - 16:04
is how you achieve another aspect of
16:02 - 16:06
scale right it's just Auto scaling all
16:04 - 16:08
of these functions and the cool thing
16:06 - 16:10
about this is that every function is
16:08 - 16:12
basically ran in isolation so the issue
16:10 - 16:14
I had before with like running an
16:12 - 16:16
Express server
16:14 - 16:18
if you have like 100 requests going to
16:16 - 16:20
the express server and it crashes you
16:18 - 16:22
basically have 100 people who just like
16:20 - 16:25
lost all of their their request data
16:22 - 16:28
versus on Lambda every function is
16:25 - 16:30
basically ran in isolation so if one
16:28 - 16:32
function throws an exception the other
16:30 - 16:33
100 will not crash because they're all
16:32 - 16:35
ran in isolation
16:33 - 16:37
in their own kind of like execution
16:35 - 16:39
context or whatever
16:37 - 16:41
so this is scaling on another level
16:39 - 16:43
which is also cool to understand we have
16:41 - 16:45
the CDN still for the front end stuff
16:43 - 16:48
that could potentially be in front of
16:45 - 16:51
your Lambda functions that's caching
16:48 - 16:53
responses as needed and this is again
16:51 - 16:54
like however cell kind of works like it
16:53 - 16:56
they have a bunch of API Lambda
16:54 - 16:58
functions so how do you scale this up
16:56 - 17:00
even more I think we should talk about
16:58 - 17:02
Edge functions now we have this ability
17:00 - 17:03
to basically take execution like take
17:02 - 17:06
JavaScript code or take whatever type of
17:03 - 17:08
code and you can run it inside of an
17:06 - 17:11
edge Network and again the edge is going
17:08 - 17:14
to basically take a user's request
17:11 - 17:16
and run the code as close as possible to
17:14 - 17:18
the user so this is for scaling and
17:16 - 17:20
performance reasons again the way you
17:18 - 17:21
scale is reducing the amount of traffic
17:20 - 17:23
and load to your services so you can
17:21 - 17:25
handle more requests per second and if
17:23 - 17:27
one way you can do that is actually have
17:25 - 17:29
the computation lift closer to the user
17:27 - 17:31
and not have them need to go to the data
17:29 - 17:32
center to like do this computation
17:32 - 17:35
if you imagine this thing is going to be
17:34 - 17:38
a little bit further away in terms of
17:35 - 17:39
like distance from hopefully these
17:38 - 17:40
things right there's different servers
17:39 - 17:42
around the world and you're trying to
17:40 - 17:43
connect the user to the closest one
17:42 - 17:46
possible so these two are probably going
17:43 - 17:47
to be close in proximity and this one's
17:46 - 17:48
going to be a little bit further away so
17:47 - 17:50
this has a lot of benefits because you
17:48 - 17:52
can like reduce the amount of traffic
17:50 - 17:54
that needs to go to your API which again
17:52 - 17:56
will reduce the amount of traffic that
17:54 - 17:58
needs to go to your databases and reduce
17:56 - 17:59
your load on your servers so this
17:58 - 18:00
solution isn't perfect either because at
17:59 - 18:03
some point your Edge function probably
18:00 - 18:05
needs to talk to a database and right
18:03 - 18:07
now you could either have the edge
18:05 - 18:09
function talk directly to a database
18:07 - 18:10
which unfortunately some Edge providers
18:09 - 18:13
don't even allow you to run like binary
18:10 - 18:14
so like running something like Prisma on
18:13 - 18:16
your Edge function might not even work
18:14 - 18:17
so you basically have to just make sure
18:16 - 18:19
you do an API request from your Edge
18:17 - 18:21
function to your database if your
18:19 - 18:22
database supports like those type of
18:22 - 18:25
um and that can sometimes shave off some
18:23 - 18:27
latency so that you don't have to go
18:25 - 18:29
through the API but I think it's worth
18:27 - 18:31
mentioning that usually the API is
18:29 - 18:34
actually super close to your servers
18:31 - 18:36
right so the latency between the server
18:34 - 18:36
and the database is going to be really
18:36 - 18:42
versus the latency between
18:39 - 18:44
your Edge function in the database will
18:42 - 18:46
be a lot higher so again I think the
18:44 - 18:48
main benefit of the edge function is if
18:46 - 18:52
you can kind of filter out data and
18:48 - 18:54
reduce the need to go to the the
18:52 - 18:56
database you're going to speed up your
18:54 - 18:58
your system I think we're also seeing
18:56 - 19:00
the industry go is we're having
18:58 - 19:02
basically this need to have Edge
19:00 - 19:05
databases so instead of having these
19:02 - 19:07
like primary replicated databases we're
19:05 - 19:10
trying to find ways to get databases to
19:07 - 19:15
be scaled inside the edge as well
19:10 - 19:17
so if every region has its own you know
19:15 - 19:19
front-end static files it has its
19:17 - 19:22
functions and it has its databases right
19:19 - 19:25
here this basically reduces a lot of the
19:22 - 19:27
overhead of connecting to a data center
19:25 - 19:29
and I would say probably this is a lot
19:27 - 19:31
more for like performance reasons and
19:29 - 19:33
not necessarily scaling but as you can
19:31 - 19:37
tell like all this stuff
19:33 - 19:39
is complex right like this this is all
19:37 - 19:42
being figured out in maintain and
19:39 - 19:44
managed by expert devops engineers and
19:42 - 19:46
system level engineers and database
19:44 - 19:47
engineers and it's not a problem that
19:46 - 19:49
you really want to spend a lot of time
19:47 - 19:51
trying to figure out yourself so I think
19:49 - 19:53
the the benefit of all this is that if
19:51 - 19:54
you are at a small company and all of a
19:53 - 19:57
sudden you get a ton of traffic and your
19:54 - 19:58
like startup is blowing up
19:57 - 20:01
um because it just can't handle the
19:58 - 20:03
traffic if you use something like versel
20:01 - 20:04
or these other services that kind of
20:03 - 20:06
provide the scaling out of the box for
20:04 - 20:07
you you're going to be good all right
20:06 - 20:09
you don't have to worry too much about
20:07 - 20:10
what happens if my server gets too many
20:09 - 20:12
requests is it going to crash and then
20:10 - 20:14
my entire company's
20:12 - 20:16
um you know servers are going to be 404
20:14 - 20:18
errors so using existing services will
20:16 - 20:20
kind of take the responsibility of
20:18 - 20:22
scaling everything manually out of your
20:20 - 20:23
hands and just leaves it in their hands
20:22 - 20:25
and all that for good reasons right
20:23 - 20:27
they've had years of experience doing it
20:25 - 20:29
and that is why you're paying them the
20:27 - 20:33
decent amount of money for them to kind
20:29 - 20:34
of take control of that type of stuff so
20:33 - 20:36
I think that's all I want to talk about
20:34 - 20:37
I don't know if this was a good talk
20:36 - 20:40
um I feel like at some point I just
20:37 - 20:41
started rambling and drawing circles and
20:40 - 20:43
lines everywhere but if you guys enjoyed
20:41 - 20:46
at least listening to me ramble about
20:43 - 20:48
this and how we've kind of went from a
20:46 - 20:50
single simple VM deployment to something
20:48 - 20:52
like super complex like we have here
20:50 - 20:53
give me a thumbs up also I have a
20:52 - 20:55
Discord Channel you're welcome to join
20:53 - 20:56
if you want to talk to me directly or
20:55 - 20:58
just find a place to hang out with some
20:56 - 21:00
other Developers it's in the description
20:58 - 21:02
of the video in below as a link other
21:00 - 21:04
than that yeah leave me a comment if you
21:02 - 21:05
think I completely messed up this
21:04 - 21:08
explanation or there's something I left
21:05 - 21:11
out I'm always eager for feedback all
21:08 - 21:11
right have a good day happy coding
video to article