Intermediate Gatsby with Gatsby Themes Routing Q&A

[00:00:00]
>> Speaker 1: And a question about the way that you setup the redirect, initially. And I guess my question is, I've seen an example of client-only routes before. Where someone used the router library that's in, I think it's Reach Router.
>> Jason Lengstorf: Yeah.
>> Speaker 1: Versus what you did here where you set up a redirect thoughts about one or the other.

[00:00:26]
>> Jason Lengstorf: It's kind of a use case based thing so if you use reach router, what you're able to do is say, based on the URL that I'm seeing, show me a different component. And it's a really nice API but in this particular case, what we were actually trying to do wasn't quite the same.

[00:00:44] So we were looking at like, we wanna show the same component all the time, we're just pulling something out of the URL. And if the URL is set, then we're showing a different kind of output so there's no really like a right or wrong way, it's just a case by case basis.

[00:01:05]
>> Jason Lengstorf: Okay, so now the the FEM progress branch is pushed up to GitHub, it's done, everything that we've done today. And you should be able to step through the commits and see exactly what happened. There's also a branch on GitHub called Chichi that has links to comparisons between each step of the way so you can see the code as it evolved throughout the day.

[00:01:30] Any other questions? Anything coming from the chat?
>> Speaker 3: If the API that we are consuming requires an EMVA variable, are you going to specify them in Gatsby config? And if yes, it's not going to be shipped to the end user browser?
>> Jason Lengstorf: So if you want to use an API that needs like a secret to make calls.

[00:01:58] You would probably want to look into something like serverless functions to handle that. Because the the catch with client side request is that if you have to send a token along that token is gonna be visible. You could be sniffed out of the request, it could be snipped out of the source code.

[00:02:16] And so you probably don't want to do that, but if you use a serverless function. You are able to kind of abstract away the the sensitive part of the call. And instead you can say only this function can only be called from my domain. And so my website will make a request to that domain, which passes the call restrictions or the cross site request issues.

[00:02:44] And then it will make that authenticated request on your behalf and send back the results you need. So that's a way to protect those credentials, if you have unauthentic. Or like unsecure, like a public key that you need to pass, then yes, you would set that through Gatsby config.

[00:03:01]
>> Speaker 3: Will the same thing go for like any type of authentication?
>> Jason Lengstorf: I mean, in general, when you're looking at client side apps. Anything that shouldn't be visible to the client probably shouldn't end up in client side code. And as a general rule, if you're working with it in Gatsby, it's the build step, isn't public that doesn't create artifacts.

[00:03:25] But you wanna try to avoid putting sensitive data into any type of build artifact. So if it gets to react, if it goes into your metadata or anything like that, you wanna be pretty careful about that. It can be useful to just not set like it so as an example, we set the Cloudinary API secret in Gatsby config.

[00:03:52] Another way that you can approach that with really sensitive stuff is you can say it needs to be available in the environment. But it never actually gets set in the config the code will just expect that, that environment variable is set. And that would avoid it getting any potential for a leakage or things like that so if you want to be really sure.

[00:04:11] You can just make sure that it doesn't gets set in any of the configured or use anywhere other than exactly what's needed.
>> Speaker 3: So how about authenticated templates versus unauthenticated?
>> Jason Lengstorf: So authenticated templates, as a general rule, my recommendation is don't pre-build any data that shouldn't be publicly available.

[00:04:37] So what that means is if you have a user dashboard. And that's got any kind of sensitive data on it, You don't wanna build that ahead of time. You don't wanna put that into Gatsby's pipeline at all because any kind of static asset can be compromised. And it's just easier to not try to play that game so what's easier to do is to have someone login within an OAuth workflow.

[00:05:04] And then only send back that data if they have a valid token and just do it all on the client side asynchronously.
>> Speaker 4: Actually i have a question.
>> Jason Lengstorf: Yeah, sure.
>> Speaker 4: Regarding the server side redirecting.
>> Jason Lengstorf: Yeah.
>> Speaker 4: You had nullified here, but what if you were using something like AWSS3?

[00:05:25]
>> Jason Lengstorf: You can set it up, I've done it and what did I use, Route 53, I think, is that right? There is a way to do it, I cannot remember off the top of my head what it is but you set up the same sort of redirect. But I don't remember which part of the AWS suite of services actually handled it.

[00:05:51] But if you were using, like if you're deploying to DigitalOcean. Or another kind of container based service, you would use Apache or NGINX to set up these routes. Managed services like Nullify tend to have configuration based redirects. So anywhere where you're gonna deploy it most likely you'll be able to make it happen.

[00:06:09] It's just a matter of what your particular flavor of deployment requires for redirects.
>> Speaker 4: I guess my question, thank you for the answer, it's entirely obvious to me now that you said it right, you have to do the server side configuration for that. But a lot of servers will just like if it doesn't recognize the path, right, it returns index dot whatever like that HTML.

[00:06:36]
>> Jason Lengstorf: All right.
>> Speaker 4: Is there a Gatsby config you can use in that scenarios, you know what, when?
>> Jason Lengstorf: Well, so the thing is with routes like that, you'll never get to Gatsby so if Gatsby is only set up for like slash surge. Then the only thing that exists in the file system is a folder/search index.html.

[00:07:01] So the server itself needs to handle that redirect because otherwise, like Gatsby, we would have to declare every possible route. And every possible combination of characters to manage that. And it's, I mean, that's obviously gonna be very not feasible. If you're using serverless, you don't have to stand up a Digital Ocean box with a NGINX proxy.

[00:07:26] That wraps your node server that serves your static assets, those sorts of problems just kind of disappear, right? And that doesn't mean they go away, they're now on somebody else's computer and not yours. But the services are becoming very stable and reliable and affordable which means that for us as front end developers.

[00:07:45] We just get to hand off a huge number of our problems. And trust that someone who is probably better at back end than we are is doing it in the best way they know how. So there are always trade offs with this but to me it's really exciting because again.

[00:08:01] The same way that Gatsby takes all this boiler plate out of the front end, the jam stack, the serverless. And the infrastructure as a service stuff that's out there is removing the need for a whole bunch of boiler plate on the back end as well. And that gives us just, I mean, we can get complete parity with what you used to have to build.

[00:08:21] A full fledged server and API 4 with a couple lines of JavaScript and a serverless function now.
>> Speaker 4: TypeScript support, just Gatsby'll do it out of the box. Is there a configuration that-
>> Jason Lengstorf: There's a plugin and it's called Gatsby plugin TypeScript. That should add support, like with one line of config.

[00:08:41] I'm not a TypeScript developer, so I'm not sure to be completely honest.