Static Sites with Gatsby

Jon: Hey, everyone. Welcome to Even Keeled episode three, building static sites with Gatsby. I'm your host, Jon Kinney, and today we'll be talking with two more folks from the Headway development team, Jacob Hebert and Matt McGee. Welcome to Even Keeled. Jake and Matt, can you both give us a quick intro about your development backgrounds?

Jake: Yeah, this is Jake. I was originally a pure Ruby developer working on a few micro-service based projects. Over the last few years I’ve been investing in web UI development, especially in React, and here at Headway working in static sites with Gatsby has sort of been my specialty, and I’ve had the opportunity this year to work on and launch a few different Gatsby sites for a couple of different clients.

Matt: And Yeah, I'm Matt and I'm a full stack developer here at headway. Kind of a similar background to Jake. Started in the Rails world at some startups and here at Headway, been doing quite a few other things have done some Rails. I've done some Gatsby, some front end stuff with React as well. So just kind of a fitting in where I can.

Jon: Awesome. Thanks guys. Well, glad to have you on the show today. We're excited to dig into a little bit about building static sites with Gatsby. Jake, we recently launched a relatively large static site using Gatsby for one of our clients. You were a big part of that successful launch, but it's been a few months now since we've launched that, how are things going? Are you still enjoying working with Gatsby each week?

Jake: Yeah, I am. It was a blast to be able to go through and really build, such a large site. You know, we've got a couple of hundred pages the site close to a thousand assets that are being loaded. So it's, it's really, kind of something different than what might normally see with the lightweight Gatsby site and it was really enjoyable to go through that process and figure out how to optimize for something that large. And what's really been enjoyable is entering into this maintenance cycle and getting to interact with the marketing team, help them learn the stack and you know, just  see them understand the power of Gatsby and how to get everything tied together. It's been cool to walk with them through that process.

Jon: Yeah, that's great. love how approachable Gatsby can be. And it seems like they've got a really good community really good documentation. Have you found their, homepage to be pretty legitimate?

Jake: Yeah, absolutely. Whenever any of my questions are actually with Gatsby, that's always the first place I go because the docs are great. I think that they're just about on par with the React docs which are, in my opinion, kind of, a gold standard for documentation. And one of the great things about the Gatsby docs is that the plugin community is built into the Gatsby docs as well. So they'll reference both first party and third party plugins directly in the Gatsby docs themselves. So if there's something you're looking for, it's almost always found on gatsbyjs.org.

Matt:  I would second that as well. I came onto that project with Jake a little bit late. So, uh, it was my first kind of introduction to Gatsby as well and I, found the docs to be extremely helpful in getting up to speed and getting caught up to where he was at. So yeah, as far as finding examples of what you're looking for or how to integrate plugins. Like Jake said, they do a great job of implementing a holistic approach to it, so the docs are really great.

Jon: Yeah. So the main site kind of the first stop, when you have a question you can search on there. There's plugins, there's questions, there's tutorials. What about if that's not quite enough? If you got a deeper question. Does the Gatsby community have any resources that they point to what's the best place to get help beyond just reading documentation?

Jake: Yeah, there is a pretty decent community built into gatsbyjs.org. There's a lot of contributors. There's a lot of hype around the stack right now, there's a lot of conversation happening. They seem to iterate pretty quickly, so if there's common problems you'll,  see a lot of people bubble those up pretty quickly and the Gatsby, team will kind of address those, but, even if they're not technically issues with Gatsby, you'll find a lot of commonality just because of the sheer volume of people that are trying out Gatsby right now for the first time and cutting their teeth. There's quite a bit of support there and obviously, you know, there's Gatsby knowledge scattered across the web, but I definitely think the docs and the help section on gatsbyjs.org is probably the easiest place to go.

Jon: I forget, do they have a lot of discussions right there on gatsbyjs.org? In terms of their documentation with comments and responses, or is it more kind of one way communication and you would pop out to like stack overflow or any of those other sites you mentioned kind of the knowledge being scattered across the web. When,  you do need more like real time help, what's the best way to go?

Jake: They do respond on their community site itself. A lot of times, if it's actually an issue,  GitHub is the best place to go because that's where stack is hosted. So if someone's got a bug or an issue that they've posted, you'll find a lot of that there.

Matt: In addition to that in their docs, they do have external links and additional pieces of community where you can find additional answers or additional help, as well as having a discord and some other places to continue that conversation. So it seems like a pretty well rounded, you know, approach to being able to help people when they get stuck, which is really helpful.

Jon: If you go to gatsbyjs.org/contributing/community, they have a section in there called where to get support and they've got a couple of things listed: stack overflow, discord, hash node, and the dev community. If you're seeing an error or an issue, a lot of times googling the error message that a lot of us quite familiar with in the Rails world, actually works quite well with Gatsby as well.

Jake: Definitely.

Jon: Sounds like there's a pretty robust ecosystem. Have you found that there's a lot of duplication of plugins or is there typically the community has coalesced around a specific plugin or tool for the job and that one will get you pretty far along road? I guess the question is, can you trust what you find on gatsbyjs.org from a plugin perspective?

Jake: I think generally, yes. Especially what you find on gatsbyjs.org. There are some other places that I think that you can find Gatsby plugins that are just on GitHub that maybe aren't explicitly acknowledged yet by Gatsby. But, in general, plugins that are out there are good. I haven't really seen a ton of duplication at this point. There's a lot of times there'll be someone who will fork off of one and say, hey, this has been inspired by this plugin and solves this niche thing. But for the most part the plugins that are there, they almost always are well-documented and work for what you need the first time you read through it, if you read through it all the way.

Matt: The point about duplication, I think is important to bring up. I've been helping with a little bit of WordPress work here recently and If you're familiar with WordPress and how their plugin system works, there are a ton of different plugins and alternatives, and there's people that rally behind one over another, and it can be kind of a confusing environment if you're just not up to date with what's the latest and greatest and the plugins and whatnot. There's a lot of back and forth with preference there. What I've seen in Gatsby is it seems like people rally behind one that works best. I personally haven't seen a ton of duplication in terms of, you know, plugins, that are recommended or rallied behind by the community.

Jon: Yeah. And I know there are some solutions in WordPress to try and help make it a little bit more developer centric story, both with your local build out of the site. And then also being able to deploy that out to infrastructure. But I think Gatsby tries to make that with the JavaScript ecosystem, a little bit more of a first class citizen, where you've got NPM packages that are being able to be easily versioned that you can upgrade things like what's the upgrade story for Gatsby in any of the plugins? Is that relatively smooth?

Jake: Yeah, all of the plugins are all hosted in NPM. So, every plugin that you have is just a normal package. If it needs to be updated, you yarn update it, you yarn install it, you pull it in and then you just configure it and that's,  pretty much it. That's all she wrote.

Matt: Yeah, I think that's one of the pieces that feels a bit of a departure, you know, in the WordPress world. Um, you know, you kind of, at times are, you know, the hands of the developer of that particular plugin. Whereas in Gatsby, it seems like there's a lot more configurability there. 

Jon: So we're talking about plugins. Do either of you have some favorite plugins that you typically pull into a new Gatsby build? Jake, why don't we start with you?

Jake: Yeah. I think the number one thing, and one of the best well-supported things in Gatsby is the plugins for different CMSes, content management systems. I have a tendency to use Contentful, but there's lots of others including like Netlify's CMS and other things. One of the great things about the plugin system is that they're made to where you can plug plugins into other plugins. So for an example remark, which is used for re-hyping your markdown that you've written in a CMS and turning that straight into raw HTML, you can plug image processors or syntax highlighters and things like that directly into that plugin so that any of your markdown that you process will be formatted for you and you won't have to write hardly any custom code to do all that, which is really, really nice.

Matt: I can agree with Jake on the Gatsby plugins like using the headless CMS, I think that's, that's a really good benefit to kind of this way of development for a static site. Really enjoy that Contentful workflow. As well as, you know, just some of the additional things they add for SEO, making that pretty simple. Again, it's something that, you know, if you're coming from a different stack, may or may not be as easy to do. so I felt like that was another add that a lot of times, you know, people forget. Um, so that was another thing that we added kind of late in the game, but it didn't take much to get up and running.

Jon: So let's talk about Gatsby's SEO story for a little bit. They bake SEO right into the framework and make it an important part of a static site. Obviously, if you're building a static site, a lot of times it's a marketing site or at least a site that you want people to be able to find and make available to the web, so SEO is important. What does Gatsby offer in the SEO realm, and do you need to augment that with plugins, or is it great out of the box?

Jake: Gatsby has great SEO support from the get go for sure. SEO is a large topic, so it depends on what you're,  asking, uh, explicitly, but you know, an out of the box Gatsby, site's going to have great lighthouse scores. Especially looking at things like first Contentful paint, using Gatsby image which helps you to both lazy load with the great blur up effect and optimize the image size that you're pulling for different things. That's all baked into Gatsby image, and it really helps when they pull up the site. How fast can they see things there immediately without having to load every single asset on the page?

There's some other really great plugins that help with that. React helmet has a Gatsby plugin, which is really easy to tie into your layout which you can apply across all of your pages. There's some site metadata plugins that can help you pull stuff into your GraphQL queries across all your pages.

There's lots of stuff dealing with structured data and they can build your robots TXT for you, they can build your site map for you, there's a lot of stuff that may not be super hard to do on your own, but  it's time exhaustive and so you'll just throw that plugin in to the Gatsby config and go on your way for the most part and that's really nice.

Jon: I know WordPress has a pretty rich SEO story as well. So it's good to see Gatsby and other static site generators and CMS systems like that. Being able to be on par. So that that isn't a, uh, a net detractor for choosing that ecosystem. So we built quite a few static sites at headway over the years. Our homepage actually, since 2015, was originally built with a Ruby static site generator called middleman.

It worked great for a really long time, but eventually our marketing team grew a little bit. They wanted to be able to add more content, control some of the new posts. We had to do a pull request for every new blog posts, for example. So adding new blog posts, adding new content, videos, that kind of thing became a little bit more of a pain and we had to involve the development team pretty regularly and that kind of slowed down our marketing team's ability add new content and create value for the folks that we try to reach. So how does Gatsby fit into an organization that has some of those same concerns wanting a high level of control over the content? And would you recommend something like Gatsby over a more point and click solution like Webflow?

Jake: Yeah, I think there's some give and take. If you are going to be using a developer driven static site like Gatsby versus something like Webflow or wordpress.com, new features and things like that are still going to have to go through developers. But when it comes to content, by and large, something like Contentful can really handle the needs for a marketing team to be able to draft new blog posts or even to draft new, pages. If you have some kind of cookie cutter pages that you have across your site, they can fairly simply go and actually fill all that content in replace images, replace links, change formatting, change flow of the page more or less from Contentful, and then push those builds themselves. And then if there's a few, like, you know, the, header links need to be updated, sometimes that will take a very small pull requests. But even that, the marketing team has been able to handle themselves to be able to put those pull requests in. So I think that, there's a lot of room for Gatsby to be able to set up to just kind of work for a marketing team without involving development at every single step. So I think that, you'll still need developers, but, you can get away with one for maintenance be okay.

Jon: I mentioned that we originally had middleman Ruby static site generator for headway.io. And when we retooled we actually went to webflow. But I think there's a right audience for webflow and it's large, but you need to be able to understand what webflow's doing under the hood in order to most effectively use it. Because when we had our marketing team creating it solely without the help of any developers, we painted ourselves into a little bit of a corner where we didn't quite have the responsive stuff working a hundred percent of the time. The JavaScript dropped down menus for the top navigation maybe were a little bit funky from time to time.

It wouldn't work on IE for example, it was just all broken because of some choices that we had made and that choice is like a oh, this toggle in Webflow sounds like a good idea, and it could have pretty far reaching implications. So you do need to still be somewhat technically adept in my opinion to properly leverage all of the power of webflow. But when you get over that learning curve it is really quite amazing what you can build. I think though what I've seen in my career throughout building content management systems for clients is that, I would frequently try and build the structure of a page myself and then give them  drop in places to edit the content, because if you just said, hey, page title, and then body, and then footer and the body, it was just a WYSIWYG editor. Then they're going to be able to do way too much and the code that those WYSIWYG editors historically had generated was not great. A lot of inline styles, a lot of problems with the way that it would use outdated, tags or just problems with the way that it would render across different browsers and if you tried to start to use it for layout, or if you threw a table in there to try and space things around, they got pretty messy pretty quickly. So do you think that Gatsby and Contentful is somewhat of a modern day parallel to what we had been seeing in the past with building a content management site from scratch and instead we can leverage kind of two tools that are the best for their respective jobs. Keep a little bit of a guardrail on how that content will ultimately render from a development perspective, but then empower the marketing team or whomever makes the most sense to be adding new content to Gatsby, to really have that right at their fingertips. Is that a fair assumption?

Jake: Yeah, I think so. And that marrying of these two great technologies, it's going to be the same with fact that your dev team is going to have to communicate well with your marketing team. I think that we've built our site fairly well in a way my client's site that I've been working on with Gatsby, we built it in a way that there's a fairly clear understanding of, hey, with this type of content model, you're supposed to put this kind of data in, it's gonna appear like this, and if you need anything more fancy we can build it in for you, we can make it custom render YouTube videos that are going to lazy load and all that. So, you can set it up to be fairly easy for them to manage on the Contentful side. It's all about communication between that marketing developer handoff for sure.

Matt: Yeah, I think that the powerful part of Contentful is being able to create your own templates and essentially create custom fields. And be able to verify that the data that's being entered by a marketing team for example, is going to be accurate and it's not going to have issues down the road because someone entered, you know, incorrect data there, for example. So I found that part of Contentful to be extremely helpful, to kind of safeguard against some of those things. Now you can obviously make that as extreme or as light as you want really, and so just having that flexibility from a developers point of view where I can you know, add some constraints there that kind of helped the marketing team not get themselves in trouble, is really helpful. Takes some of that concern off of us as well.

Jon: Yeah, Contentful is an amazing system and it can get expensive. If you lean into all of their different offerings. For example, they've got content approval workflows, they've got a number of requests and pieces of content at certain different gates, but there is a free tier and we found the free tier to be quite adequate for a lot of static sites that we've built with that headless CMS, so definitely would encourage you to check it out. And if you're getting the kind of volume where you need to pay, hopefully it holds true that Contentful like many SAS platforms, you're generating a lot more value than the cost of that system and they're doing so much for you that it's cheaper to buy than to build in a lot of cases. Um, The fun thing for me when I was first getting into Contentful was building up that data model. It felt right almost as quick and easy as generating new Rails scaffolds. And you're just pushing and pulling, models around then their attributes and linking things together and making it just kind of all happen, right there in their web UI was pretty neat.

So how have we leveraged Contentful, Jake, in this client project to be able to have it be that dynamic source of new content? And is there something you had to do special in Gatsby in order to allow, for example, a new blog post and Contentful to automatically show up in Gatsby without having to, you know, cause it's a static site, a lot of times folks think that means, okay, I've got a blog entry template and now I must go enter all of my content for that new blog. And there's a new static file on the file system that I use github pages or something to deploy out there. How is it different with Contentful and with the way that we have Gatsby set up.

Jake: Yeah. So there's a couple of things that we've done to make Contentful really work for that marketing team. One is like Matt was saying, you know, we put in the right fields and we put the right safeguards on them. If it's a link, we make sure it has to be an HTTP formatted link and in some cases there's more complex layouts that we want them to be able to generate. So instead of just having one markdown body that they just drop whatever content they want and we've actually got it to where you can link multiple markdown bodies within that post and those will populate on some left floated or right floated divs on the page. There's a good bit of configuration or customization that you can do to make those models really work for you and to make them really represent the data like you want it. And then on the Gatsby side of things, it's a little bit of configuration, but it's pretty simple. They have a file called Gatsby node, which allows you to run some custom node, JavaScript, build. And basically they have a great API for creating pages that lets you pull in your graph query for whatever data you need, and if you want to build out pages based on the data that you're getting from Contentful you can do all that right there.  You take a template that you've built as a page in Gatsby, you take the graph data that you have and you call create page, and that's pretty much it. And with that there's lots of customization. You can do one off pages that just have whatever path you assigned to them or you can do even as far as like paginated pages can all be built directly from there.  Probably the most advanced configuration we have in there is our blog system so it pulls in and all of the blog posts. It makes paginated homepages for all of them. It makes all of the blog pages and then it actually indexes all of those pages with algolia, which is a little bit more of a topic, but essentially that makes it to where we have an auto-generated blog page with search and pagination, which is pretty neat for not that many lines of code.

Matt: I think in addition to the blog stuff Jake is, uh, some of the stuff we did with migrating over from the client's old site. I think they were WordPress in the past. That's always a concern is like, do I get all these? How do I get all these blogs over and verify that everything moved correctly? Right? Contentful offers some pretty easy options there for doing like batch importing and batch exporting, that kind of thing, so that you can get your data over and migrated correctly. And I think in an afternoon we were able to write up a quick script kind of auto batch that stuff for us. I know that's a major concern when people are thinking about switching over stacks or whatever. How do I migrate my data? Contentful kind of handles that for you. I know we're going really hard on the Contentful stuff, but it really was helpful to get that going.

Jon: Yeah. I mean that backend data is a huge part of being able to drive dynamic content through what otherwise people would view as a static site. We are trying to help, I guess bring to light that static sites can be dynamically generated without a lot of pain. And we have that story of middleman not being the case for us, which prompted the switch to webflow. But you can do it with Gatsby and there's many different options on that backend data management piece. So, no, I think that's, it's good for folks to understand that. 

Let's talk a little bit about the front end styling aspect. So it's built upon react. Obviously, folks love react. They have a ton of mind share the developer ergonomics of React and being able to componentize your UI are very powerful.

What's the development story with Gatsby on the front end? Like how does it feel? What are the developer ergonomics? Is it a joy to use.

Jake: I'd say yes, definitely. I think that when you start actually building react side of Gatsby, it feels very much like you're building a react spa, but you don't have to manage, you know, like a router or anything like that. That's built into Gatsby and you have GraphQL is built right in, so, building a new page in Gatsby is as easy as dropping a new page.js in your pages folder and just writing some react code, and whatever's returned from there is going to be rendered on the page at that path. And that's just awesome. It's so easy to get from zero to moving and that's really what I love about it is that there isn't anything special to do to make Gatsby work as a react site. You just write react code.

Matt: Yeah, I totally agree there implementing plugins and things like that. A lot of times it's as simple as, you know, using their custom hooks that they built right, for the plugin. So if you're familiar with that workflow, then none of this will feel that different from what you do on a normal react app. So can get up and running pretty fast, like Jake said, there's not a lot of steep learning curve unless, you know, you just have no experience with react. Obviously you need to know a little bit of GraphQL and things like that. A lot of these things are things we're doing anyway on other react builds so it's not too different from, like I said, what we do on a normal react app.

Jon: Yeah, Matt, I think you mentioned that you actually mentor some folks that are looking to get into web application development and you found throughout your exploration with Gatsby in some of the sites you've been able to build a headway, that it could be a really good on ramp to teach people those fundamentals of react and not have to worry too much about the state and too much about the database because it's kind of all built in right there for you with Gatsby adding those guardrails. Has that been positive experience for the folks you've been trying to teach react?

Matt: Yeah, like I said, would say that the major kind of hurdle there is learning some just fundamentals of react. But that's going to come with learning react anyway. Right? So  as long as you're on board with pursuing the react development and, you know, looking into things like GraphQL, then really no different there.

I think the main benefit  is you can get up to speed pretty quickly and have them build things that they feel are real from day one. I can get content on a page within 15 minutes. Now they may not understand the complexity behind what's going on behind the scenes with connecting up Contentful and things like that. You know, they might not understand that today and I feel like that's fine. If the pursuit is to teach them how use React, then Gatsby has been a really good tool for that. Cause I can quickly get data into their front end. I can quickly, set them up with something that looks and feels like real world application.

Like I said, there is some learning curve obviously with the GraphQL side of it. There is some learning curve with just react in general, if they don't have any experience there. But from our perspective of building react in the real world, it really is no different.

I would say it's a good kind of launching pad for creating what feels like real-world apps pretty quickly.

Jon: So Jake, we built the front end of this from a theming and UI perspective with a toolkit called material UI. Do you want to talk about that a little bit?

Jake: Yeah. So Material UI is a styling kit that's based on Google's Material UI standard. I think the biggest benefit of Material UI, well there's two big benefits of Material UI. One is that it's really easy to see the benefit of it very fast -  you spin up your own theme, you start pulling in components and for the most part, they just work. They help you use Flexbox without learning too much CSS if you don't know that already. And they help you, you know, just pulling things like buttons that look good and topography that's consistent across your site. A lot of those things are built into the very like surface level of Material, UI's component system. 

Jon: And accessibility, right? Just a lot of the sane defaults that you would otherwise need to know about and build yourself in a way that works across all the browsers and keeping all of the different folks who might have disabilities in mind.

Jake: Yeah, it looks good and it does HTML the right way whenever you're building out your components. So I think that's a huge bonus of it. The other benefit of it is that it's extremely extensible and configurable. You know, they've got a huge CSS API that lets you really dig into the way that all of the components work together and look together and you can build some really cool custom stuff based on Material UI and it's just a great jumping off point for building some complex components so I love that about it. Using it with Gatsby also is easy because there's a component called link in Material UI, and there's a component called link also in Gatsby and the component link in Gatsby is actually really important. You know, we talked about there's no router, there's no location state that you have to manage and instead you, for the most part, just use this link component that you give it link to a relative path, and whenever you load that page, if you've got links on there, it's going to start  pre-loading some of the content on those other pages so that whenever your user does click that link, it's instant. Switches the page, it only refreshes what it has to, and keeps all the layout things that stay the same. That's super powerful part of Gatsby, and material UI, the link component is all about your theming. So you theme your link and your link always looks the same across your site. And there's a plugin that lets you marry those two things as well as some other button and other types of components with material UI, right in with the way that Gatsby works.  I found that to be really nice to not worry that I'm using Gatsby the right way and that I'm gonna be optimized in the components that I build and also that they're going to look and be accessible in the way that Material UI is.

Jon: There's one criticism that I've seen from some folks that Gatsby is never going to be as fast as a true HTML static site. That is the case, right? It has to load a JavaScript bundle. But there's a lot that you get from a maintenance perspective, from a developer ergonomics perspective.  Gatsby, is also very, very focused on speed and on performance. And so while that might not be as performance as the exact raw HTML and raw DOM, it is very, very top of mind for them and I think the trade off in the majority of cases is worth it. It's a progressive scale like anything, right? You could reach a level at which you need to optimize certain funnels on your site and perhaps, re-evaluating Gatsby at that scale is something that any same developer would do. But for getting off the ground quickly and being able to maintain an amazing looking static site, a landing page, a documentation page, I think it's a Really good system. And under the hood they're doing some amazing things. You talked about the prefetching capability of Gatsby after it originally loads some of that content it starts to spider out and see where are all the links that are associated with this page? You can watch in the network tab, it's really cool how it goes to do a prefetch of all of that JSON data that's associated with the other static pages so that it tries to do a little bit of an initial render and then spiders out. And so it takes over as a SPA like you mentioned, after it first starts to download its core assets, and then now you're inside of a React SPA all of the links will prefetch and if on page two there was a link that wasn't on page one, when you navigate to a prefetch to page two it will start to prefetch that page three that wasn't on page one. So it does all the work in the background to make sure that each new navigation action is extremely snappy and fast and it works well. And again, they built all of that with SEO in mind and with accessibility in mind. So you don't have the trade off of building it yourself with JavaScript from scratch having to know it, understand, and take into account all of those best practices.

Matt: Yeah, I would  also add that you can tell that Gatsby is focused on performance, right? It's front of mind for them because you can see it in like you said, the prefetching. You can see it in the way that they handle images. There's different plugins add-ons or configurations that you can do within Gatsby to lazy load images and have SVGs load, for example, that will kind of just handle that for you. So they are being cognizant of performance, right? They don't want to really sacrifice that at the sake of writing React. It doesn't seem that way to me. It seems like it is on the front of their mind that they do want to make sure that it's snappy and it's quick and that your pages load fast and that you know, when I click on this link I'm not going to have to wait. So like the prefetching thing I think Jon hit on is super important and kind of a cool feature that they've added.

Jake: To tag onto this discussion actually ran across a plugin recently that, well, it was on a path that I was looking at toying with using Preact instead of React and there's a really easy plugin to drop that into your Gatsby site. But, the person who wrote the article went a step further and actually said that there's another plugin that will remove all JavaScript from your site. Obviously that's not great if you're writing a super interactive site, but you can still get the Gatsby development ecosystem and if you have something so simple that you could just have static HTML, it'll do that, just static HTML in your build. And it'll dramatically reduce your build size. That's not the recommended way of using Gatsby, but it's pretty cool that that even is possible.

Jon: I didn't know about that. Very cool. We'll have links to that in any of the other tools that we mentioned in the show notes. So definitely check out headway.io/even-keeled for that. So we've convinced folks that Gatsby is useful, that it's fun, it's maintainable. How do we get it out to the web?

It's a static site, right? Can we just, put it out on S3? What happens? Do we need to bundle it up? What are people using to typically deploy things, Jake.

Jake: One of the most popular tools is Netlify and Netlify's integration with Gatsby is super good. It's, very easy to set up. You basically tie it into your GitHub repo or your GitLab or your Bitbucket or wherever you're hosting it and you'll get automatic deploys when you merge into master and that is, outside from setting up some ENVs, that's just about it. All it's gonna do is download whatever your latest main branch is and it's going to go ahead and start building that for you and run Gatsby build, optimize your assets, and deploy it for you. And you know, that's really it. It's super easy.

Jon: DNS configuration - they've got all that handled for you right there in Netlify?

Jake: Yep. They've got it all built in you can configure it using your outside DNS configuration source, or you can handle all your CNAME stuff right there in Netlify. So it's very low barrier to entry and you can also go pretty deep. They've got a build plugin system that will optimize your build times using like Gatsby cash. So that it will persist your cash between builds.

They've even added it's not quite incremental build support, but it's close. They have it to where whenever you push from your CMS, they're only gonna rebuild pages that changed based on what CMS was changed. There's lots of cool stuff you can do with Netlify  and it's just so easy to use.

Jon: Yeah. And the Netlify folks and the Gatsby team, they really work hand in hand.  They're not on the same team per se, but they definitely are trying to build an ecosystem that works well together. You can do other stuff on Netlify, but I know that Gatsby's a big part of their story.

Jake: Yeah, they do. And you know, I think that in saying that too, it's  good to note that Gatsby also has great hosting solution that can do a lot of those things as well, Gatsby Cloud, uh is actually Gatsyb's preferred hosting solution. And it does have first class support for incremental builds, which means that, they really have a much faster your build process whenever, just your content changes and you push that up.

But one of the big things with Netlify is just the ecosystem that is around it already supporting it. Gatsby Cloud is a pretty new product and from my understanding, it's going to be pigeonholed into just Gatsby, right? Netlify, you can build other types of static sites, so if you ever want to explore and do something like Redwood.js, you already know what you need to know with Netlify in order to you get something like that spun up so that's why I really enjoy using Netlify. 

Jon: It's good to have options and I Just recently saw that Gatsby cloud was coming online too, a few months back. We had already picked net five for this particular deployment solution and then that was perhaps in private beta, but not on our radar and now looks to be really gaining some traction. So excited to evaluate that in the future. But as you said, a lot of mind share already in the Netlify community and a little bit more flexibility there too. I guess one pro tip that I've seen you do well, Jake, on this project with, GitHub pull requests and Netlify deployment integrations is that it's really easy to build a new feature in a pull request and then have that also be deployed out separately, almost like a mini staging environment to Netlify. Do you want to talk about how that's helped us.

Jake: Yeah. So the way it works is it's a feature in Netlify that you can toggle and it's, deploy previews. And basically, as soon as you open a pull request into whatever branch that you've designated Netlify is going to go ahead and build the code that you've got ready to pull in as if you would have just deployed it the site.

So instead of every single person who goes and does a code review having to go and switch their branch locally and if they are not a developer they don't have to actually get a local development system running or anything like that. They can just do a static review of your code, and then they can click the link that's right there in Github. It looks like a check that passed essentially, and then it's going to be an actual build of the site in production and just on a throw away domain name that, uh, yeah, sub domain that Netlify builds and it's really, really nice. And it leads to a pretty low friction QA process especially being able to pull in content people that are gonna care about, making sure that your changes don't mess up the way that content is displayed and stuff like that. So that's been really, really nice.

Jon: Really sounds like true application development workflow. So one of the other clients we've pitched a Gatsby, Netlify, contentful stack to, we also helped build a React SPA with GCP backend and so thought was that, you know, they're currently on WordPress. They're thinking about scrapping that and revisiting their website to build it for the next five to 10 years, and we said there's a couple of ways you could go. We did talk about webflow. We talked about our site being an option and we didn't know yet or understand if their marketing team would have the desire or the skillset to maintain that effectively. So another option that we talked about and they haven't quite made a choice yet, but was that the Gatsby ecosystem would allow their application development team to really transition into a co-web development team and not feel like they're you know, having to do anything that's different, their skillset would translate directly, and the workflow would translate directly because you're in Github, you're using pull requests, you're doing code review, and it's just a lot of fun. So I think it's a really great choice for a lot of folks.

Anything else either of you want to talk about to wrap up the episode here today?

Matt: Yeah, I would say that, you know, the future looks pretty good for Gatsby or, you know, static site generators in general. There are a few others out there that I know are getting some traction as well. And Pretty excited to see us moving forward with static sites. I mean, just because we spend a lot of our time building web applications or other types of applications, it doesn't mean that some clients don't just need a static site, right? That's true for a lot of marketing pages and a lot of other kind of applications. So, I think that to see them come along with us and get into React and get into using some current technologies that, like you said, Jon  I don't have to turn off my React brain in order to work on the marketing site now.

Which may not seem like a big deal, but if I'm able to keep that same workflow, it cuts out some of the context switching and some of the, you know, reframing of, well, now I'm working on the website, so I've got to put on that brain. I'm excited to see what happens going forward. I'm excited to see where we go with the headless CMS platforms and Gatsby and additional front end static site generators. Pretty exciting.

Jake: To reiterate what Matt just said we're full time developers. We're not just building static sites, we're doing all sorts of development all the time. And being able to go from a, Elixir/Phoenix + React stack for the first half of my day, and then switching over to a Gatsby/Netlify stack for the second half of my day is pretty seamless and that's pretty incredible for us to be able to work at that level. And at the same time, when I'm working on my Gatsby site, I'm also working with people who are content creators and marketing professionals, who have a little bit of a background in development, and they can get their feet wet and they can actually, you know, review PRs, they can open their own PRs for new features all in Gatsby, because they are comfortable enough with the concept that they can learn that fairly easily on the job and that's just really cool.

Jon: Well, I think that about wraps it up for us here on episode three, building static sites with Gatsby. Thanks Jake, thanks Matt, for being on the show. Really appreciate it. Be sure to check out all the show notes for any of the topics that we discussed. We'll have links there and we'll link out to some of our favorite Gatsby starter kits as well, so that you can get off and running right away.