Check out a free preview of the full Intermediate Gatsby, v2 course:
The "Course Recap" Lesson is part of the full, Intermediate Gatsby, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Jason provides a general recap of the material covered so far in the course. A student's question regarding why Jason organized the data pull plugin as it is in the Gatsby project is also covered in this segment.

Get Unlimited Access Now

Transcript from the "Course Recap" Lesson

>> Just as a general recap before we go into deployment, and then we're gonna look at environment variables here a little bit, let's poke at what we built today. So first and foremost, we set up custom data. We were able to pull in custom data from these JSON files, we could have pulled them in from a third party API, or could use software as a service thing, could use a headless CMS, whatever.

[00:00:26] And using those and the Gatsby source nodes API, we were able to specify some relationships between them and then create nodes in the graph QL layer for each one. We were also able to use the create pages API to then go ahead and turn all of these into like here we got our books.

[00:00:47] We turned our books into pages, with some special handling, we needed some logic for the way that the slugs were done. And that let us to some customization in the data itself, we wanted to be able to create a bio-link. We wanted to be able to get the cover image from a third party service.

[00:01:07] So we use the Open Library to find those covers and then turn that into a locally optimized image by loading it in with a custom resolver. All of that led to us building out these pages. And then we dug into client only routes, were able to get those up and running, we got protected routes up and running, and we also built ourselves a theme.

[00:01:33] So with a Gatsby theme, we were able to set up this header and the nav and all that good stuff with this shared styling, and we didn't actually have to include that nav on anything. So if you look at our pages, our pages actually don't have any reference to like a layout, there's no layout here we just export this markup.

[00:01:51] But when we go to the books page, you can see that it still has this layout apply, that's the power of a theme. And we used some tools including just regular old config by overriding the site metadata which composes in themes. To set our site title and the nav items, and then we also use a technique called file shadowing.

[00:02:14] To replace the variables and change the heading color to dark blue up here, so that we were able to have a dark blue header.
>> I'm just curious, so the way you did the data pool, I've been putting it in a in a direct in a plugins directory.

[00:02:33] Did you do it differently because this is a monocyte? Or is has the convention just changed or is it could you just do it either way?
>> I mean the idea of making a custom plugin for your site to handle stuff like data pulling that's an organizational choice.

[00:02:54] If I had a really complicated. To the node, which we are kind of approaching that, right? This is a fairly complex Gatsby node file where it 150 lines. So I could pull all of this out into like a Gatsby plugin books. That would be locally installed and then I could use it and not have to look at this as part of my actual site build, it mostly comes down to your preference, right?

[00:03:22] Because there's cleanliness of having it tucked away in a plugin is nice you don't have to think about it. You don't have to look at it. If I was shipping this to lots and lots of developers, I would probably consider that because it's one less thing for somebody to get intimidated by to stumble into and accidentally break their site.

[00:03:42] The other side of it though, like the trade off here is that, that's an indirection. So by taking it out of the site setup and putting it into a separate directory, if it's not gonna be reused, you're adding a layer of indirection around the where the data is coming from.

[00:03:58] So it's ultimately a matter of preference I would say way the the use case and where it's gonna live and how many people have to look at it. Who has to maintain the data itself versus who has to just use what comes out of it? And based on the answers to those questions, I think both answers are good answers.