Intermediate Gatsby, v2


Jason Lengstorf

Jason Lengstorf

Learn With Jason
Intermediate Gatsby, v2

Check out a free preview of the full Intermediate Gatsby, v2 course

The "Introduction" 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 Lengstorf introduces the course by providing some personal background, briefly discusses Jamstack architecture, course resources, and an overview of the material that will be covered in this course. Gatsby is built on ReactJS and GraphQL, is opinionated on file structure, has a focus on faster load times, and is a great option to build static websites fast.


Transcript from the "Introduction" Lesson

>> We're gonna talk about Gatsby today and we're gonna dig into some of the more advanced use cases of it. This is something that I think it's really interesting there's so much you can do with Gatsby beyond what the initial impressions are. I think when you first look at Gatsby if you just went to the intro to Gatsby course that I did a couple days ago.

You may have kinda gotten the impression that Gatsby reserved for building static sites. It's a really good tool for that, you can load data from anywhere, you can put it up on the internet. And it all happens very fast, but Gatsby can do a lot more than that.

And today we're gonna dig into what the opportunities are, what the additional things we can do are with Gatsby that let us go more toward the app side of the spectrum. And take advantage of some of these dynamic things and do some pretty powerful stuff. So first, let's go ahead and go through just some basics, I'm gonna show a few slides here.

If you've seen the intro to Gatsby workshop, this is gonna look familiar but it's good to recap. So let's start by saying who I am, so I am Jason Lengstorf. I'm the VP of developer experience at Netlify. I'm also the host of a show called learning with Jason which runs on Twitch I pair program with people, and we learned something new together a couple times a week.

I used to be on the Gatsby team. I am now over at Netlify as I said, but while I was at Gatsby got to see a lot of cool things work with a lot of amazing people. And I'm also a booth enthusiast I really like being goofy on the internet.

I like corgis, I like boots on the nose. I like making websites about whooping corgis on the nose. It's all really just right here in my heart. So, let's start with saying what the heck is Gatsby? So, Gatsby is two things. If you start googling Gatsby, it can get a little bit confusing.

And that is because Gatsby, is the name of both an open source framework and a venture backed cloud company, right. And they are connected but they're not the same. And so that can get a little bit confusing, it can be a little hard to understand what's going on.

So for the purposes of this workshop, we are only going to talk about Gatsby the framework. We are not going to talk about Gatsby cloud. So that helps it at least in the context of this, we are going to restrict all of our discussion around the open source framework only.

None of the features that we're using today are restricted to Gatsby cloud, nothing requires you to have a Gatsby cloud account. This is all open source, you can do whatever you want with it. So what Gatsby is, it's a static site generator but as I said, it can do a little bit more than that, its primary thing is taking in data running a build step and outputting static files.

This is known as the jam stack architecture. And what that means is, you decouple your front end, because by putting them into static files you're able to ship that to a CDN it's not reliant on a server. It can be completely decoupled from any API's microservices backends that you have.

It is also then precompiled, which is that build step. And that pre compilation helps cut down on resource usage. If you know that a page is always gonna look the same no matter who looks at it. Building that page ahead of time, cuts down on the server resources required to make that available to the internet.

You have the ability to put it up on a CDN, CDNs are cheap, they're very performant, they are scalable, they're secure. It's pretty hard to take down a CDN and so in the grand scheme of things. If you've got a file that you can make static, putting it as a static file on a CDN is probably one of the easiest ways, to hit that kind of enterprise grade of uptime and availability and scale.

Gatsby is also built on react, so react is a Facebook framework that gives us a lot of ability to modify the UI quickly through pretty thoughtful API's. It's a great way to handle user interactivity, and stateful things across UI's where you can kind of have a button over here change some state over here.

Things that are getting easier with native web API's. But especially when react first came to prominence, they weren't easy it was pretty challenging. Gatsby's also all in on graphql. All-in on graphql is a data layer that allows for us to query for arbitrary nested data, you can start by looking at one object and then look at the related objects.

So if you've ever used rest, you would hit an endpoint for let's say, your blog post. So slash API slash posts. That's gonna come back with a list of blogs. And then if you have comments, it would give you an array of comment IDs. And then you would have to go and make a query for each one of those comments if you wanted to show them.

Which means that you're making tens or even hundreds of rest calls, to load one blogs worth of posts and comments. That can be really challenging. What graphql does instead is it abstracts all that away into a kind of a centralized layer, where you're able to say I want my blog and I also want all the comments, and let me get the comment author in the comment text.

And graphql will bring all that data together. And let us make one request to the graphql endpoint then that brings us back all that data. So it's, really, really good when you're dealing with loosely structured data. If you're doing data in your site, that will be related to itself, kinda spread all over the place.

Sometimes you'll need like a subsection and maybe you'll need something much broader and all over the place. Graphql is a great way to solve that. And when you're dealing with building websites, especially websites that pull in data from all around the web, which is how the jam stack works.

You might be pulling from a rest API, multiple headless services maybe you've got a headless CMS for your blog. Maybe you've got a headless E commerce system like you're using shopify to manage your products. Maybe you're pulling in comments from a third party system as well. Maybe you've got a custom back end, that has an API for some of your own data, all of that gets stitched together in the jam stack layer.

And having this graphql layer to bring those together and create relationships between them, is really powerful gives you a lot of flexibility. So that's why Gatsby went all in on it. It's a really good use case for building websites. Gatsby's also opinionated, it wants you to do things a certain way.

It's gonna give you very clear APIs, it's got a lot of things that are done for you. But in order to get those benefits, you have to be willing to work with the platform. I have watched a lot of people make themselves really sad by trying to disagree with Gatsby's opinions.

And then they'll dive into the babble configure the Web pack config to change it. And it just leads to sadness, right? So Gatsby is an opinionated tool, you get a lot for agreeing to follow the conventions that Gatsby provides. If you find yourself constantly fighting against what Gatsby does.

You may wanna consider another framework, because the benefit of an opinionated framework is what's done for you. If you are spending most of your effort, arguing with your framework, you've probably chosen the wrong framework. Gatsby is perf conscious, so one of the core benefits of Gatsby, outside of just when you build things to static files and put them on a CDN, you're automatically gonna get a perf benefit because the site loads faster.

There's less data to load, you don't have to keep servers running. So you don't have to manage data, round trips or scaling up servers, making them globally available. So you just inherently faster, Gatsby also does a bunch of things like pre loading assets in the background. It will optimize your images, it will do some baseline compression and tree shaking.

And all the things that you want it to do to make sure that your bundles are as small as they can be, that they're compressed properly, that they're only loaded when they're actually needed. But the browser is able to start pre-loading them a little bit so that they feel even faster.

And finally Gatsby's convenient, that's its biggest value prop, is that if you use Gatsby, you get to go very far very fast, because of the way that it's set up to just let you hit the ground running. It has huge ecosystem, a ton of plugins, a ton of third party sources already integrated with it.

And that means that you as a creator, don't need to argue with your framework or set up this boilerplate or build the foundational stuff. You can just build the thing you wanna build. And that makes it a great choice for if you're trying to stand up a marketing site.

If you're trying to get a blog rolling, if you wanna be a content creator and you're trying to get up and running. Don't spend all your time fine tuning your website, just start publishing just get things out there. Start that muscle of being a content creator. It's also great for agencies for that reason.

There's just a lot of reasons why Gatsby is a good like, hey, we need to move fast Gatsby who's probably a good choice. So specifically, what we're gonna cover today is a whole bunch of Gatsby's more advanced features. So if you're interested in the basics of Gatsby, how to make pages ,how to set up a project.

We're not gonna cover that today ,that's gonna be in the intro to Gatsby workshop which you can watch on the front and master site. What we're gonna cover today, is we're gonna be using a monorepo for a dev setup. So in a lot of bigger companies I've seen they use monorepos.

And especially if you're gonna start building your custom plugins, custom themes, things like that. Having a monorepos gonna make dev a whole lot easier. So we're gonna talk about how to do that and what's the benefits are. We're gonna set up custom pages. So not just building a page in the pages directory, but actually getting into the Gatsby node API's and creating pages using those node API's with custom context and all those good things.

We're gonna look at custom data types. How do you get data into the Gatsby graphql layer, and not using a source plug in. But actually building your own using the node API is dropping data in. We're gonna look at custom data relationships. So after you've created data, how can we make it possible to do the nesting and the arbitrary queries.

We're gonna look at custom resolvers. If we have some data and we wanna get a derived field, we can build right into Gatsby's graphql layer. So we're gonna look at how to do that. You can do remote image handling, if you've got that listen image that's available on say on splash or, whatever service had the images before.

You can have Gatsby pulled out locally and do optimization for you, we'll look at how to do that. We're gonna do theme development. So we're gonna build a theme that can be shared between sites, reusable code, this is really good especially if you are in the agency space or if you work with clients where you need some kind of basic boilerplate, things that are always more or less the same.

So that you don't have to do the same general setup for everyone in your clients. We're gonna look at client only route. So if you wanna build something that shouldn't be server rendered. Let's say you've got an account page or you're doing a surge where some kind of user interaction is required before you know what you're gonna display on the page.

We're going to look at that. We're also gonna look at server less functions. So when you are working with a client only site, you can do a lot but there are moments where you find yourself wanting a node server or some kind of a back end. Serverless functions are often a way to very quickly stand up that little bit of back end functionality you need, without the headache of actually standing up and scaling a server.

Building a little bit of functionality is fine, I love doing that as a dev. Building out a whole node server and figuring out how to get it into a docker container and then figuring out how to get that deployed in a way that scales means now I'm writing Kubernetes config.

There's a lot to that I don't wanna do it, I would love to never think about it again. And serverless functions make that, generally speaking, I can almost always solve my problems with a serverless function instead of having to actually stand up a whole note service. We're gonna set up protected routes.

So we're not gonna do actual authentication, we're not going to deal with usernames and passwords. But we are gonna show how if you do have someone authenticated, if you've used a service like auth 0 or you've used Netlify identity or some other thing that gives you a token or logged in status.

Will show you how to make sure the Gatsby only shows pages to people who are logged in that way. We're gonna look at deployment, how do you get this thing up on the internet? And especially when you're talking about monorepo development, there's a little bit to that. So we wanna make sure that we've got a good flow there.

We're gonna do environment variables. Environment variables are a really good way when you're working with third party services, you're gonna have public keys for how you integrate with somebody's JavaScript SDK. Or private keys so that you can get access to data that shouldn't be publicly available on the web, so that you can pull out a subset of it for display on the website.

Those workflows are little head bendy at first. So if you've never worked with environment variables, this will be a good kind of look at what Gatsby does with environment variables. And how we can make sure that only the public ones should be available to the website, and everything else should be restricted to the builds process and serverless functions

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