Server-Side GraphQL in Next.js

Authentication Schema

Scott Moss

Scott Moss

Superfilter AI
Server-Side GraphQL in Next.js

Check out a free preview of the full Server-Side GraphQL in Next.js course

The "Authentication Schema" Lesson is part of the full, Server-Side GraphQL in Next.js course featured in this preview video. Here's what you'd learn in this lesson:

Scott discusses the necessary components for authentication, such as the user type, query to get the user, and input for signing in. He mentions the importance of not including sensitive information, like passwords, in the GraphQL schema. He also provides examples of how to define the user type, auth input, and mutations for signing in.


Transcript from the "Authentication Schema" Lesson

>> Scott Moss: All right, now it's time to get real though. So we have that, now we actually need to make the schema, put the stuff in it. And I'm gonna pull up like the database schema, we'll look at the tables and it will try to figure out how we need to make the object types and what queries need to make and things like that.

Now that we have our server, we need to actually build the things for the authentication. We're gonna need a user type, we're gonna need a query to get the user, we're gonna need some inputs in order to fulfill the form in which you sign in and sign up.

Luckily for us, they take the same thing, they both take an email, they both take a password. So we're gonna need that in our schema, and then we're also going to need to resolve those things. So we need to resolve the user, we need to be able to sign in, we need to be able to sign up, which is called Create user, so we're gonna do those two things.

So let's get to it. Let's go to our schema first.
>> Scott Moss: Here we go, I'm gonna get rid of the me one, or at least for now, just get rid of that. And then let's make our type user. So what actually goes on a user? I mean, there's no wrong answer here.

You could even probably guess from the off input type. But if you go look in the repo, there should be another schema file, not the one you're writing in, but another one for the database. If you go and look at that, you can kinda see there is a users table here.

You don't really need to know this tool to understand what fields there are. As you can see, there's an ID field, there's a createdAt field, there's an email field, and there's a password field. Now looking at all these four fields, which fields do you think would make sense to go on the GraphQL schema version of the user?

And which ones would not make sense to go on the GraphQL schema with the user? Right, think about that. And the reason I'm asking is because not all fields from your database are gonna map to your schema. Because you probably should not be sending down someone's password [LAUGH] from an API request.

So maybe don't put that on the graphical schema. There's no point to send your password. There might be one example I can think of where you would wanna do that. And that would be in a setting somewhere, if someone wanted to change their password, but you somehow wanted to show them their current password.

Which I've never really seen is usually like you give me your current password and then I'll let you change your password. It's usually not like yeah, here's your current password if you wanna look at it. I've never really seen that, but that is like the only example I can think of why you would wanna put someone's password on there.

And that's assuming it's even in plain text, which I hope it's not. Lot of security issues there, so no, it's not always gonna be one for one. And even then maybe you don't wanna call it email inside of GraphQL. Maybe you wanna call it email address, so you can rename that field.

So it's not always a one for one. Maybe you wanted to format the createdAt before you give it to the user, so that field is something different. So what we're gonna do is in our schema, is we're just gonna say we have an ID, its type is ID, it's always gonna be there.

We're gonna have a type email, that's a type string, it's always gonna be there. If you want it to get really strict with this you can go make a custom scalar type that does a regex to make sure this is an email. So you can validate that email on the GraphQL level to make sure it's a valid email address.

Have ChatGPT make you an email regex and go make a custom scaler type that defines the email type. In fact, you know what, if I just get on npm right now, I guarantee you, npm graphql email type, I guarantee it's done.
>> Scott Moss: Here we go, somebody already has one.

This was this was six years ago we're so behind. They already have a GraphQL type date, they use this GraphQL type object syntax. This was really hot back in the day, I don't know if people still do it this way. But they have a scalar called email and then look, you can just set it to email.

And I guarantee if I looked at this code it's just gonna be a regex on an email, there it is that is, the nastiest regex I've ever seen in my life.
>> Male Speaker 1: [LAUGH]
>> Scott Moss: So [LAUGH] that's the regex on the email and it's just checking to see if it's an email, right?

And if we go look at the actual GraphQL implementation of it, yeah, this is actually mostly the same. You have to serialize it, you have to parse it, and you have to like parse it literally, this is actually still the same way you do it, so it's quite simple.

But yeah, you can do that if you want. You can get pretty granular with this stuff, but we're not gonna do that. That's just too much work right now. So let's go back to our code, we got our email and then we also have createdAt you could add that.

I'm not using it in the app, so I'm not going to add it, but you know what, I'll just add it. Maybe we won't use it, but I'll just say it's type string.
>> Scott Moss: This might throw an error if the database throws a different type for the createdAt, I think this is a string, we'll have to see.

Yeah, I mean SQLite only has strings, integers and blobs. They don't have anything else, they don't even have booleans. So I think that'll be a string. If not, we can coerce it with a resolver, it's totally fine. So we have our user and then we go back to my notes.

>> Scott Moss: We need to make our AuthInput, so let's do that. I'm gonna say AuthInput. You have to give me an email, that's a string, you have to give me a password, that's a string. It's the only way you can authenticate, okay?
>> Scott Moss: Then for the query, I'm gonna put me, it's gonna return the current user.

And then I need to make some mutations. I need to make sign in. Which is gonna take input of type, Authinput required,
>> Scott Moss: And it's gonna return User. User also is gonna need a token here I just realized that.
>> Scott Moss: So I'm gonna say token or does that make that?

Yeah, it's not required, you're not always gonna have it. So these needs to be a user here.
>> Scott Moss: And then for a sign up, I just call it createUser. That's also gonna take the same input of AuthInput, that is required. And it's also gonna return a User here.

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