Validation Overview

[00:00:00]
>> Earlier in the course was pretty cool. We walked through a bunch of stuff. One of the most exciting things I think was interacting with Prisma. Which is a really powerful tool. And then even configuring some of the authentication. Which is usually this mysterious thing unless you've done it a few times.

[00:00:17]
So I thought that was really cool, even having done that many times. Every time I build authentication I'm still just at all of the simplicity but also the effectiveness of how that works. It's really cool. And today we're just going to continue on that, we're gonna keep going.

[00:00:35]
We're gonna cool things. We're already in the rabbit hole. So let's keep digging. What we're gonna do next is we're going to talk about the route handlers. So if you remember to go back to our project right now, let me pull it up. Where am I at, here we go.

[00:00:52]
We still don't have the route handlers built out for the routes that we created, right? We have all these routes here for product update, update point but no route handlers. We gonna fill that up and is a lot. So we will be doing that. I just wanna go over some tips and different things to think about as we're building up this route handlers.

[00:01:14]
Because we know how to create the database a little bit because we did so in the users handlers here. So we'll talk about that a little bit more. And then we will also talk about how to deal with user input. Because when you are dealing with user input and any application where there is it's always gonna be dangerous.

[00:01:34]
So let's talk about that. So we head over to the site that we have been using. We have this one we are on eight, route handlers. And we are gonna talk about validating inputs. So basically, TLDR never trusts the user, okay? You ever heard of SQL Injection? Okay, that's what happens when you trust the user.

[00:02:00]
It's part of building a CRUD application, Create, Read, Update, Destroy is that you want users to be able to create things. You want them to be able to update things. And the only way that they can do that is if you allow them to give you the options on what they wanna create and what they wanna update.

[00:02:18]
So they have to provide you some type of input. And that can be dangerous because depending on how you develop your system. Typically if you develop it with a lot of assumptions as you assumed everything would go right. Your app gonna break because it will go, wrong cuz people it's not like the whole world was over your shoulder watching you build this.

[00:02:39]
To know exactly how you API works. Things are gonna go wrong even if you build the kind that the user gonna interact with. And the client understand the use of the rules of the API it will probably still go wrong. Because it just complicated. So at the end of the day, you can't really trust the user.

[00:02:54]
So just like on the front end, you might do some form validation before a user submits a form. Okay, we do the same thing on the back end for validating the input before we start interacting with the database. Because if you, for instance let's say you allowed someone to change their username.

[00:03:15]
But you didn't validate whether or not this is the right user. Okay, whose username are they changing? Anybody users, if I just have the ID of a user cannot change their username? How does that work? So this is a lot of stuff that goes into it. And you can't really trust the user So we're gonna make sure that we don't by validating our inputs.

[00:03:35]
No what HTTP methods are we gonna use that allow someone to send something up? So we know get as for getting stuff.
>> Chat says post.
>> Post for creating things, so yeah user probably sent something out. So we want the user input validation on post requests. What about any other methods in which a user might send something up?

[00:04:00]
>> A put.
>> A put exactly where they update something. So yeah we wanna validate the inputs on all of the puts and the posts. So that's what we're gonna do. So what does that look like? There's a lot of ways. There's many, many ways to validate inputs.

[00:04:16]
You don't really need a library or a framework or anything like that. I guess technically you don't really need express. But that doesn't mean you shouldn't use the [LAUGH] library or framework. Because you end up just building your own system anyway. So I've used a lot of them in the past and the one that I've landed on was this one called Express Validator.

[00:04:34]
I think it's really cool. So, what we're gonna do is we're gonna go through, find those puts those posts. And think about the different inputs that we're going to need for those requests. And then we're going to write validators for them. So that way by time the controllers actually do their job they can safely assume that the inputs are correct.

[00:04:57]
And they don't have to do that checking themselves. Which is another way. That's probably another way how you would do it. So, basically what I'm describing is if I go to router and let's say for a post request for a product, right? So we have a request, we have a response, right?

[00:05:18]
There's nothing wrong with coming in here and saying, if not req.body.name. Cuz I know a product needs a name to be created. Do something here. There's nothing wrong with that but imagine a product needed six fields for it to be created. And then you had all these other routes too.

[00:05:39]
I mean, this just gets tedious and you haven't even gotten to the part. To the actual job of the handler which is like to actually create a post down here somewhere. That is all the handler should be concerned with. Is creating that post or I am sorry creating this product in that case.

[00:05:55]
And not having to deal with this type of logic. You want to separate that out. That way it can be tested, it can be reused, it can be changed in one place. So but there's nothing wrong with this. It's just try to separate out different pieces of logic as much as you can.

[00:06:16]
It just scales better especially if you're working on a team with many people. You can have someone working on input validations and someone working on handlers, right? But if you just do it like this you're gonna run into a lot of problems. So functionally just fine but practically probably not ideal.