Serverless with AWS Lambda Your First Lambda Solution
Transcript from the "Your First Lambda Solution" Lesson
>> Scott Moss: All right, so did everyone gets a chance to create a local lambda and invoke it locally? Did anyone do anything extra? Nice, what did you do?
>> Speaker 2: I deployed [CROSSTALK]
>> Scott Moss: Snap. There you go. Okay, what about anybody else? Anybody else deploy? You deployed too, nice. Anybody tried to create multiple lambdas to do different things, different events maybe?
[00:00:24] Maybe looked ahead, looked at some docs. Checked out a different solution brand, something like that? No? All right, cool. So let's just hop right in, and I'll just create some lambdas here. So basically he first thing you would have done is you would have come into functions, or I'm sorry, the serverless yaml file.
[00:00:41] Made a functions property here. And then you would've given your function a name. I'm just gonna call it helloworld. And then basically you would do, is you would give it a handler. And that handler is, the handler's gonna be the path to the file, right? So this file is in source.
[00:01:02] So you can't just type in the name of file, you gotta give the full path, so in this case src/hander. And then, I'm sorry, not handler but helloworld is the name of the file,
>> Scott Moss: And then this is the handler, so .handler. And then now you can come in here and we can just say done(null, 'hello').
[00:01:33] And once we've got that, we can just run it. So we can say sls invoke.
>> Scott Moss: Local -f and then the name of the file. I'm sorry, the name of the function, which is whatever name you gave it here, so helloworld. So invoke,
>> Scott Moss: Local -f and then helloworld.
>> Scott Moss: There we go, so then you'll get that message. Anybody try to put an error in here and see what happens if you do that? No, nobody tried that, what? That's fine. All right, so I'll put an error here.
>> Scott Moss: Let's see what happens.
>> Scott Moss: Boom, it sends you back an error.
[00:02:27] Now, this is just what happens locally. Depending on how you execute it and what you're functions doing on AWS, it won't look like this. In fact, debugging lambda functions is the most difficult thing when they're deployed. At least in my experience, it can be difficult. And we'll talk about different things you'll have to do once you deploy to make that a little easier.
[00:02:49] But it's still pretty hard. I mean, there's not much you can do, unless you want to write another lambda that goes into the container of another lambda, looks at it while it's running. There's so many things you can do, but it's very difficult. Okay, cool. Any questions on helloworld?
[00:03:08] Getting a lambda out there? I know there was some questions earlier about event, context. Any specific ones I didn't answer about how that event works? Maybe I wasn't clear, or there was something there. Does everyone understand how this event works? As far as up to the point would have described.
[00:03:25] You might not understand AWS, but as far as how to describe. So just a walkthrough again, we can pass an event from a file using the -p flag and it will pass the event to it. I'm not doing anything with it right now, so it's airing out, but if I were to just pass that event, just echo, like this.
>> Scott Moss: That's the event that's in the file. So the file is the payload which is also the event, and that's just because I'm invoking it locally, but this same lambda function might also be used in another event. And therefore it would have a different context, different everything, so it might not look the same, but I'm just evoking it locally and I'm forcing the event to be whatever I wanted to be.
[00:04:12] So therefore it is that way. But in production, it probably won't be this way. So sls invoke local is a really great tool to use. I use it for just seeing if my lambda is running. But in actuality, unless you are writing a raw lambda, like it's just completely raw, you always give it an input.
[00:04:35] Most of time running sls invoke local doesn't work. And you'll see why. And it's mostly because these lambda' are kind of responding to different events that are real events. So the only way to get them to work locally, to test them out, is if you basically go to AWS, get a copy of the event, paste it into your file and then you test it with that, which is pretty reliable.
[00:04:56] But then sometimes what you would do in that lambda relies on services on AWS that you don't wanna be doing inside of a CI. Or you don't wanna be doing on your machine, so it's really hard to test. Sls invoke local is cool just to make sure nothing's breaking, but it's not like a production dry run.
[00:05:15] I wouldn't do it this way, I would run it on AWS there to see if it's good. Does that make sense?