Transcript from the "Plugins and Dynamic Data Q&A" Lesson
>> Student: Prefetch is a webpack thing that Gatsby is just configuring for you.
>> Jason Lengstorf: Prefetch is a browser thing actually. So it's a built-in, what's it called? I know this, you can do a prefetch, a preload, preconnect and a few others. And each of these are, they're hints. So they tell the browser, hey, I'm going to load this page next, or I'm going to need this resource soon.
[00:00:29] And in doing that the browser is able to kinda make calls, but they're all done with really low priority. So if you've got Data Saver turned on It won't try, if you are trying to download something else, it will put that thing in the bottom of the stack instead of blocking your images or something you need for the current page.
[00:00:47] So, yeah, it's built-in browser technology on modern browsers, I believe it's supported in like Edge, Firefox, Chrome, all the modern browsers. So it should be and in it like fail silently and browsers don't support it. So there's no harm in putting it in. This will work on any technology.
[00:01:07] But again it's nice to just have it done for. [LAUGH] Any other questions? Go ahead.
>> Student2: Can you explain the how the GraphQL scheming gets generated and whenever we install a new Gatsby plugin, is it possible to modify the schema?
>> Jason Lengstorf: It is, yes and yes. So the way that the schema is generated, let's see what would be an easy example for this.
[00:01:35] So if I just go to the Gatsby node APIs, we have,
>> Jason Lengstorf: Source nodes here. And so, what's source nodes will do is, the APIs, like the source plugin is basically you're gonna say like, hey, Instagram give me posts. And then the posts are gonna come back and they ultimately end up in some kinda of JSON-like data structure.
[00:02:04] There's a couple things that you have to add, you need a node ID, you need to set a parent and children, and a couple of these things. It needs a type and a content digest and I think the rest of it is optional. And then you can use this create node action to put that into our GraphQL layer.
[00:02:27] So when you create a my node type, this is going to tell Gatsby that we need to have my node type query. And then all my node type query where you're able to query for whatever is in here. In this case, you would have the key, foo and bar.
[00:02:44] That is the kind of very, very quick version of how that works. You're also able to listen for like they're a bunch of different API s in here, all of which enabled different things. So you can create pages, we're able to create resolvers, you can look for when a different data node is created and extended, that's a pretty powerful thing to do.
[00:03:10] This is how, for example, like the sharp transformer is gonna look for any file nodes to get created and then determine whether or not there are images and if so do more stuff to them. There is a whole workshop's worth of material on how to build source plugins and manipulate data, so I'm not gonna be able to go super deep on that.
[00:03:32] But the short answer is if you dig through this page and then look at existing source plugins, you can see how they're using these different APIs to do all of those different things to get data into Gatsby's GraphQL layer. If you want to customize that schema, you're able to use our new schema customization API, which is only a couple months old here.
[00:04:00] And this will allow you to straight up define a thing. If you want to say, I'm gonna have an author type and I want that to be mapped to this data and throw it in, you can do anything. It can be completely custom, you could like one way that we're looking at this is really exciting to us is if you wanted to you could define a generic blog type.
[00:04:30] And then you could write a series of resolvers that would say map a WordPress blog to the generic blog type. Or like Drupal or markdown all to generic blog types, which means that you would write your posts like your Gatsby sites using a generic type, the blog type.
[00:04:50] So if you were to start in markdown, and then your site grows up and it scales and you hire people. And they don't know how to write markdown, they want to use some kind of a CMS, if you map that CMS to the generic blog type, you don't have to change any of the code in your site, because the queries are all against the generic type.
[00:05:08] And that means that the code is completely portable, even if you totally change the back end. So that type of stuff is starting to come down the pipeline, we're starting to play with ideas and proofs of concept on that. If you want to ping me on Twitter or send me an email or something, I will happily send you a ton of examples.
[00:05:29] But we don't have time for it now.
>> Student2: Is there a story for card screens or any kind of dynamically generated data?
>> Jason Lengstorf: Yeah, we have, like for dynamic apps you mean?
>> Student2: Yeah, I mean like an admin interface would have the database returning stuff.
>> Jason Lengstorf: Sure, yeah, so there are handful of sites that have done this.
[00:05:57] I'm trying to think of one that's a good example. So Like our our Swag Store is using dynamic data. We've also seen a couple people build dashboards with Gatsby. Gatsby itself has a dashboard that's built in Gatsby. But the way that that works is anything that you can build at build time, we encourage you to do so.
[00:06:16] If you can get that data and you know that the data changes relatively and frequently, grab it ahead of time, stick it into a page and you're good to go. If you've got something that is hard to build ahead of time or that you shouldn't build ahead of time like user data, then instead you would want to do that asynchronously.
[00:06:33] And we have dynamic routing. So Gatsby, what is it dynamic routes, you are able to set up a what we would call like a hybrid app or like a client only app where you can say hey, anything that's under the app directory. Just treat that like a regular react app, don't try to do any serve side rendering or anything.
[00:07:03] And for client side stuff like a loading user data or whatever, that's a completely reasonable way to approach that problem. Because you wouldn't be, you wouldn't wanna build out like all that user data in the static files, anyways, it's a kind of security problem. So that's one way to solve that, another way we've seen that solved is you can wrap your entire Gatsby app with a provider for Apollo, or for Axios if you wanted to rest calls.
[00:07:33] However you decide that makes the most sense. And you're able to kind of use static data where you've got it and make dynamic calls where you needed. If you use either in class base components, you would use like componentDidMount or in React Hooks, you would use use effect.
[00:07:50] You're able to say like dynamic staff happens in this component. But because componentDidMount and use effect don't fire during a server side rendering phase, they just get ignored during server side rendering which means that the component would render in its loading state or in its empty state. And once it rehydrates into React that would just repopulate with whatever the dynamic content was.
[00:08:14] So that's kind of, that's the way that you would approach that problem in a completely static world. You could also, there's nothing stopping you from building most of your site as a Gatsby app, and then having some server driven routes if it was really highly sensitive like a stock ticker.
[00:08:32] Probably wouldn't make a ton of sense to be built in Gatsby. But you could have a component that's just completely dynamic that receives the new stock data in real time. Or if you wanted to have a whole page dedicated to that, you could just build a server side rendered page and is only for the stock picker.
[00:08:52] My preference is to try to avoid standing up servers whenever I don't have to. So I like the idea of just rendering it in the client when it's when it's client only data. Your mileage may vary, it's going to depend on use case.