GraphQL + JAMStack - Panel Discussion

Thank you everyone for joining us today. This is Alex Lobera. I'm an independent software developer and coach, maybe best known as the React GraphQL Academy Head Coach. So thank you everyone for joining today. We're going to have a very interesting discussion. We're going to be talking about GraphQL and the JAMstack together. And what's special about it? What's this interesting relationship between? Is this a one off thing? Is this something is going to last or what's coming after these? Are they going to procreate? There are a lot of interesting things we can talk today about the two and of course any gossip between them is also welcome.

Thank you, everyone, for joining us today. This is Alex Loberham. I'm an independent software developer and coach, maybe just known as React GraphQL Academy head coach. So thank you, everyone, for joining today. We are going to have a very interesting discussion. We're going to be talking about GraphQL and the JAMstack together and what's special about it? What's this interesting relationship between? Is this a one-off thing? Is this something that's going to last or what's coming after these? Are they going to procreate? There are a lot of interesting things we can talk today about the two. And of course, any gossip between them is also welcome.

So after this, hopefully, entertaining introduction of the topic, let's have a quick round of introductions because we have a very, very good panel today. So maybe we can go clockwise or maybe, I don't know, Sid, you want to go first and introduce yourself, please? Yeah, sure. Thanks Alex. My name is Sid. I live in India. I work at Gatsby, Inc. Gatsby, Inc. is a company which builds the Gatsby, JS, open-source static site generator, and more. You've probably used it, in case you haven't checked it out. We also build Gatsby Cloud, which is a cloud platform that helps build your Gatsby sites even faster. And, yeah, I'm looking forward to this discussion. Thank you for having me here.

Thank you, Seth. Scott, would you like to introduce yourself, please? Yeah. I'm Scott Moss. I'm the CEO of a company called Type. With an I, because we couldn't afford the Y, because it's really expensive. We're a headless CMS. If you don't know what that is, you can think of us as basically a CMS that has no idea or doesn't really care how your app, or what your app is and how it's built, and we just provide content over an API. We structure your data with a schema. We do the rest. Most of our product is open source. We just handle the API, and the infrastructure, and all the hard stuff for you.

So after this hopefully entertaining introduction of the topic, let's have a quick round of introductions because we have a very, very good panel today. So maybe we can go clockwise or maybe, I don't know, you want to go first and introduce yourself please.

Yeah sure, thanks Alex. My name is Sid. I live in India. I work at Gatsby Inc. Gatsby Inc. is a company which builds the GatsbyJS open source site static site generator and more, you probably use it in case you haven't checked it out. We also build Gatsby Cloud, which is a Cloud platform that helps build your Gatsby sites even faster. I'm looking forward to this discussion, thank you for having me here.

Thank you Sid. Scott, would you like to introduce yourself please? Yeah, I'm Scott Moss. I'm the CEO of a company called Type, with an i. You couldn't afford the y because that's really expensive. We're a headless CMS. If you don't know what that is, you can think of us as like basically a CMS that has no idea or doesn't really care how your app or what your app is, now it's built and we just provide content over an API. You structure your data with the schema, we do the rest. Most of our product is open-source, we just handle the API and the infrastructure and all the hard stuff for you. We basically have integrations with frameworks like Gatsby and Next.js and things like that, and we're currently in private release and will be coming out later this month, so before Christmas. I also am just really interested in everything JAMstack, GraphQL, things like that. I do a lot of courses on platforms like Front-end Masters and stuff like that, so just interested from a user perspective, not just from the CEO of a company, just a really big fan of JAMstack and GraphQL.

We basically have integrations with frameworks like Gatsby, and Next.js, and things like that, and we're currently in private release, and we'll be coming out later this month, so before Christmas. I also am just really interested in everything Jamstack, and GraphQL, and things like that. I do a lot of courses on platforms like Frontend Masters, and stuff like that. So just interested from a user perspective, not just from the CEO of a company, just a really big fan of Jamstack and GraphQL.

So, let's go straight to it. Why GraphQL and Jamstack are a good match? Why is it? You wanted me to start? Okay. Why are they a good match? I mean, I think a lot of the incentives for both of those technologies are aligned, right? So if we look at Jamstack, Jamstack was manifested for the sake of, you know, performance, as in runtime performance, but also, you know, being able to not sacrifice the tooling that we use and being able to use JavaScript and GraphQL is, you know, specifically from the client side, is meant to, you know, follow some of those same guidelines. You only want to get the data that you asked for and nothing more.

Cool, thank you. Yeah, I couldn't have said it better than Scott, but there's definitely everything Scott mentioned and there's also the fact that I think I've seen a trend with the JAMstack where there's a fairly high likelihood that your site is, you know, going to go request data from multiple different sources and back in Gatsby we call that the content mesh. But really it's a simple idea. It's the fact that you use the best tool for the job, you know, if you want to, you know, use a service that helps you build out forms that could have a separate API, which you could call. Or if you want to like embed, you know, comments from Disqus maybe or some other platform, you could, you know, use its own API and the idea is that you use the best sort of tool for the job and you don't reinvent the wheel for everything, right?

Thank you, Scott. So, let's go straight to it. Why are GraphQL and JAMstack a good match? Why are they a good match? I mean, I think a lot of the incentives for both of those technologies are aligned. So, if we look at JAMstack, JAMstack was manifested for the sake of performance as in runtime performance, but also being able to not sacrifice the tooling that we use and being able to use JavaScript. And GraphQL, specifically from the client side, is meant to follow some of those same guidelines. You only want to get the data that you ask for, nothing more. You want to limit how much formatting you have to do before you throw it in the render, different things like that. You want type safety. You just want your app to be more reliable. So, I think those two things independently having some similar goals just make, you know, it kind of just makes sense to do that. So, yeah, I think that's the big reason.

Cool. Thank you. Yeah, I couldn't have said it better than Scott, but there's definitely everything Scott mentioned. And there's also the fact that I think I've seen a trend with the JAMstack where there's a fairly high likelihood that your site is going to go request data from multiple different sources. And at Gatsby we call that the content mesh. But really, it's a simple idea. It's the fact that you use the best tool for the job. You know, if you want to, you know, use a service that helps you build out forms, that could have a separate API, which you could call. Or if you want to, like, embed, you know, comments from Disqus, maybe, or some other platform, you could, you know, use its own API. And the idea is that you use the best sort of tool for the job, and you don't reinvent the wheel for everything right. I think GraphQL turns out to be a really good interface to sort of this, when it comes to multiple different sources, all of which would otherwise have their own way of doing things. And they have their own sort of different interfaces, you know, their own APIs, and with their own docs, and it can get really overwhelming really quickly. I think GraphQL is great, because it gives you one sort of shared interface to be able to fetch or consume data from all these sources, right? That idea is really first class in Gatsby. And that's what that's what GraphQL is all about. In Gatsby, you can use data from really anything, including stuff like type, which I think is in the works. Scott will know more, like he said, but whether it's WordPress, or Sanity, or DattoCMS, or Contentful, or really any other third party service, you can consume all of them over a sort of unified interface, which is GraphQL, in that case. And you happen to get documentation out of the box with GraphQL. I think that's really powerful. And with that, there's also the matter of simplicity.

So, you know, I think that's a big reason. Cool, thank you. Yeah, I couldn't have said it better than Scott, but there's definitely everything Scott mentioned and there's also the fact that I think I've seen a trend with the JAMstack where there's a fairly high likelihood that your site is, you know, going to go request data from multiple different sources and back in Gatsby we call that the content mesh. But really it's a simple idea. It's the fact that you use the best tool for the job, you know, if you want to, you know, use a service that helps you build out forms that could have a separate API, which you could call. Or if you want to like embed, you know, comments from Disqus maybe or some other platform, you could, you know, use its own API and the idea is that you use the best sort of tool for the job and you don't reinvent the wheel for everything, right? I think GraphQL turns out to be a really good interface to sort of this, when it comes to multiple different sources, all of which would otherwise have their own way of doing things and they'd have their own sort of different interfaces, you know, their own APIs and their own docs and it can get really overwhelming really quickly. And I think GraphQL is great because it gives you one sort of shared interface to be able to fetch or consume data from all these sources, right? That idea is really first class in Gatsby and that's what GraphQL is all about in Gatsby, you can use data from really anything including, you know, stuff like type, which I think is the works, Scott will know more like he said, but, you know, whether it's WordPress or Sanity or DattoCMS or Contentful or really any other third party service. You can consume all of them over a sort of unified interface, which is GraphQL, in that case, and you happen to get sort of documentation out of the box with GraphQL. I think that's really powerful. And with that, there's also the, you know, the matter of simplicity. I think the Jamstack is also about simplicity when it comes to a developer, right? Being able to write code that, you know, you know will be built in a super performant way, but without having to sort of do all of that yourself, and in a way where DX is still like really important, and it is for us at Gatsby, it's great. And I think GraphQL sort of ties into that as well, right? You don't have to always know how to call your API or like what tokens that you need, or, you know, you don't have to understand the sort of shape of every single API independently. You can just write a query, which you can, you know, sort of auto complete in GraphQL even, paste that in, and boom, it just works. So I think a lot of these ideas, you know, philosophically also are kind of shared between both the JAMstack and GraphQL, and that's one of the reasons why, you know, Gatsby uses GraphQL so extensively.

I think the Jamstack is also about simplicity when it comes to a developer, being able to write code that you know will be built in a super performant way, but without having to do all of that yourself. And in a way, where DX is still really important, and it is for us at Gatsby, is great. And I think GraphQL sort of ties into that as well. You don't have to always know how to call your API, or what tokens that you need. Or you don't have to understand the sort of shape of every single API independently. You can just write a query, which you can sort of auto-complete, graphically even, paste that in, and boom, it just works. So I think a lot of these ideas, philosophically also, are kind of shared between both the JAMstack and GraphQL. And that's one of the reasons why Gatsby uses GraphQL so extensively.

So I think a lot of these ideas, you know, philosophically also are kind of shared between both the JAMstack and GraphQL, and that's one of the reasons why, you know, Gatsby uses GraphQL so extensively. That's really cool. Thank you very much. I could not agree more with both of you. I think you both touched a few things that are very interesting, so we're going to zoom in a little bit in some of those. I'm also very passionate about the JAMstack. One of the things I like about the JAMstack is that it separates how we create the content from how we consume or display that content, and I think in my view, it has contributed to this proliferation of many content creators, healthy CMS, or site generators, so there's a lot of in the ecosystem, and I wonder how can GraphQL specifically help us connect them. You mentioned some of the things from server to client but maybe from server to server, and what are your thoughts on how this unified language that can help connecting and simplify all these mesh that you were mentioning.

Sit. Yeah, that's a great question. I'll talk about a quick example which sort of ties into my talk from before as well. Jason Ball, who's a coworker and a friend back at Gatsby, built WPGraphQL. And if we sort of rewind back to why he built it before it became a Gatsby-sponsored project, and because we realized that a lot of the users that were using it were actually using it with Gatsby, before all of that happened, like rewind in the past, Jason was trying to build a... so Jason was working at a newspaper, and there were a bunch of other newspapers, right? And they all wanted to be able to syndicate their content across each other, and that sort of stuff is also hard, right, when it comes to multiple different systems and platforms and groups of people. It's hard to find an interface that would let everyone share their data in a sort of unified fashion where it's easy to consume. And where it doesn't require you to sort of invest in tools per sort of instance of it. And that's where WPGraphQL came from, because it turns out a lot of these were WordPress instances, and WPGraphQL sort of does a great way to sort of syndicate data between them. So coming back to stuff on the content mesh in different services and having them interact with each other, I haven't seen a lot of tools that let us do that. I mean, I think I've seen One Graph and the sort that let you, that sort of let you consume them together. I think Gatsby is also an example there, where it's while you can't run that in production, you could use that at build time. But I'm definitely looking forward to more tools that sort of support interactivity between platforms.

That's really interesting, like Scott, what do you think about that? Yeah, so I think my initial thoughts, and this is just like for me working on a CMS for the last two or three years, and then also teaching a lot of this stuff. To me, the really big thing it comes down to just like how much application code are you going to be writing versus how much you're not going to be writing. If I'm building some Jamstack app, and I need to pull in content or data from multiple sources, from strike, from this CMS, from Disqus, like wherever, sure, I could do that. I can use window.fetch or whatever mechanism, Axios, however you want to do it. But all the application code that I would have to write to really get that the way that I want it to look inside of my components, it's going to be a lot, right? Whereas if I had used something like GraphQL, I complete eliminate that application code and the logic for what the structure of that data is going to look like is defined in the query, defined in the schema, and it's just a much more structured, safe place to define those connections between those different endpoints that when you finally get to writing application code, it's read-only. It's very simple. And to me, I've noticed with companies and teams of all sizes, that is really like a huge help for them to ease that burden of all that transformation application code, because usually like when things error out during a build or even sometimes runtime, depending on what framework you have, it's that code. It's that code of like trying to merge all this stuff together. Now you don't have to, because it wouldn't have executed through GraphQL because of the type safety if it wasn't correct in the first place.

That's really cool, thank you very much. I could not agree more with both of you. I think you both touched a few things that are very interesting. So we're going to zoom in a little bit in some of those. I'm also very passionate about the JAMstack. One of the things I like about the JAMstack is that it separates how we create the content, from how we consume or display that content. And I think in my view, it has contributed to this proliferation of many content creators, HelloCMS, or site generators. So there's a lot in the ecosystem. And I wonder how can GraphQL specifically help us connect them? You mentioned some of the things, from server to client, but maybe from server to server. And what are your thoughts on how this unified language that can help connecting and simplify all this mesh that you were mentioning, Sid?

Yeah, that's a great question. I'll talk about a quick example which ties into my talk from before as well. Jason Ball, who's a co-worker and a friend back at Gatsby, built WPGraphQL. And if you rewind back to why he built it, before it became a Gatsby-sponsored project, and because we realized that a lot of the users that were using it were actually using it with Gatsby, before all of that happened, like rewind in the past, Jason was trying to build a- So, Jason was working at a newspaper, and there were a bunch of other newspapers, right? And they all wanted to be able to syndicate their content across each other. And that sort of stuff is also hard, right? When it comes to multiple different systems and platforms and groups of people, it's hard to find an interface that would let everyone share their data in a unified fashion, where it's easy to consume, and where it doesn't require you to invest in tools per instance of it. And that's where WPGraphQL came from, because it turns out a lot of these were WordPress instances, and WPGraphQL served as a great way to syndicate data between them. So coming back to, you know, stuff on the content mesh and different services and having them interact with each other, I haven't seen a lot of tools that would, that let us do that. I mean, I think I've seen one graph, and the sort that let you, that sort of let you consume them together. I think Gatsby is also an example there, where it's while you can't run that in production, you could use that at build time. But I'm definitely looking forward to more tools that sort of support interactivity between platforms.

Yeah, so I think, you know, my initial thoughts, and this is just like for me working on a CMS for like the last two or three years, and then also teach a lot of this stuff, to me, the really big thing, it comes down to just like, how much application code are you going to be writing versus how much you're not going to be writing, right? So if I'm building some Jamstack app and I need to pull in content or data from multiple sources, from Stripe, from this CMS, from, you know, Disqus, like wherever, sure, I could do that. I can, you know, use Window.Fetch or whatever mechanism, Axios, however you want to do it. But all the application code that I would have to write to really get that the way that I want it to look inside of my components, it's gonna be a lot. Right? Whereas if I had used something like GraphQL, I completely eliminate that application code and the logic for what the structure of that data is gonna look like is defined in the query, it's defined in the schema. And it's just a much more structured safe place to define those connections between those different endpoints that when you finally get to writing application code, it's read-only, it's very simple. And to me, I've noticed with companies and teams of all sizes, that is really like a huge help for them to ease that burden of all that transformation application code. Because usually like when things error out during a build or, or even sometimes run time, depending on framework you have, it's that code. It's that code of like, trying to merge all this stuff together. Now, you don't have to, because it wouldn't have executed through GraphQL because of the type safety if it wasn't correct in the first place. So you're pretty much good to go.

So you're pretty much good to go. So I think that is something powerful that GraphQL offers JAMstack when connecting to multiple sources. Yeah, that's a really good point. I agree. I think it's also interesting. It saves a lot of time. And as you were mentioning this single language to query all and self-documenting as well, all those different data sources, they can be very useful when dealing with many different sources and you need to build things fast. I think I agree that that can be very valuable.

So I was looking at the jamstack.org website yesterday and I was looking at the different headless CMS and side generators. And there are a lot. And I was looking at which ones had or are using GraphQL and both on the headless CMS and on the side generators side of it. And not all of them use GraphQL, not all the side generators use GraphQL and not all the headless CMS use GraphQL. So why do you think is that? What are the traits of in your opinion? Yeah, that's a great question. And something that we hear a lot, I've read a lot of issues, respond to a lot of issues, discussions on GitHub about why Gatsby uses GraphQL. Because if you're new to, say, the web in general, and just trying to build out a blog or a simple site using a static site generator, and if you've never seen GraphQL before, I can see why it could look really intimidating. And it's one more thing you have to learn. So there's definitely that sort of learning curve, which is why we get this question a lot about why Gatsby really uses GraphQL.

So you're pretty much good to go. So I think that is something powerful that GraphQL offers JAMstack with connecting to multiple sources. Yeah, that's a really good point. I agree. I think it's also interesting. It saves a lot of time. And as you were mentioning, this single language to query all and self-documenting as well, all those different data sources, they can be very useful when dealing with many different sources and you need to build things fast.

I think I agree that that can be very valuable. I was looking at the JAMstack.org website yesterday and I was looking at the different headless CMS and side generators and there are a lot. And I was looking at which ones had, or using GraphQL and both on the headless CMS and on the side generator side of it. And not all of them use GraphQL, not all the side generators use GraphQL and not all the headless CMS use GraphQL. So why do you think it's that? What are the traits of, in your opinion?

Yeah, that's a great question. And something that we hear a lot, right. I've read a lot of issues, responded to a lot of issues, discussions on GitHub about why Gatsby uses GraphQL because if you're new to say the web in general, you're just trying to build out a blog or a simple site using a static site generator. And if you've never seen GraphQL before, I can see why it could look really intimidating. And it's one more thing you have to learn, right? So there's definitely that learning curve and which is why we get this question a lot about why Gatsby really uses GraphQL.

And I think the trade off really is about simplicity and time that it takes for you to get started versus time that you take to keep building, right? One thing I've seen with CMSs or even other static site generators, I mean, I know Next can now do static site generation as well, right? Is that it's much like React in a way, in the sense that things start getting declarative, and that can help you move a lot faster later while the tradeoff is that you pay some more upfront cost. Let me talk about an example. If you build a site in Next right now, right, and you're using it as a static site generator, you don't have to deal with GraphQL, and that's great because you don't have to learn GraphQL. And if you don't know GraphQL, that might seem like the best way to go. But you're going to have to write imperative code for every single other data source that you need to fetch data from. And that code adds up over time. It's code you have to maintain. It's code you have to debug. It's code that you have to help other developers understand. And it's also code that runs at the runtime, right? Or that code that, you know, I mean, it's code that could, it's just more code to break, right? But it seemed simple in the beginning because there was sort of a low upfront cost to pay. With Gatsby, if you don't know GraphQL, there's definitely a learning curve, and there's that initial upfront cost to have to pay to understand GraphQL and learn it and then start writing your queries. But, the beauty of it then is that if you've consumed one data source in Gatsby, you can probably consume any other data source using a plug-in. Like just install it and it'll work. Because you know how to write a query, you know what GraphQL is, you know where to write your query, and now the only thing that'll change is the shape of your query, depending on the schema and depending on the service you're using.

And I think the tradeoff really is about simplicity and time that it takes for you to get started, versus time that you take to keep building. One thing I've seen with CMSs or even other static site generators, I mean, I know Next can now do static site generation as well, is that it's much like React in a way, in the sense that things start getting declarative. And that can help you move a lot faster later, while the tradeoff is that you pay some more upfront cost.

Let me talk about an example. If you build a site in Next right now, and you're using it as a static site generator, you don't have to deal with GraphQL. And that's great, because you don't have to learn GraphQL. And if you don't know GraphQL, that might seem like the best way to go. But, you're going to have to write imperative code for every single other data source that you need to fetch data from. And that code adds up over time. It's code you have to maintain. It's code you have to debug.

It's code that you have to help other developers understand. And it's also code that runs at the runtime. It's just more code to break. But it seemed simple in the beginning because there was sort of a low upfront cost to pay. With Gatsby, if you don't know GraphQL, there's definitely a learning curve, and there's that initial upfront cost to have to pay to understand GraphQL and learn it and then start writing your queries. But the beauty of it then is that if you've consumed one data source in Gatsby, you can probably consume any other data source using a plugin, just installing your work, because you know how to write a query, you know what GraphQL is, you know where to write your query, and now the only thing that'll change is the shape of your query, depending on the schema and depending on the service you're using.

But you get sort of, you know, it's self-documenting out of the box. That's one of my favorite things about GraphQL, and you have the graphical IDE, so often that's not hard, which means you can move a lot quicker later even though you've paid that upfront cost.

And that sort of declarative nature of being able to consume multiple data sources, I think, is what sort of really separates Gatsby from other static-side generators. And like you said, like Alex mentioned, I think there's definitely that trade-off of whether you want that simplicity when you get started or not. And again, not every tool is for everyone.

So I mean, I completely get that things aren't mutually exclusive here. If you don't like GraphQL and if you want to keep things simple, and if you're more comfortable with calling fetch for an API, that's fine. But the moment you start consuming a lot of different data sources or WordPress, like we spoke about in my talk, you start seeing the same issues with all of that as we've seen over time with REST APIs in general, right. You start underfetching, sorry, you start overfetching or in some cases you're underfetching. And then stuff breaks, and it's just really hard to keep track of all of that. It's more core you have to write. With Gatsby, you don't need to write any of that. I think that's what separates Gatsby from other static site generators when it comes to GraphQL itself.

To touch on the second part of your question, which is CMSs that support GraphQL natively versus not. I think it's a huge DX win when a CMS supports GraphQL out of the box. Because if I'm using a new CMS, the last thing I want to do is go back, look at docs, and understand how it saves my data or how I'm able to fetch it. With GraphQL, it's as simple as opening an ID and starting to write my queries and I have everything over autocomplete. It just feels like so much less work. So honestly, if I'm using a CMS now, it's very unlikely I'd pick one that doesn't support GraphQL. But again, that's that bias that I have. What do you think, Scott?

Yeah, I mean there's so much. I mean this has literally been my life for the last three years, is both of these topics. So in a previous version of Type, I think we exclusively only supported GraphQL and there was a lot of learnings there. So, you know, touching on the topic of CMS is there's really only, you know, two reasons why a CMS would or wouldn't support GraphQL. One is, is that CMS capable of serving what I call structured content? So we're talking like content that is more than just here's some free-flowing content like a blog post or, you know, something like that. Like is their structure, are their objects, are there arrays, is that some nested data, some relational data which is big? Usually, if that's the case, that CMS is going to support some type of Graph API, whether it's something they made themselves in the case of something like sanity, or also opting into something like GraphQL, you're going to need something to handle those relationships, and I think there it's kind of like a no-brainer. But then again, like I said, you have some CMSs that are just like, oh, we're just for blog posts. Well, maybe you don't really need GraphQL for that because you're really just getting back a big blob of text. So what are you going to do with that? So they might not opt into that. As far as like Jamstack goes, there's really only a couple of reasons.

But you get sort of, you know, it's self-documenting out of the book. That's one of my favorite things about GraphQL, and you have the graphical IDE, so often that's not hard, which means you can move a lot quicker later, even though you've paid that upfront cost. And that sort of declarative nature of being able to consume multiple data sources, I think is what sort of really separates Gatsby from other static-side generators. And like you said, like Alex mentioned, I think there's definitely that trade-off of whether you want that simplicity when you get started or not.

And I mean, again, not every tool is for everyone, so I mean I completely get that things aren't mutually exclusive here. If you don't like GraphQL, and if you want to keep things simple, and if you're more comfortable with just, like, you know, calling fetch for an API, that's fine. But the moment you start consuming a lot of different data sources or WordPress, like we spoke about in my talk, you start seeing the same issues with all of that as we've seen over time with REST APIs. In general, you start overfetching, or in some cases, you're underfetching and then, you know, stuff breaks. It's more code you have to write. With Gatsby, you don't need to write any of that. I think that's what sort of separates, you know, Gatsby from other static side generators when it comes to GraphQL itself.

To touch on the second part of your question, which is CMSes that support GraphQL natively, versus not, I think it's a huge DX win when a CMS supports GraphQL out of the box. Because, I mean, if I'm using a new CMS, the last thing I want to do is go back, look at docs and understand how it, you know, saves my data or how I'm able to fetch it. With GraphQL, it's as simple as opening an ID and starting to write my queries and I have everything over autocomplete. It just feels like so much less work. So honestly, you know, if I'm using a CMS now, it's very unlikely I'd pick one that doesn't support GraphQL. But again, there's that bias that I have. What do you think, Scott? Yeah, I mean, there's so much. I mean this has literally been my life for the last three years, both of these topics.

One, the Jamstack framework is just not catching up to what Jamstack is yet. A lot of these static site frameworks were made a long time ago and they just haven't been updated to what's coming and what's trending. So that could be one thing. Or for some of the newer ones, let's say like Next.js that does have static support, they are optimizing for getting you started as fast as possible and not having those opinions always be there. Like, sure, you could use GraphQL inside of Next.js. It's not native like Gatsby's is. Like, you have to talk to a GraphQL server that already has GraphQL and you can write the query. But they're trying to optimize for getting you started faster without having to add too many opinions on data fetching. They're trying to keep that agnostic as possible. So like Sid said, there's tradeoffs. Like, do you want to get started faster? Or do you want to save time later? Like, where do you want to be? And some frameworks decide that they want to help people get started faster. Less dependencies to know usually means that you've got more code to manage later on and it has to be tested and developers have to agree and all this other stuff. So there's tradeoffs. And I would say those are usually the two reasons why or why not a CMS or a Jamstack would choose GraphQL.

I mean, this has literally been my life for the last three years, both of these topics. So in a previous version of Type, I think we exclusively only supported GraphQL and there was a lot of learnings there. So, you know, touching on the topic of CMSs, there's really only two reasons why a CMS would or would support GraphQL. One is, is that CMS capable of serving what I call structured content. So we're talking like content that is more than just, here's some free-flowing content, like a blog post or, you know, something like that, like is there a structure, are there objects, are there arrays, is it some nested data, is this some relational data, which is big. Usually if that's the case, the CMS is going to support some type of graph API, whether it's something they made themselves in the cases of like sanity, or, you know, also opting into something like GraphQL, you're going to need something to handle those relationships. And I think there's like, it's kind of like a no-brainer.

But then again, like I said, you have some CMSs that are just like, we're just for blog posts. Well, maybe you don't really need GraphQL for that because you're really just getting back a big blob of text. So let me, what are you going to do with that? So, you know, that might not, they might not opt into that. As far as Jamstack goes, there's really only a couple of reasons. One, the Jamstack framework is just not catching up to what Jamstack is yet. You know, a lot of these static site, you know, frameworks were made a long time ago, and they just haven't been updated. So, you know, what's coming and what's trending. So that could be one thing, or for some of the newer ones, let's say like Next.js, that does have static support.

You know, they are optimizing for getting you started as fast as possible and not having those opinions always be there. Like, sure, you could use GraphQL inside of Next.js. It's not native like Gatsby's is, like, you have to talk to a GraphQL server that already has GraphQL and you can write the query. But they're trying to optimize for getting you started faster without having to add too many opinions on data fetching. They're trying to keep that agnostic as possible. So like Sid said, there's tradeoffs. Do you want to get started faster or do you want to save time later? Like, where do you want to be? And some frameworks decide that they want to help people get started faster.

Cool. Good insights. Yeah. It seems that there's a certain cost you need to pay up front if you want to use GraphQL. You know, unless you know GraphQL, you're already familiar with it. It seems to me also that on the LSCMS side of it, there is a huge GraphQL adoption. There's a lot of LSCMS that they provide GraphQL. But on the client side, the story is a bit different. There are less site generators that they go for GraphQL. And that actually makes me think about what is the role that GraphQL clients play on the Jamstack.

There's also an interesting question on the chat. On the Discord chat, if anyone has questions, you can put it there. Joanne is asking about limitations about the Jamstack in itself. So we are talking today about GraphQL and Jamstack. So I'm not sure we'll have time to answer this specific question about the Jamstack. But so the Jamstack, when I think of the Jamstack, is this idea where we optimize how web applications and websites will perform because we build things ahead of time, right? And we bring that content, and we build the website ahead of time. And then we have GraphQL, where I thought of GraphQL before knowing the Jamstack as this idea that we'll get data in an efficient way from server to client. And that makes me think when we put both together, what is the role that actually the GraphQL client plays here? Because if we bring all the data in an ideal scenario, or most cases, you were talking about the blog, if we bring all the data upfront, what's the role that GraphQL clients play here? Do we need to have some considerations here? Do we need new GraphQL clients? We don't need GraphQL clients at all. What are your thoughts on that?

Let me see. I could talk about that. I think it really just depends on the actual static site framework that you have. Each framework has different abilities to do certain things. Like for instance, if what I'm doing is pulling down content at build time, do I really need a client? It also depends on, is this a hyperpage? Is this a completely static page? Is it being server rendered in the case of next.js? Because if it's just a, I'm building this at build time. It's being served from a CDN. There's no interactivity on the client. I don't really need a GraphQL client. I don't need all the sweet caching and passing data from the server onto the client and hydrate. I don't need all that. It's just being built into just a static site. Someone can go here and turn off JavaScript and it's good to go.

But as the community moves forward and we move past just a static world where we move into a world where eventually things are static, or I'm sorry, they start off as static, but eventually they can be something else like hybrid or server rendered. Now you're like, okay, well, sure, I did render and get some content from GraphQL via server-side or build time. But now that I'm on the client-side, whether it's server-side rendering or just single-page application, maybe I do need a client. Maybe I do need to actually hydrate this client on the front-end with the call that was on the build time or the server render. And I want to make sure that it's good to go, the cache is warm, and et cetera. So I really just think it depends on how you're building your app. But like I said, it seems like Jamstack is moving towards the not just static anymore to everything is static, but you also get to opt-in to either the server-side rendering or a hybrid page. Yeah, I think that's a great answer. And I think in my head when I'm looking at GraphQL in a Jamstack site, there's two different places where it can be, right? It's either at build time or at run time, right? If you're using GraphQL at build time in a static site generator that supports it out-of-the-box, like Gatsby, you don't need a gap, you don't need another GraphQL client because we built one and our GraphQL client happens to know exactly what optimizations it can do with our GraphQL server that's running as your build happens. And we also strip it all out of your bundle. So when you get your site built and when you have your static assets, there's no GraphQL client in there because you don't need one because the data's already fetched and it's been inlined as JSON, right? So that's at build time.

But if you're running GraphQL queries at runtime, which there are perfectly valid reasons to do, I mean, for instance, if you have, let's say a site with a blog and with, you know, but where there's an app where you log in and then you have like a dashboard for users, it's very likely that that dashboard for users is going to be a single page app, you know, and in case it's not a single page app, even if it's, you whether it's server-side rendered or whether it's just a client-side single page app, you're going to want to run some queries or call some APIs at runtime. And if you're also using GraphQL for that, then you need a GraphQL client. So that's how I look at it. I look at it. If you're, you know, if you're thinking about build time or runtime, if it's built time and you're using something like Gatsby, you don't need a GraphQL client. And if it's runtime, then you do. And I mean, there's plenty and they give you a lot of stuff, right? But there's also that cost of including that. So I don't think they're mutually exclusive. Often for a large enough site that does most things that apps do these days, you probably need both, right? You're going to have some parts that are statically generated, and then you're going to have some kind of dashboard or some login experience, log-in experience, I'm sorry. So on the other hand, though, if you're using a static site generator that doesn't support GraphQL out of the box, and you're trying to sort of just call some arbitrary API and then render HTML and just leave it at that, you're probably going to want to include a GraphQL client. But you're also going to pay the cost of, you can sort of pick if that will go into your bundle or not. But again, those are decisions you need to make, and then there's a plan to pick and so on. So again, these aren't usually exclusive. You can do whatever works for you. But yeah, I think an easy way to sort of simplify these things is to think of build time and then runtime and sort of treat them differently because they're two different parts of your app almost. I don't know if that makes sense. Does that make sense?

Thank you very much. I think that's an important point. Build time and runtime maybe, I don't know, my thought is that we tend to build a lot of Jamstack sites that use a lot of real-time data consumption and so when we use, when we think of GraphQL on the client side, there's actually not much data to get from it. So I think that's very important, yeah, to very much run and build time.

Cool, thank you. Well, this is a GraphQL conference and so I assume there will be people that know GraphQL and might not know much about Jamstack. Actually we have some discussion on the chat. So what are your recommendations for those who know GraphQL and want to explore the Jamstack, where would you recommend them to start? Maybe tools, resources, use cases, yeah, maybe some recommendations for them.

So this answer is super biased. I'll just say go ahead and npm install gatsby-cli and build a Gatsby site. You don't have to write any code to have GraphQL work out-of-the-box, you can explore GraphQL, learn how to use it, write markdown content for your blog and then get a GraphQL interface that you can actually consume. So I think it's a great way to use what you already know with GraphQL, but eventually build a JAMstack site. On the other hand, you can also check out other frameworks that don't natively support GraphQL if that's not what you want. But if you want to use GraphQL and you want to build a JAMstack site, Gatsby is probably the easiest way to do that today. Because it just works out-of-the-box. So I'd recommend just going ahead and installing Gatsby using one of our starters or themes. If you hit something if you hit a snag, feel free to DM me or the rest of the team on Twitter. Always happy to help. Yeah. What Sid said, basically.

So if you're looking for JAMstack with GraphQL and you also want to use React, then Gatsby's pretty much the go-to there. They have great documentation. The framework's pretty dope. You got other options if you're, you know, you don't really need GraphQL natively or you want a different flavor of JavaScript. So if you prefer Vue, there's Gridsome, which is basically like a, you can think of as a heavily inspired framework from Gatsby, but made in Vue. You can try that one out. I haven't used the GraphQL integration since they had it, but I used Gridsome itself a long time ago. That was pretty dope. Next.js is also very, very good with JAMstack. It does not support GraphQL natively, but it's like a, it's a full stack framework.

It does not support GraphQL natively, but it's like a, it's a full stack framework. So it has some things in there. You could add GraphQL to Lambda functions if you want to, or even just call them with server side props and things like that. So you can pretty much do whatever you want there. It's just not supported natively.

Other than that, Oh, if you're into Angular, there's something out there called Oh man, he's gonna kill me if I don't say the name right now. Oh my goodness, what is it? Yeah, if you're into Angular, there's stuff out there for Angular. Sorry Aaron, I forgot the name of your static site generator. Yeah, so you got that. For me personally, if I had to choose one, my favorite, when I like Genesect, me personally, I like Next.js because I just like the full stack framework ness of it all. I just like to put everything there and then I can opt in to opt out to whatever I want. If I was just going to build something purely static, I would probably just go with Gatsby because that's what they do well. It's really good statically. I know GraphQL so I don't have a problem with it and I know that there's probably a plugin for that, right? Gatsby has a plugin for that. So like I literally don't have to make anything. So it really just depends on what you're doing but you can't really go wrong with either Gridsome, Next.js or Gatsby.

Yeah, that was cool. I anticipated you were going to talk a lot about tools. Are there any use cases that you would recommend them to, I don't know, is it a word, a blog, a good place to start if you know GraphQL? Or is an overkilling thing where in terms of use cases, what are the use cases you see more common for someone to get started? First of all the name of that Angular framework is called Scully with a C. So check that out, Scully. Pretty dope. Resources for learning GraphQL, I think, I don't know the exact name of it but I think it's called what is it? Learn GraphQL, maybe? I think it's made by Prisma. Or HowtoGraphQL, I think that's what it is. So HowtoGraphQL is a really good resource. I used that a lot in the early days when I was picking up GraphQL, so check that out. I also just like to read the GraphQL JS docs and specs. I don't know, that's just me. I'm just that person. I like to just read the specs in the docs. It just makes more sense to me.

I usually just read docs for like a getting started, and then after that it's just the source code and the specs. So that's kind of my thing. And then, actually, I think Gatsby does a really good job of explaining GraphQL, even though they're not GraphQL, right? They're a framework that uses GraphQL. Just by going to tutorials on how to consume data with GraphQL, you learn a lot there about the best ways to actually consume it in a way that makes sense for a static site. So, me personally, I think I don't like to go learn just new topics in isolation. I'm just gonna learn GraphQL. The way that I do things is I'm gonna build something and it's gonna use GraphQL, and then I kind of run into a problem, then I can ask that question and I can move forward, versus I'm gonna learn everything about GraphQL without building anything. No, it doesn't work that way. You don't need to know how a car works to drive it. So you don't really need to know how GraphQL works. You just need to know how to use it, and the best way to know how to use it is to build something with it. And the best way to build something with GraphQL right now is probably Gatsby. So just go build something with Gatsby and you'll learn enough about GraphQL that you feel comfortable with it.

Yeah, we did not pay Scott to say that, but thank you, Scott. And yeah, the Gatsby quick start tutorial, which is at gatsbyjs.com slash tutorial, how to build a blog with Gatsby from scratch. And it happens to also explain GraphQL in case like you didn't know it. And I think it's a fairly simple sort of explanation and an easy way to sort of go step by step. So check that out, maybe. Yeah, that's a good idea. And I would suggest for those who are maybe a bit more advanced, also a big fan of Gatsby, you can try to create plugins. I think Gatsby, that's something very interesting with GraphQL because you can extend the schema and you can build very interesting things. So I would say if you're a bit more advanced GraphQL user and you know a little bit of React, I would suggest, go and try to build plugins, Gatsby plugins. That's gonna be very interesting. And otherwise, yes, stay with some blog, some get started blog. It's a good place to start.

So next question, we are getting to to the end of it. What do you see is the future of this GraphQL and JAMstack? Do you think, what are the things you would like to see more about or things that we are going towards? And where is the future going with this GraphQL and JAMstack? Yeah, I can look into that. One thing that I'd like to see more and that we're also trying to sort of give more thought to is being able to sort of blur the lines between stuff that happens at runtime and build time. I already spoke about how you'd need a separate GraphQL client to be able to fetch data at runtime, in the app, right? Post the build. And one thing that we're sort of trying to do is blur that line, where all of that data that was available at build time, maybe is now available in a live endpoint as well. So, you don't really have to think too much about whether something is happening at runtime or build time, but you can still go back and query it the same and it just works. I think that will be really interesting because that might simplify things a lot. Yeah, that's one thing I'm looking forward to, personally. Yeah. Okay. For me, I would say the thing I'm looking forward to in the future with GraphQL and Jamstack is just an abstraction around GraphQL, to be honest. I think GraphQL is powerful, but I don't think everyone needs to know about GraphQL and how it works. And I think learning GraphQL with Jamstack is a turnoff to a lot of people because it can be intimidating. So we can find a way to where, hey, you're just going to create this data, you don't need to know how we're doing it, but if you want to look, we're doing this thing called GraphQL. I think just finding abstractions around GraphQL and Jamstack is going to be helpful.

Cool. Thank you very much. It was a great discussion. We've seen things we can build, why is this good, where the future is heading and some ways to get started. So I hope you enjoyed and take care and enjoy GraphQL and Jamstack. See you. Peace. Thank you.

You know, less dependencies to know usually means faster. But then, again, you've got more code to manage later on, and it has to be tested and developers have to agree and all this other stuff. So there's tradeoffs. And I would say those are usually the two reasons why or why not a CMS or a Jamstack would choose GraphQL.

Cool! Good insights. Yeah, it seems that there's a certain cost you need to pay upfront if you want to use GraphQL, you know. Unless you know GraphQL, you're very familiar with it. It seems to me also that on the LSCMS side of it, there is a huge GraphQL adoption. There are a lot of LSCMS that they provide GraphQL. But on the client side, the story is a bit different. There are less site generators that they go for GraphQL.

When I think of the Jamstack is this idea where we optimize how web applications and websites will perform because we build things ahead of time. And we bring that content and we build the website ahead of time. And then we have GraphQL where I thought of GraphQL before knowing the Jamstack as this idea that will get data in an efficient way from server to clients. And that makes me think when we put both together, what is the role that actually the GraphQL client plays here? Because if we bring all the data in an ideal scenario, or most cases, you were talking about the blog. If we bring all the data up front, what's the role that GraphQL clients play here?

But so the Jamstack, when I think of the Jamstack is this idea where we optimize how web applications and websites will perform because we build things ahead of time. And we bring that content and we build the website ahead of time. And then we have GraphQL where I thought of GraphQL before knowing the Jamstack as this idea that will get data in an efficient way from server to clients. And that makes me think when we put both together, what is the role that actually the GraphQL client plays here? Because if we bring all the data in an ideal scenario, or most cases, you were talking about the blog. If we bring all the data up front, what's the role that GraphQL clients play here? Do we need to have some considerations here? Do we need new GraphQL clients? We don't need GraphQL clients at all. What are your thoughts on that?

Let me see, I could talk about that. I think it really just depends on the actual static site framework that you have, right? Each framework has different abilities to do certain things. For instance, if what I'm doing is pulling down content at build time, do I really need a client? Well, it also depends on, is this a hybrid page? Is this a completely static page? Is it being server rendered in the case of Next.js, right? Because if it's just building this at build time, it's being served from a CDN, there's no interactivity on the client. I don't really need a GraphQL client, I don't need all the sweet caching and passing data from the server onto the client and hydrate, I don't need all that, right? It's just being built, it's just a static site, someone can go here and turn up JavaScript, and it's good to go.

But as the community moves forward, and we move past just a static world, where we're moving into a world where eventually things are static, but I'm sorry, they start off as static, but eventually they can be something else like hybrid or server rendered, now you're like, well, sure, I did render and get some content from GraphQL via server-side or build-time, but now that I'm on the client side, whether it's server-side rendering or just a single page application, maybe I do need a client. Maybe I do need to actually hydrate this client on the front end with the call that was on the build-time or the server render, and I want to make sure that is good to go. The cache is formed and et cetera. So I really just think it depends on how you're building your app.

So I really just think it depends on how you're building your app. But like I said, it seems like JAMstack is moving towards the not just static anymore to everything is static, but you also get to opt in to either server-side rendering or a hybrid page. Yeah, I think that's a great answer. And I think to add to that, in my head when I'm looking at GraphQL in a JAMstack site, there's two different places where it can be right. It's either at build time or at runtime, right.

If you're using GraphQL at build time in a static site generator that supports it out of the box like Gatsby, you don't need another GraphQL client because we built one. And our GraphQL client happens to know exactly what optimizations it can do with our GraphQL server that's running as your build happens. And we also strip it all out of your bundle. So when you get your site built in, when you have your static assets, there's no GraphQL client in there because you don't need one. Because the data is already fetched and it's been inlined as JSON, right. So that's at build time.

But if you're running GraphQL queries at runtime, which there are perfectly valid reasons to do, I mean, for instance, if you have, let's say, a site with a blog and with, you know, where there's an app where you log in and then you have like a dashboard for users. It's very likely that that dashboard for users is going to be a single page app, you know. And in case it's not a single page app, even if it's, you know, whether it's server-side rendered or whether it's just a client-side single page app, you're going to want to run some queries or call some APIs at runtime. And if you're also using GraphQL for that, then you'll need a GraphQL client. So that's how I'd look at it. I'd look at it if you're, you know, if you're thinking about build time or runtime, if it's build time and you're using something like Gatsby, you don't need a GraphQL client.

And if it's runtime, then you do. And there's, I mean, there's plenty and they give you a lot of stuff, right? But there's also that cost of including that. So I don't think they're mutually exclusive. Often for a large enough site that does most things that apps do these days, you probably need both, right? You're going to have some parts that are statically generated, and then you're going to have some kind of dashboard or some login experience. Login experience, I'm sorry. So on the other hand, though, if you're using a static site generator that doesn't support GraphQL out of the box, and you're trying to sort of just, you know, call some arbitrary API and then render HTML and just leave it at that, you're probably going to want to include a GraphQL client. But you're also going to pay the cost of, you know, you can sort of pick if that will go into your bundle or not. But again, that's those are decisions you need to make and then there's a plan to pick and so on. So again, these aren't mutually exclusive, you can do whatever works for you.

But yeah, I think an easy way to sort of simplify these things is to think of built time and then runtime and sort of treat them differently because they're two different parts of your app almost. I don't know if that makes sense. Does that make sense? Yeah, it does. Thank you very much. I think that's an important point, real time and runtime. And maybe I don't know, my thought is that we tend to build a lot of jumpstack sites that use a lot of real time data consumption. And so when we use when we think of GraphQL on the client side, there's actually not much data to get from it. So, I think that's very important. Yeah, to very much run and build time. Cool. Thank you.

So, well, this is a GraphQL conference. And so I assume there will be people that know GraphQL and might not know much about jumpstack. Actually, we're some discussion on the chat. So, what are your recommendations for those who know GraphQL and want to explore the jump stack? Where would you recommend them to start? Maybe tools, resources, use cases? Yeah, maybe some recommendations for them. So, this answer is super biased. I'll just say, go ahead and npm install Gatsby-cli and build a Gatsby site. You don't have to write any code to have GraphQL work out of the box. You can explore GraphQL, learn how to use it, write markdown content for your blog, and then get a GraphQL interface that you can actually consume. So, I think it's a great way to use what you already know with GraphQL, but eventually build a Jamstack site. On the other hand, you can also check out other frameworks that don't natively support GraphQL if that's not what you want. But if you want to use GraphQL and you want to build a Jamstack site, Gatsby is probably the easiest way to do that today. It just works out of the box. So, I'd recommend just going ahead, installing Gatsby, using one of our starters or themes. If you hit something and if you hit a snag, feel free to DM me or the rest of the team on Twitter. Always happy to help. Yeah, what Cyd said basically.

So, like if you're looking for, you know, Jamstack with GraphQL and you like, you know, and you're also want to use React, then, I mean, Gatsby's pretty much the go-to there. They have great documentation, framework's pretty dope. You got other options if you're, you know, you don't really need GraphQL natively or you want a different flavor of JavaScript, so if you prefer Vue, there's Gridsome, which is basically like you can use a heavily inspired framework from Gatsby but made in Vue. You can try that one out. I haven't used the GraphQL integration since they had it, but I used Gridsome itself a long time ago. It was pretty dope. Next.js is also very, very good with Jamstack. It does not support GraphQL natively, but it's like a, it's a full stack framework, so it has some things in there. You could add GraphQL to lambda functions if you want to or even just call them with server-side props and things like that. You can pretty much do whatever you want in there. It's just not supported natively. Other than that, if you're into Angular, there's something out there called, oh man, he's going to kill me if I don't say the name right now. Oh my goodness. What is it? Hold on, give me one second.

Angular. If you're into Angular, then I just- I can't remember the name. Best of luck. I mean, I'm kidding. If you're into Angular, there's stuff out there for Angular. Just Google it. Sorry, Aaron. Cross. I forgot the name of your static site generator. Yeah, so you got that.

For me personally, if I had to choose one, my favorite, when I like JANstack, me personally, I like Next.js because I just like the full stack framework-ness of it all. I just like to put everything there. And then I can opt-in to opt out to whatever I want. If I was just gonna build something purely static, I would probably just go with Gatsby because that's what they do well. It's really good statically. I know GraphQL, so I don't have a problem with it. And I know that there's probably a plug-in for that. Right. Gatsby has a plug-in for that. So I literally don't have to make anything. So it really just depends on what you're doing. But you can't really go wrong with either Gridsome, Next.js or Gatsby.

Yeah, that was cool. I anticipated you were going to talk a lot about tools. Are there any use cases that you would recommend them to... Is it a word? Sorry, a blog a good place to start if you know GraphQL, or it's an overkilling thing. Like in terms of use cases, what are the use cases that you see more common for someone to get started? First of all, the name of that Angular framework is called Scully. What a C. So, check that out. Scully.

Pretty dope. Resources for learning GraphQL, I think... I don't know the exact name of it, but I think it's called... What is it? Learn GraphQL, maybe? I think it's made by Prisma. Or HowtographQL. I think that's what it is. Yeah. So, HowtographQL is a really good resource. I used that a lot in the early days when I was picking up GraphQL, so check that out.

I also just like to read the GraphQL JS docs and specs. I don't know. That's just me. I'm just that person. I like to just read the specs and the docs. It just makes more sense to me. I usually just read docs for like a getting started, and then after that it's just the source code and the specs. So, that's kind of my thing.

And then actually I think Gatsby does a really good job of explaining GraphQL, even though they're not GraphQL, right? They're a framework that uses GraphQL, just by going to tutorials on how to consume data with GraphQL, you kind of learn a lot about the best ways to actually consume it in a way that makes sense for a static site. So, me personally, I think I don't like to go learn just new topics in isolation.

I'm just going to go learn GraphQL. The way that I do things is I'm going to build something, and it's going to use GraphQL, and then I kind of run into a problem. Then, I can ask that question, and I can move forward. Versus I'm going to learn everything about GraphQL without building anything. No, it doesn't work that way. You don't need to know how a car works to drive it. So, you don't really need to know how GraphQL works. You just need to know how to use it. And the best way to know how to use it is to build something with it. And the best way to build something with GraphQL right now is probably Gatsby.

So, just go build something with Gatsby, and you'll learn enough about GraphQL that you feel comfortable with it. Yeah. I did not, we did not pay Scott to say that, but thank you Scott. And yeah, the Gatsby quick start tutorial, which is at Gatsbyjs.com slash tutorial, walks you through how to build a blog with Gatsby from scratch. And it happens to also explain a lot of the things that we did in Gatsby. And I think it's a pretty, you know, it's a fairly simple sort of explanation and an easy way to sort of go step-by-step. So try, you know, check that out maybe.

I'm also a big fan of Gatsby, you can try to create plugins. I think Gatsby does something very interesting with GraphQL because you can extend the schema and you can build very interesting things. So if you're a bit more advanced GraphQL user and you know a little bit of React, I would suggest go and try to build plugins, Gatsby plugins. That's gonna be very interesting. And otherwise, yes, stay with some blog, some get started blog. It's a good place to start.

It's a good place to start. So next question. We are getting to the end of it. What do you see as the future of this GraphQL and JAMstack? Do you think, what are the things you would like to see more about or things that we are going towards and where is the future going with this GraphQL and JAMstack? Yeah, I can sort of look into that. One thing that I'd like to sort of see more and that we're also trying to sort of give more thought to is being able to sort of blur the lines between stuff that happens at runtime and build time. I earlier spoke about how you'd need a separate GraphQL client to be able to fetch data at runtime, in your app, post the build. One thing that we're sort of trying to do is blur that line where all of that data that was available at build time may be now available in a live endpoint as well. You don't really have to think too much about whether something is happening at runtime or at build time, but you can go back and query it the same way and it just works. I think that that will be really interesting because that might simplify things a lot. That's one thing I'm looking forward to, personally.

For me, I would say the thing I'm looking forward to in the future with GraphQL and Jamstack is just an abstraction around GraphQL, to be honest. I think GraphQL is powerful, but I don't think everyone needs to know about GraphQL and how it works. I think learning GraphQL with Jamstack is a turnoff to a lot of people because it can be intimidating. We can find a way to where, hey, you're just going to create this data. You don't need to know how we're doing it, but if you want to look, we're doing this thing called GraphQL. I think just finding abstractions around GraphQL and Jamstack is going to be helpful. Cool. Thank you very much, it was a great discussion. We've seen things we can build, why is this good, where the future is heading, and some ways to get started. I hope you enjoyed, and yeah, take care, and enjoy GraphQL and Jamstack. See ya. Peace. Thank you. Bye.