Serverless with AWS Lambda

Serverless Routing

Scott Moss

Scott Moss

Superfilter AI
Serverless with AWS Lambda

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

The "Serverless Routing" 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:

Scott uses the serverless framework to show the many ways to route requests from using multiple lambdas to multiple routes to using one lambda to one route.


Transcript from the "Serverless Routing" Lesson

>> Scott Moss: Now what we're gonna do is we're going to learn about different ways to handle routing in our Lambda API that we just created. So if we go back to our API, we had two functions. I mean, I made this third one while I was just talking about it, but really, we have two or three depending on what you have in your repo.

And they're all different APIs and they're all three different functions, right? And this is cool, but if you go back to how you would have created something on a server, you'd probably just have something like Express, and then Express defined what the routes were, right? Actually, I think that's a much better workflow, and I wish I could go back to something like that.

And yeah, you can, you can totally do that. So what we can do is instead is we can just have API gateway proxy to one Lambda. And then we have that one Lambda proxy to Express. And then we just have Express to find the routes and do everything internally from there.

And then that way, literally transitioning from an API that you made on Node that's Express based to Lambda that's just copy and paste. You don't have to do anything, you just copy the code from whatever you had and paste it into Lambda function and you're done. You don't have to set up anything but just a proxy.

So that's the easiest transition from going from a traditional API you might have with Express and Node to Lambda in one afternoon. So that's what we're gonna do. So a couple of things that we have to do for that to work is we need to consolidate our functions.

We have three functions here. Don't get me wrong, there are some benefits of having multiple functions, and actually, you know what? I'm gonna walk down the different paths that you can do. Let me take a step back before we transition over to using Express, let me talk about the different paths that you can take.

So one is the path that we just took, which we have three different functions that have three different HTTP routes. So it's like one for one match, for each function it's doing its own route. The next iteration we could have done is we could have had,
>> Scott Moss: Three different routes point to the same function, right?

And what I mean the same function, I mean there's actually three different Lambda functions, but they'll be the same handler, right? So if I gave all these functions the same handler, like handler was just src/api/api, and I put that here, and I put that here, they are the same handler.

Yes, I would get three separate Lambda functions, but they would all be the same code, so over here, there would always just be one file. And then inside of here I'd do some internal routing. So yeah, you could do that. And then you can do routing based on the context, you're like, what's the function name?

The function name is whatever was put here. So I can check the function name, I can check the path. So that's one way you can do it, and that might be more helpful if you would wanna do some things like analytics and you wanted to track on that level.

So it's like, cool, it's the same source function, but I've got these three Lambda separated, so I wanna be able to separate them completely so that way my metrics dashboard is separated out by functions. So I can literally just go see how long a todo's function took to execute versus the API function, even though they're the same source code, they're separate Lambda functions though.

So it might be easier to segment that way, so that's the second way. The third way is what we're gonna do is we're just gonna have one function send every request over to its source code, which we'll just use Express inside of it, and Express will do all the routing just like you normally would.

See if you have questions on that?
>> Scott Moss: Yes.
>> Student: I mean, bit that then is gonna trigger the Express function and charge you for it no matter what the address is, correct? So if you got web crawlers and trawlers, you're gonna pay for thousands of bad requests.
>> Scott Moss: Well, yeah that depends on how loose you wanna be with your proxy.

We're gonna proxy every single route, but you could proxy only the routes that you want. So yeah, you're right, it's totally up to you how you wanna do that. But yeah, you could totally have people crawl on you. But the way you get around that is, what we didn't really talk about today, is having a authorizer.

Authorizer is a Lambda function that sits in front of your Lambda functions. And then whenever somebody will hit your API gateway, API gateway is like cool, does this Lambda that you're trying to access have authorizer? Let me go talk to the authorizer first, which itself is a Lambda function, and then based on a token, a header, or IP address, or whatever, it'll authorize access to the Lambda function you really want.

And if not, you can get denied there. So that's a good place to do things like rate limiting and stuff like that. So that's how you would get around that. And then if you really wanted to get crazy with it, you could move that to the Edge and do that on the Lambda on the Edge.

So it doesn't even go anywhere near anything, it's just like right on cloud front. So it's a lot of ways you can mitigate that.

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