Next.js & Course Project Q&A

[00:00:00]
>> Scott Moss: Now that's hooked up, we are ready to make GraphQL queries and mutations and all those things. Any questions on this?
>> Scott Moss: No, pretty sure? Yes, Mark.
>> Mark: Well, there's a few Next.js questions like why are there parentheses around the dashboard directories?
>> Scott Moss: These? Boy, okay. So if you wanna learn more about Next.js, highly recommend taking the Next.js as courses we have in front of masters, I cover a lot of this stuff.

[00:00:33]
And then also in the upcoming one with intermediate Next.js that we'll be teaching later. But in short, these parentheses are, so a folder in App.js is a route, okay? So if I have API, now I have my URL slash API. If I have a folder called AUTH, it'll be my URL slash AUTH.

[00:00:55]
But if I put parentheses around it, it doesn't add a route segment. So now, by having parentheses around it, there's no such thing as slash off. So why would I add this folder here? The only reason you would add a folder of a parentheses and Next.js app directory, is because there's more than one route in there and you need them to share a layout, but you don't want to create a new URL segment.

[00:01:17]
So in this case, I want to be able to go to slash sign in and slash sign up, and they share the exact same layout. And I don't want it to be slash AUTH slash sign up or slash AUTH slash sign in, which is gross, so I put parentheses around AUTH so it doesn't get included in the URL, but I can still give them a common layout.

[00:01:38]
That is the only reason, yes.
>> Mark: Are the assumptions about our understanding of SSR, server components and caching and next relevant for this course, or are we skipping that stuff on purpose?
>> Scott Moss: We are 100% skipping that stuff on purpose. We are in client land only. We're doing full client react SSR, and server components has nothing to do with any of this.

[00:02:02]
I think server components completely breaks people's mental models on how you actually get data. I looked at the documentation on like Urkel and Apollo and a lot of them are like, this is how you do GraphQL queries with server components. But I still can't reconcile why you would ever do it in the first place, when you can just go straight to the database.

[00:02:20]
Why would you even make a network requests, leave the network, come back into the same network just to get the data when you're already there? If you want the type safety, I get it, but you can just make a database request. It makes sense if your GraphQL API was on a third party, hosted somewhere else, obviously you have to do that.

[00:02:36]
But in our example, it doesn't make sense. So I still think there's a lot of patterns there and I don't wanna push my strong opinions yet, but also it is just quite confusing if you've never dealt with server components. And then SSR, that's just a hard topic to understand.

[00:02:53]
They make it seem so easy, but I don't think anyone really understands what's actually happening on SSR, so yeah, we're just avoiding all of that, and we're just gonna do straight up client side react. But choosing Next.js because if you go to the React documentation or getting started, the very first thing they say is Donald Next.js.

[00:03:12]
So that's what we're doing Next.js because react recommends you use Next.js for react.
>> Mark: The handle sign in function doesn't have a type? When do you use types versus not?
>> Scott Moss: That's a great question. When do I use types versus not? I'm not the right person to ask because I don't like using types at all.

[00:03:31]
I want them done for me, but I don't wanna do them. So, [LAUGH] [COUGH] I just want them done. So really, my number one use case for GPT is types. So I'll just go and like GPT fig types do the types cuz I don't wanna make them because it seems like a waste of time, but man, when they're there, they're so nice.

[00:03:50]
So yeah, you'll see me not doing types in some places, but then in some other places I'll do the types. So there's no wrong answer or types cuz they are always optional. You can ignore them. So I guess the question is always do the types, but sometimes doing the types ain't fun.

[00:04:07]
So, there it is.
>> Mark: Assuming a microservice architecture, what would be the advantage of having a GraphQL layer instead of just calling the microservice API directly from the Next.js app?
>> Scott Moss: Assuming a microservice architecture, what would be the benefit of having GraphQL versus just calling the microservices from the API?

[00:04:31]
A lot of the benefits would be obvious when you do server side GraphQL. So, if you had a SLA, a microservice oriented architecture, then that means you have smaller services, like instead of having like a route that handles water resource, you might have a whole service, a whole API on its own that handles a specific resource.

[00:04:59]
It might even have its own database. GraphQL is helpful in that regard, because each one of those servers has their own protocol on how you retrieve data. They could be using GraphQL. They could be using REST. The types that come back are different. How you authenticate might be different, depends on how you set it up.

[00:05:15]
GraphQL will orchestrate all of that into one schema. So you'll just have one main schema, that is aware of all the micro services and the types of data they return. So when you're on the front end and you're writing code, or if you're just any client querying that API, you won't even know that when you're asking for a user and you're asking for the user's settings and then their profile that that's coming from three different microservices, because GraphQL can combine them all into one schema.

[00:05:47]
So when you make your query, you're getting back that data and all you have to do is make one query on the front end, but on the back end, the way it's resolved, we'll be talking to all those microservices. So it's really great for abstracting a way all the different microservices you might have into a trusted-typed schema in which it is completely abstracted away from the person on the front end.

[00:06:09]
They don't know, this one field on this query can come from Stripe, this other field next to it can come from another microservice. This field over here could come directly from this database. And the person on the front end has no idea. So in that regard, it's quite useful, because, yeah, GraphQL doesn't care where your data comes from.

[00:06:31]
Yes.
>> Mark: How did you set the headers in the next config for access control? How do you debug it to get the state from the default settings?
>> Scott Moss: What was the question again?
>> Mark: Setting the AUTH headers in the config, The AUTH headers.
>> Scott Moss: These are just cores so they're specifically talking about the next config.

[00:06:56]
This is course, this is me basically setting up Cross-Origin Resource Sharing. You don't really need this for this course. The reason I added this is because that Star Wars API that we were using, you can actually put whatever URL you want in there, you can put your localhost URL in there, and you can explore it, but only if your API has CORS enabled.

[00:07:19]
So I enabled Cores so I can load it up in another app, but since then I actually figured out how to embed that into our app, so we don't need to do that, and that's what I was gonna show next. But yeah, this is Cores, it's not authorization, Cores is basically something a browser would do.

[00:07:35]
It's called a preflight check, so before you make a request to a server, something like a browser will go check that server with an options request to like, hey, this client is trying to send you a request, what do you allow? And the server has to respond back with these headers, these are the things that I allow.

[00:07:51]
I allow these things. I allow these things. So any origin, I allow these methods and these headers and then the browser we get that back and be like, okay, cool. Based on what the client is asking and what the server allows, I'll allow it, here's your request. So sometimes if you go in your browser, you'll see two requests for every one request you do, and that first one is always like, it says options.

[00:08:14]
That's what this is. This is the server allowing that to happen. In production, unless you have an API that developers are consuming, if it's just like some internal API, you probably don't wanna have chorus, you probably wanna limit it to just the URL in which your client is coming from.

[00:08:32]
But obviously, if you have mobile or something like that, that's not gonna work.