And welcome back in today's video, we'll be discussing about Mladic.
Now at a high level overview basically allows you to run your Lamela function to customize the content
that your cloud friend might deliver to your end users.
Now, basically, this can be easily explained in a diagrammatic view, because if we directly jump
into these theoretical points, it will just confuse.
So this is a diagrammatic representation.
So let's say this is a user.
This can be a browser.
Ciarlante and you have a cloud front here.
This is a cloud friend.
Gosh.
And this is the origin.
Now, this can be a street market or whatever website that you are running behind the scenes.
You know what lamda at the Edge allows you to do is it allows you to run lamina function at four major
points.
First major point is before the request hits the cloud.
Friend Gosh, the sticking point is after the request misses the cloud cache and before it hits the
origin.
So this is the second point where you can run your lamda function.
Third point is as soon as you get the data back from your origin, this is the third part.
And the fourth part is after the data traverses the cloud print cash and before it goes back to the
user, you have one more point.
So there are four pointers where you can run your lambda function.
Now, these pointers are defined by a name.
The first one is defined by viewer request.
Second one is defined by origin request.
Then you have the original response.
And fourth is the viewer response.
No, because of the capability of a dabblers to run your lambda function in these four pointers, it
really allows a lot of possibilities and a lot of capabilities.
So let's go back to our first slide and understand about each of these points.
So now coming back to the second point of the first slide, it states that you can run your lambda function
to change the cloud print request and responses at the following points.
Now, we already discussed that there were four pointers.
Now, these are the four pointers that you need to remember versus viewer request.
Second is original Questers original response.
And for this viewer response, now a viewer request is nothing, but after cloud print receives a request
from a viewer.
So this is what the viewer request is all about.
Second is the original request, which basically states that this is the location before cloud print
forwards, the request to the origin.
So before.
So you have a cloud from Casoria now before you forward the request to the origin, there is a pointer
woodier.
So at this point that is referred to as the original request.
Now the third one is the original response, which is basically after cloud print receives the response
from the origin.
So this is the third place of it.
And the fourth place is the viewer response, which basically states that before the cloud front forwards
the response to the viewer.
So this is the location.
So before the request is sent back to the user agent.
This is the fourth place.
Now, do remember that this representation that you see here, it's basically the cloud front cash.
So let's do one thing.
Let's understand about each of these event in a detailed manner.
Now, the viewer request is basically executed on every request before the cloud from cash is checked.
This is something that we already saw that a viewer request, so any lambda function that you put it
in.
So these are the four locations where you can put your lambda function and that lambda function will
execute at each of this location whenever a request is arrived.
So any lambda function that you put at this specific location will be executed every time before the
cloud friend cashes check.
Now, there are a lot of benefits of running of function at the viewer request.
One of the benefit is modifying the Eurail.
You can do a cookie, you can do a query, string related modification.
And one of the very famous ones of it is also easy to explain is perform authentication and authorization
checks.
So this can be understood with the following diagram where you have a user agent over here and you have
a cloud front.
So as soon as the cloud receives the request, then the first thing before the cloud front cash is git
is the viewer request.
Even so, viewer request even can basically look into what is their request that the user agent has
sent, whether the request contains the appropriate password, which is required to open the website.
If the request contains the appropriate password to open the website, then the request will be go to
the OCC and then it will be sent to the origin.
If the request does not have the password, then your viewer request even can send the EDP for 03 back
to the user agent.
And this password authentication is one of the functions which a lot of organization put at the viewer
request level itself.
Because if if let's say that a user agent is requesting for a specific file and that file is Kastoria
now, it might be possible that the request would not go to the original.
The request would be responded from the cache itself.
So it is very important specifically if you have kind of a password authentication, you put your password
authentication related tick in the viewer request so that as soon as the request is arrived at the cloud
threat level, you run your lambda function here and that lambda function can determine whether the
request should be allowed to pass or not.
Now, the second part is the original request.
Now, origin request is generally a location of your lambda function, which would execute whenever
a cache is missed or before a request is forwarded to the origin.
Now, basically, there are lot of things that you can do at this stage, like dynamically sector the
origin based on the request headers.
So let's understand this.
But so this is the diagram of the original request.
If you note, I have to start over here so that it is easy to know on which function or which location
we are discussing about.
So here we are, assuming that the request first went to our friend, then you have the viewer request,
then it went to cloud frenk cache.
There is a cache, miss.
Do remember important part to remember you.
If a cache hits that, then Cloud Front can deliver the data directly to the user and then the original
request and the original response might not execute.
So it is important to remember.
So whenever a cache miss occurs, the data traverses to the original request audio now origin request
that you can control a lot of parameters.
We're one of the parameters are one of the use cases that you can work at this level is dynamically
set the origin based on the request headers.
So it might happen that there are multiple origins.
Let's say you have a S3, but do you have an easy to instance?
No.
From this lambda function, you can tell whether the request should go to the S3 bucket or to the easy
to instant's based on the request headers.
So all of those control you can have at the original request level itself.
Now you can also directly send the data from the original request back.
It is not necessarily that it would hit the endpoint.
So depending upon what is the logic that you want to define audio.
So the next part that we need to discuss is the origin response.
Now, Origin response basically is executed on a cache miss after a response is received from the origin.
So if we look into their diagram associated with or is in response.
So Aurélien response comes after the origin and the date of it origin sends back.
It goes to the original response stage audio.
Now, again, this stage is very important and you will be able to as you will.
Use cases from this in response, stage one is you can modify the response headers and you can also
intercept and replace various forensics and fire errors from the origin.
So let's say you have origin.
It can be easy to instant and somehow your application is down and it is not working at all.
And what it gave, it gave a five hundred error back.
Now, at the original response, you can have a logic that whenever you get a 500 response from the
origin, either it can replace that response with a specific.
You can see a bit saying that the website may be in a maintenance or the origin response can connect
or it can say not residual redirect to a back in or to the backup origin for the request to happen.
So this is also one critical stage.
Now, the last stage is the viewer response.
Viewer response is basically the function which gets executed on all the responses received either from
the origin or from the cache.
Now, this, again, is a very important state because it might happen that after viewer request, the
request might hit the cloud from cash and from the cloud from gas.
It said the data would go back to the user agent.
So this right site might not get executed at all.
So if you want certain functions to happen for all the responses which are being sent back to the user
agent, putting your function at the viewer response limit is extremely important.
Now, one of the use cases, which a lot of organizations use the viewer response for is to modify the
response header before the caching of the response happens.
Now, basically what happens is from the original response, if you have certain headers, it might
get gassed at the cloud Frankish.
But if you put it at the viewer response level, you will not have the caching at all.
It will go directly at the user agent level.
So this is the high level overview about LAMDA at D.H.
I hope this video has been informative for you and I look forward to seeing the next video.