Serverless with AWS Lambda Lambdas on Express Solution and Q&A
Transcript from the "Lambdas on Express Solution and Q&A" Lesson
>> Scott Moss: Was everyone able to convert over their app using Express? Pretty simple, right? So again, if you're thinking about using Serverless in Lambda and you have an Express app, and your manager is telling you that you can't do it because it's gonna take forever. Then you can just do that this weekend.
[00:00:19] And say, look I already did it. And then it can't say anything. And then you just show them the numbers of how much money they're gonna be saving. And they're gonna be like. But then you try to connect to the database and you're like, actually, we can't do it.
[00:00:28] [LAUGH] If anyone wants to talk about connecting databases in Lambda, we can definitely do that after this next module cuz, yeah, good luck. Were there any questions about that? Did anybody notice any patterns? Was there anything different using Express on Lambda than you might have experienced using Express on a traditional server?
[00:00:50] And if so, what were those differences that you might have examined?
>> Scott Moss: Nothing there? And, yeah?
>> Speaker 2: Well, I mean, I guess an immediate question that comes to mind that I didn't experience, but I definitely thought about while we were on break was using Express as a server naturally leads to all kinds of questions that you have with an Express server.
>> Scott Moss: Right.
>> Speaker 2: What kind of Middleware am I gonna use to manage flow?
>> Scott Moss: Right.
>> Speaker 2: What resources is my Express server gonna use for authentication and logging and all that kind of stuff?
>> Scott Moss: Mm-hm.
>> Speaker 2: Is that all manageable in the AWS environment or no?
>> Scott Moss: Yeah, and this is kind of what I was saying with the question in the chatroom is it's so nice to have Express on Lamba.
[00:01:38] But then you get caught of thinking about what you would do in a traditional Express server, which is on a server, which is all of that stuff. But in reality you probably wouldn't do authorization on that Express server. You'd have another Lambda for that. Or your Middleware would be very basic because most of the Middleware you're doing could probably offload it to another Lambda.
[00:01:59] So there's a lot of things you would, the way I would like to think about is just think of Express as just the routing, and forget everything else you did. Because yes, you can do everything you just described, but at the end of the day you just have a huge Express app on a Lambda function.
[00:02:14] And it's like what benefit are you getting from that? And it's probably going to be worse, because it's probably slower most likely. Depending on where your setup was. And you're not taking advantage of anything else that a Lambda could offer you. So you might be saving money, maybe.
[00:02:27] Maybe you'll save some money, but that's about it.
>> Speaker 2: I guess a follow up question to that was, I wonder if anyone, I mean basically by using Express you are putting in a lot of baggage in the node modules that Webpack is just gonna remove anyway. I wonder if there are already exist library out there that's just basically just, [CROSSTALK] Routing?
>> Scott Moss: Just the routing. Yeah, tons of them. There's at least a hundred of them. You can just type in, I mean, there are so many of them like node, [CROSSTALK] I should be using that instead of Express. Yeah, I think the Express one is literally just a transitioning over.
[00:03:04] It's like, cool, how do we get from here to here? All right, boom, place it in. Now, let's start taking things out and making it more lightweight, and that's kinda the approach I would take. Type in node routing and the first thing that comes up is Express.
>> Speaker 2: [LAUGH]
>> Scott Moss: SEO is strong. But yeah, there's tons of routers. Or you could've went down the path that I was saying where you just make your own hash table, state machine and do it yourself. But yeah, there's tons of them out there. Are there any other questions with Express and Serverless and how those things combine together?
[00:03:38] Everybody understands how that works? It's not a long live server, even though you have Express. It's still just a Lambda function. All right? Okay, cool. Next thing we're gonna do is we're gonna talk about testing. But I did wanna talk about, I think it's a good opportunity to talk about some gotchas in here.
[00:03:59] Or something that are, somethings you just wouldn't really know unless you just kinda like mess like Express. I'm sorry, Serverless profile. So let me check out to lesson-3-solution. This just has my test on it.
>> Scott Moss: Okay, okay, I'm fine with that.
>> Scott Moss: My God.
>> Scott Moss: Okay. So, a couple of things to note here is that,
>> Scott Moss: Looks like my solution's like, yeah, I broke it out. Okay, cool. A couple things to note here is just for my solution what I decided to do was kind of like what I would do in a traditional app whereas I wouldn't, if I make an Express app I don't start the Express server in the same file that I create the Express server.
[00:04:58] And that's because I want to be able to export that app instance from Express and test it without starting a server. So I always start the server in another file. So that's kinda what I did here when I started the server. So I create the Express out here.
[00:05:09] I export it and then in another file I actually require and do the thing. And that allows me to be a little test everything in this file without having to interact with all the business logic here. So that's kind of the solution I did. And that's just like having this testable code.
[00:05:26] Eventually you break all the stuff out into all different other types of things, but that's just the approach I took. But the things I wanted to talk about were understanding things like closures, and caching, and that stuff inside of Lambda cuz they actually do have effects, side effects.
[00:05:47] So this function right here, this is our handler. This is the actual Lambda function that's going to be invoked, this is the entry. Whatever state you declare out here while the container is still used and the Lambda is still hot it's basically cache, it's closure. So you could have side effects in here.
[00:06:06] So this can be useful and this can also be dangerous. This is useful for things like databases where you would cache a database connection so it's not always reconnecting. And this kind of how you get around this software databases. But it can also be dangerous if you declare some object out here and you're mutating the object somewhere in this function on every single request, and you're having these bugs where everybody is getting different values.
[00:06:27] And you're like, I don't know what's going on. Also, cuz you're mutating this object in a closer inside of this Lambda. So you gotta remember that cuz the container has the same memory. It's the same container. So if you keep it here it's gonna hold a reference to it.
[00:06:41] So that can be used in your advantage. It could also be used to your disadvantage. So just be wary of that. We really ran into that problem so many times. And then when I ran to the problem of how do I keep it dated it's connection over open, I realized it like I could just do that thing that got me stuck like a week ago.
[00:06:59] So, [LAUGH] that's how that worked out. Any questions on that, this might not understand what I mean but I like the closures and mutations basically, I just walk through it. But If I had this function here,
>> Scott Moss: And I had an object says state,
>> Scott Moss: And if I came in here and was just like state.name =,
>> Scott Moss: Right, I'm changing the state up here. It's in a closure. So as long as its container is still open this is the same state, it's the same object. So I'm mutating that state and I could possibly have side effects. All right, so you gotta be careful of that.
[00:07:49] So if you are keeping state outside of your handlers for better or for worse, and you don't intend to have side effects just make sure you keep everything stateless and mutable. So instead of doing that you might do something like,
>> Scott Moss: And then now you just made a new object based off of that, you put a name there.
[00:08:15] So it's immutable now. So just be wary of that. [LAUGH] It will bite you and you would not know what's going on, cuz it just will not tell you. And if you have a frame or Express you won't even know where the closure is. You would be like, I don't even know where the handler starts or where the closure ends.
[00:08:32] You just won't even know what's going on. So just be careful with that. My advice is just put everything in a function. Put everything in a function, you're fine. You would never have this problem cuz these functions do not reach out and create closures. Just put everything in a function.
[00:08:46] Closures are not good for Lambda unless you absolutely need to. Does that make sense?
>> Scott Moss: Cool. What else did I want to talk about before I get to testing?
>> Scott Moss: I think that's it. Most of the other stuff is really advanced. Any other questions? Specific things so far?
[00:09:09] I mean so far what you've learned about Lambda is basically all you need to know about deploying Lambdas. You all could just deploy Lambdas on AWS right now and you'd be totally well equipped to do it. You will run into problems if things go sideways for sure, as we all do.
[00:09:24] But you are more than well equipped to go deploy some Lambdas, so congratulations. If I had a certificate and a printer I'd print some out. I don't have that. [LAUGH] So, [LAUGH]