Serverless with AWS Lambda

Setup API Gateway Locally

Scott Moss

Scott Moss

Superfilter AI
Serverless with AWS Lambda

Check out a free preview of the full Serverless with AWS Lambda course

The "Setup API Gateway Locally" Lesson is part of the full, Serverless with AWS Lambda course featured in this preview video. Here's what you'd learn in this lesson:

To get the same functionality of API Gateway to develop locally, Scott shows how to use the Serverless offline mode plugin.


Transcript from the "Setup API Gateway Locally" Lesson

>> Scott Moss: All right, so, let's hop into this. Let's check out to the next branch here.
>> Scott Moss: lesson-2, and lesson-2 has got a lot more stuff in it.
>> Scott Moss: So I'm just gonna walk through some of this stuff. One, in the serversless yml file, we got two handlers here.

You all know what these are. You know what functions are. You what handlers are. So this shouldn't be new. I just have two new functions. And then there's this API folder would like todo.js and todos.js. So that's what you get here. Now, what we're gonna do is we're gonna make a new function, and instead of just running this function locally with invoke, we're gonna hook this function up to an HTTP event.

And then we're gonna use this plugin called serverless-offline to actually start a server offline for us. That executes our function serverless, all right, let me explain that. So API gateway is the thing that's sitting in between your client and your lambda. So therefore, it's a long live process, it's a server, API gateway is a server.

We're gonna emulate that server on our machine, API gateway, but our functions are still serverless and they're gonna be executed in a different context. So API gateway, locally on our machine, is gonna execute our lambdas for us, just like it would on AWS. And that's what we're gonna do locally.

That is different than what we just did, which is where we just invoked the lambda without an API gateway in between it. And we passed in our own event. We're now gonna go through a local API gateway, which formats the event the exact same way that I just showed you.

It's gonna do that formation for us. Everybody following me there? Okay, so let's make a new function. I'm gonna make a new function here. And I'm just gonna call this one api.js.
>> Scott Moss: And I'll call it handler.
>> Scott Moss: And it's gonna take an event, some context, and then done.

And this context object's actually going to have some stuff announced. So we'll look at it too when we get there. And remember I said, done takes null, and then whatever response you want, well, now because we're using the API gateway, and we're using the proxy method. API gateway calls Arelanda and then we would respond.

That goes back through API gateway, then API gateway responds back to our client. So API gateway is the final piece before our client sees it. So in order for API gateway to respond back to our client in a predictable way, we have to respond back to API gateway in a predictable way.

So they give us a format in which we have to respond to them. So we can no longer just put whatever the hell we want here. In fact, the syntax now is gonna be something like this. You put a status code. And you can put whatever status code you want here.

So like if this lambda resolved to a 200, then I would put 200 here. Or if it was a 401, then I'd put a 401 here. Whatever the status code needs to be. The next thing is optional is headers. So you put a object of key values here for headers.

This is gonna tell API gateway what headers I wanna send down for this request. This only works with the API proxy method that's on by default. If you opt out of the proxy method, you don't get to set the headers. You have to go into AWS API gateway and set them there.

Which is not fun. You also don't get to set the status code. You got to do it in AWS API gateway. Don't recommend doing that. You probably want control here. And then the last part, which is probably one of the most important parts is the body. The body is whatever payload you want to send back.

The only important thing to remember here is this must be stringified. Lambda's are very low level. So they're not going to do things like stringify json for you, so you have to do it yourself. So whatever you send back here has to be stringified. So I'm just gonna send back a message that says hello.

Cool, and then this, now our lambda is set up to properly respond to an HTTP based event. The next thing we need to do is actually setup that event. So what we'll do is we'll go over to the serverless yml file and I'll open this up in another tab.

>> Scott Moss: And first things first, just let's make another function here. And we'll call this one, api. And we'll say the handler. This to src/api/api.handler. By the way, you don't have to export. I notice all my exports are called handler, but you don't have to export it as handler.

You can export it wherever the hell you want to. It doesn't matter. As long as you give it the same name over here. Cuz it's that I've just been using handler in this example because I would always run into problems where I would just have the wrong name.

And this is always handler, so I'll just use handler for everything. And then if you get into using the web pack with lambda, which you can, it gets really complicated. So just for consistency, pick a name and always use that name. Otherwise, you will get lost. Although it looks cool to have all these names, just don't [LAUGH], you will mess up.

All right, cool. So now that we have that, the next thing you wanna do is you can add an events, yeah, I think it's plural, here to your API. And this allows you to pick the type of events that your lambda can subscribe to. So the events that we wanna subscribe to is gonna be http.

>> Scott Moss: So with http, what we can to do is we can use a shorthand method that says we want to do a GET request to /api. So what this is saying is that I have a function called api whose handler is that source. And it's going to subscribe to an event, the http event.

And for that event, it's going to be able to do a GET request to /api.
>> Scott Moss: So now, when someone does a request to wherever my lambda or wherever my AWS API gateway's hosted/api, it's gonna execute this handler for this function. And it's going to pass the event that AWS gateway formatted as the first argument.

And then it's gonna wait for a response or an error to be called. And then it's gonna respond back to the client.
>> Scott Moss: Does that make sense? So let's run this. Now you might think that we can just invoke this locally. Why can't we do that?
>> Speaker 2: [INAUDIBLE] get request?

>> Scott Moss: All right, say that again?
>> Speaker 2: You wanted to send in a GET request?
>> Scott Moss: Right, I didn't send in a GET request.u I just called the lambda. If I just called the lambda locally like this, invoke local -f api.
>> Scott Moss: It will just print this out. But I'm not actually testing that it's working with an API.

So the next step would be, I'll just go copy the event object from AWS and then send that in. It's like, okay, that's more of a realistic test, for sure. But you really wanna test the whole flow, so you wanna run it through API gateway. And that's where serverless offline comes in.

So you can just run sls offline start which actually I think is already in the package.json. Let me see if I put it in there. Yeah, you can just run epm run dev or if you're using yarn. You can do yarn dev and that's gonna run service offline on port 4500.

So you just run that. And you can see, it'll tell you right here couple things. One, it says, you got some routes for this function called api. And it's for a GET request, so /api. And then it's like, routes for this other function? None, you didn't tell me about them.

Routes for this other function? Nope, didn't tell me about it. Right, so now we've got some routes. So all I gotta do now is go to this URL, /api, and this should execute my lambda, so let's check it out. Okay, this one says 404 not found. Anybody knows why it's a 404?

>> Speaker 2: Set it to API?
>> Scott Moss: That's right. I didn't make a route for root. So it didn't create, it's literally only gonna route to whatever I told it to route to. And so it's not like it's setting up some magic, some defaulting. It was very explicit, it's only gonna go to what I setup.

So now if go to /api you could see I got my message. All right, so my lambda actually executed. So that's how easy it is to set up an API with lambda. And there's definitely some more things we can do in here. This right here is the shorthand method, this is basically me saying, I wanna set up a GET request to /api.

But if you wanna do more advanced things,
>> Scott Moss: You wanna set up a different path. You can say, I want /api, but then I also only want it to be a GET request, or maybe I also want it to be only a post request. So you can do that.

I wanna say GET. And this is also where you'd do something like cores true, to ensure that this core is enabled, and things like that. So there's a plethora of options you can pass through this HTTP, that we will not get into today, because that's literally a whole other course on its own.

Just look at the docs. But that's mostly how you would set up. So you would give it a route, give it a method, and then some configurable options depending on your needs of your application. Any questions on this?
>> Speaker 2: Yeah, that response looks like it also returned all of the existing routes.

>> Scott Moss: Which response, in the browser? This one?
>> Speaker 2: Your 404 response, actually.
>> Scott Moss: Did it? Let's see.
>> Scott Moss: Yeah, so it's like, cool, this will not happen in production.
>> Speaker 2: Okay.
>> Scott Moss: Okay yeah, I see what you're saying, yeah. This is just offline cuz it's a development tour, right?

They know you're running this offline. So basically, service offline is somebody went, and I'm so glad they did this cuz I would never do it, they went and looked at, they basically just broke apart AWS API gateway to see exactly how everything works. And they just tried to emulate it locally.

And I looked at the code. It's ridiculous, I don't know how or why somebody thought this is gonna be fun. But I'm glad they did it. Then they added enhancements like this, telling you, you probably meant this route. But in production, you will never see that. AWS will never put that there.

But they offer things like that. They also offer you to be like turn off authentication and simple development tools like that for local development. But yeah, you would never see this like. In fact, the error you would get in production is you just get a CloudFront error. Because, right, AWS API gateway actually goes to CloudFront the CDN which then hits the gateway, but the gateway is like, I don't have it, so then CloudFront errors out.

So we didn't even go anywhere, it won't even touch our code. It would just freak out way before it gets there.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now