In the last lecture, we learned how to look into the lambda function and we saw the object being passed
to that function, that request object with all the request metadata.
Now as I said at the end of the last lecture, I don't like that,
I like my lambda functions to be clean and to only work with the data I need.
I think the lambda functions shouldn't need to parse any incoming event and extract exactly what it
needs if
it doesn't need 90% of that data, instead
that should be the job of the API Gateway.
There,
you should ensure that you only pass to your action, lambda in this case,
what this action needs.
So I will go back to integration request and uncheck this lambda proxy integration, confirm and confirm
again and we're back to the old world thereafter with the body mapping template.
Now again, since no template is selected, the whole request body is forwarded to lambda.
So now if we reword this to simply login the event and we test this again by passing an object where
we have name, Max, I'll omit the age here, we see that we get this back and this is back to the state we were at.
Now
I was mentioning a more elegant way of extracting data and only passing data to lambda it needs,
this way uses body mapping templates,
let me change the structure of the request body.
Let's say we actually have a person data property here which is another object which then in turn holds
that name.
So this is the data we send and we maybe also have the age here, 28. This is the data we send to lambda, if we
do send it, we get this returned.
Now in the lambda function, let's say I don't just want to return this event data,
instead what I want to do here is I log it,
then I want to retrieve the age and I want to retrieve age on the event.
However right now, I would have to use person data age, right because age is a property
on this person data object here. I also get the name even though the lambda function is not interested
in that
and here, I could return age times two. Now if I save this and I click test again, we get back 56 which is twice
28.
So that makes sense
but again, the lambda function has to care about the structure of the data it receives.
It would be much better if the lambda function could simply access age on the event because it knows that
there will be an age property and only age property because that is all this lambda function needs
and this is where body mapping templates enter the stage. In the integration request and response,
we can use them to map in the case of request, the data we pass to the action and in the case of response,
data we get out of that action.
So here integration request, we can scroll down and first of all switch this to when there are no templates
defined.
Now let's add a template, I'll name it application/json
and with that, the request body will not be forwarded by default anymore but this template will be used,
though just as for the response if this template is empty, it will still forward the request
but if I simply set this to an empty object here and hit save and we now go back to testing this, let
me hit
test here, you see we get back null and we can check our cloud watch logs here, the latest stream to see
that indeed, we get an empty object here,
this is what we'll log the console here.
The reason for this is that in our template, we transform the incoming data and simply pass on an
empty object to our action, to lambda.
Not super useful obviously but just showing what we can do with that.
Now typically of course, we don't overwrite the data with an empty object,
instead what we want to do here is do something more useful and use the powerful body mapping template
language
AWS API Gateway provides us with.