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 <a href="/tags/jamstack/talks">JAMstack</a>. One of the things I like about the <a href="/tags/jamstack/talks">JAMstack</a> 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 <a href="/tags/ecosystem/talks">ecosystem</a>. And I wonder how can <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/gatsby/talks">Gatsby</a>, built WPGraphQL. And if you rewind back to why he built it, before it became a <a href="/tags/gatsby/talks">Gatsby</a>-sponsored project, and because we realized that a lot of the users that were using it were actually using it with <a href="/tags/gatsby/talks">Gatsby</a>, 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 <a href="/tags/data/talks">data</a> 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 <a href="/tags/wordpress/talks">WordPress</a> instances, and WPGraphQL served as a great way to syndicate <a href="/tags/data/talks">data</a> 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 <a href="/tags/gatsby/talks">Gatsby</a> 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 <a href="/tags/jamstack/talks">Jamstack</a> app and I need to pull in content or <a href="/tags/data/talks">data</a> 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 <a href="/tags/graphql/talks">GraphQL</a>, I completely eliminate that application code and the logic for what the structure of that <a href="/tags/data/talks">data</a> 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 <a href="/tags/graphql/talks">GraphQL</a> because of the <a href="/tags/type safety/talks">type safety</a> 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 <a href="/tags/graphql/talks">GraphQL</a> offers <a href="/tags/jamstack/talks">JAMstack</a> 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 <a href="/tags/data/talks">data</a> 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 <a href="/tags/jamstack/talks">JAMstack</a>.org website yesterday and I was looking at the different <a href="/tags/headless cms/talks">headless CMS</a> and side generators and there are a lot. And I was looking at which ones had, or using <a href="/tags/graphql/talks">GraphQL</a> and both on the <a href="/tags/headless cms/talks">headless CMS</a> and on the side generator side of it. And not all of them use <a href="/tags/graphql/talks">GraphQL</a>, not all the side generators use <a href="/tags/graphql/talks">GraphQL</a> and not all the <a href="/tags/headless cms/talks">headless CMS</a> use <a href="/tags/graphql/talks">GraphQL</a>. 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 <a href="/tags/gatsby/talks">Gatsby</a> uses <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/gatsby/talks">Gatsby</a> really uses <a href="/tags/graphql/talks">GraphQL</a>.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 <a href="/tags/react/talks">React</a> 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 <a href="/tags/graphql/talks">GraphQL</a>, and that's great because you don't have to learn <a href="/tags/graphql/talks">GraphQL</a>. And if you don't know <a href="/tags/graphql/talks">GraphQL</a>, that might seem like the best way to go. But you're going to have to write imperative code for every single other <a href="/tags/data/talks">data</a> source that you need to fetch <a href="/tags/data/talks">data</a> from. And that code adds up over time. It's code you have to maintain. It's code you have to <a href="/tags/debug/talks">debug</a>. It's code that you have to help other developers understand. And it's also code that runs at the <a href="/tags/runtime/talks">runtime</a>, 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 <a href="/tags/gatsby/talks">Gatsby</a>, if you don't know <a href="/tags/graphql/talks">GraphQL</a>, there's definitely a learning curve, and there's that initial upfront cost to have to pay to understand <a href="/tags/graphql/talks">GraphQL</a> and learn it and then start writing your queries. But, the beauty of it then is that if you've consumed one <a href="/tags/data/talks">data</a> source in <a href="/tags/gatsby/talks">Gatsby</a>, you can probably consume any other <a href="/tags/data/talks">data</a> source using a plug-in. Like just install it and it'll work. Because you know how to write a query, you know what <a href="/tags/graphql/talks">GraphQL</a> 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.

Thank you everyone for joining us today. This is Alex Lobera. I'm an independent software developer and coach, maybe best known as the <a href="/tags/react/talks">React</a> <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/graphql/talks">GraphQL</a> and the <a href="/tags/jamstack/talks">JAMstack</a> 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.

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 <a href="/tags/gatsby/talks">Gatsby</a> Inc. <a href="/tags/gatsby/talks">Gatsby</a> 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 <a href="/tags/gatsby/talks">Gatsby</a> <a href="/tags/cloud/talks">Cloud</a>, which is a <a href="/tags/cloud/talks">Cloud</a> platform that helps build your <a href="/tags/gatsby/talks">Gatsby</a> 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 <a href="/tags/headless cms/talks">headless CMS</a>. 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 <a href="/tags/data/talks">data</a> with the schema, we do the rest. Most of our product is <a href="/tags/open-source/talks">open-source</a>, we just handle the API and the infrastructure and all the hard stuff for you. We basically have integrations with <a href="/tags/frameworks/talks">frameworks</a> like <a href="/tags/gatsby/talks">Gatsby</a> and <a href="/tags/next.js/talks">Next.js</a> 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 <a href="/tags/jamstack/talks">JAMstack</a>, <a href="/tags/graphql/talks">GraphQL</a>, 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 <a href="/tags/jamstack/talks">JAMstack</a> and <a href="/tags/graphql/talks">GraphQL</a>.

Thank you, Scott. So, let's go straight to it. Why are <a href="/tags/graphql/talks">GraphQL</a> and <a href="/tags/jamstack/talks">JAMstack</a> 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 <a href="/tags/jamstack/talks">JAMstack</a>, <a href="/tags/jamstack/talks">JAMstack</a> was manifested for the sake of <a href="/tags/performance/talks">performance</a> as in <a href="/tags/runtime/talks">runtime</a> <a href="/tags/performance/talks">performance</a>, but also being able to not sacrifice the <a href="/tags/tooling/talks">tooling</a> that we use and being able to use <a href="/tags/javascript/talks">JavaScript</a>. And <a href="/tags/graphql/talks">GraphQL</a>, specifically from the client side, is meant to follow some of those same guidelines. You only want to get the <a href="/tags/data/talks">data</a> 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 <a href="/tags/type safety/talks">type safety</a>. 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 <a href="/tags/jamstack/talks">JAMstack</a> where there's a fairly high likelihood that your site is going to go request <a href="/tags/data/talks">data</a> from multiple different sources. And at <a href="/tags/gatsby/talks">Gatsby</a> 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 <a href="/tags/forms/talks">forms</a>, 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 <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/graphql/talks">GraphQL</a> is great, because it gives you one sort of shared interface to be able to fetch or consume <a href="/tags/data/talks">data</a> from all these sources, right? That idea is really first class in <a href="/tags/gatsby/talks">Gatsby</a>. And that's what that's what <a href="/tags/graphql/talks">GraphQL</a> is all about. In <a href="/tags/gatsby/talks">Gatsby</a>, you can use <a href="/tags/data/talks">data</a> 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 <a href="/tags/wordpress/talks">WordPress</a>, 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 <a href="/tags/graphql/talks">GraphQL</a>, in that case. And you happen to get <a href="/tags/documentation/talks">documentation</a> out of the box with <a href="/tags/graphql/talks">GraphQL</a>. I think that's really powerful. And with that, there's also the matter of simplicity.

I think the <a href="/tags/jamstack/talks">Jamstack</a> 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 <a href="/tags/gatsby/talks">Gatsby</a>, is great. And I think <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/jamstack/talks">JAMstack</a> and <a href="/tags/graphql/talks">GraphQL</a>. And that's one of the reasons why <a href="/tags/gatsby/talks">Gatsby</a> uses <a href="/tags/graphql/talks">GraphQL</a> so extensively.

But you get sort of, you know, it's self-documenting out of the box. That's one of my favorite things about <a href="/tags/graphql/talks">GraphQL</a>, 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 <a href="/tags/data/talks">data</a> sources, I think, is what sort of really separates <a href="/tags/gatsby/talks">Gatsby</a> 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 <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/data/talks">data</a> sources or <a href="/tags/wordpress/talks">WordPress</a>, 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 <a href="/tags/gatsby/talks">Gatsby</a>, you don't need to write any of that. I think that's what separates <a href="/tags/gatsby/talks">Gatsby</a> from other static site generators when it comes to <a href="/tags/graphql/talks">GraphQL</a> itself.To touch on the second part of your question, which is CMSs that support <a href="/tags/graphql/talks">GraphQL</a> natively versus not. I think it's a huge DX win when a CMS supports <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/data/talks">data</a> or how I'm able to fetch it. With <a href="/tags/graphql/talks">GraphQL</a>, 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 <a href="/tags/graphql/talks">GraphQL</a>. 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 <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/graphql/talks">GraphQL</a>. 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 <a href="/tags/data/talks">data</a>, some relational <a href="/tags/data/talks">data</a> 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 <a href="/tags/graphql/talks">GraphQL</a>, 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 <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/jamstack/talks">Jamstack</a> goes, there's really only a couple of reasons.

One, the <a href="/tags/jamstack/talks">Jamstack</a> framework is just not catching up to what <a href="/tags/jamstack/talks">Jamstack</a> is yet. A lot of these static site <a href="/tags/frameworks/talks">frameworks</a> 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 <a href="/tags/next.js/talks">Next.js</a> 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 <a href="/tags/graphql/talks">GraphQL</a> inside of <a href="/tags/next.js/talks">Next.js</a>. It's not native like <a href="/tags/gatsby/talks">Gatsby</a>'s is. Like, you have to talk to a <a href="/tags/graphql/talks">GraphQL</a> server that already has <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/data/talks">data</a> 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 <a href="/tags/frameworks/talks">frameworks</a> 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 <a href="/tags/jamstack/talks">Jamstack</a> would choose <a href="/tags/graphql/talks">GraphQL</a>.

Cool. Good insights. Yeah. It seems that there's a certain cost you need to pay up front if you want to use <a href="/tags/graphql/talks">GraphQL</a>. You know, unless you know <a href="/tags/graphql/talks">GraphQL</a>, you're already familiar with it. It seems to me also that on the LSCMS side of it, there is a huge <a href="/tags/graphql/talks">GraphQL</a> adoption. There's a lot of LSCMS that they provide <a href="/tags/graphql/talks">GraphQL</a>. But on the client side, the story is a bit different. There are less site generators that they go for <a href="/tags/graphql/talks">GraphQL</a>. And that actually makes me think about what is the role that <a href="/tags/graphql/talks">GraphQL</a> clients play on the <a href="/tags/jamstack/talks">Jamstack</a>.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 <a href="/tags/jamstack/talks">Jamstack</a> in itself. So we are talking today about <a href="/tags/graphql/talks">GraphQL</a> and <a href="/tags/jamstack/talks">Jamstack</a>. So I'm not sure we'll have time to answer this specific question about the <a href="/tags/jamstack/talks">Jamstack</a>. But so the <a href="/tags/jamstack/talks">Jamstack</a>, when I think of the <a href="/tags/jamstack/talks">Jamstack</a>, 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 <a href="/tags/graphql/talks">GraphQL</a>, where I thought of <a href="/tags/graphql/talks">GraphQL</a> before knowing the <a href="/tags/jamstack/talks">Jamstack</a> as this idea that we'll get <a href="/tags/data/talks">data</a> 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 <a href="/tags/graphql/talks">GraphQL</a> client plays here? Because if we bring all the <a href="/tags/data/talks">data</a> in an ideal scenario, or most cases, you were talking about the blog, if we bring all the <a href="/tags/data/talks">data</a> upfront, what's the role that <a href="/tags/graphql/talks">GraphQL</a> clients play here? Do we need to have some considerations here? Do we need new <a href="/tags/graphql/talks">GraphQL</a> clients? We don't need <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/next.js/talks">next.js</a>? 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 <a href="/tags/graphql/talks">GraphQL</a> client. I don't need all the sweet caching and passing <a href="/tags/data/talks">data</a> 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 <a href="/tags/javascript/talks">JavaScript</a> and it's good to go.

But as the <a href="/tags/community/talks">community</a> 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 <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/jamstack/talks">Jamstack</a> 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 <a href="/tags/graphql/talks">GraphQL</a> in a <a href="/tags/jamstack/talks">Jamstack</a> 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 <a href="/tags/graphql/talks">GraphQL</a> at build time in a static site generator that supports it out-of-the-box, like <a href="/tags/gatsby/talks">Gatsby</a>, you don't need a gap, you don't need another <a href="/tags/graphql/talks">GraphQL</a> client because we built one and our <a href="/tags/graphql/talks">GraphQL</a> client happens to know exactly what optimizations it can do with our <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/graphql/talks">GraphQL</a> client in there because you don't need one because the <a href="/tags/data/talks">data</a>'s already fetched and it's been inlined as JSON, right? So that's at build time.

But if you're running <a href="/tags/graphql/talks">GraphQL</a> queries at <a href="/tags/runtime/talks">runtime</a>, 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 <a href="/tags/runtime/talks">runtime</a>. And if you're also using <a href="/tags/graphql/talks">GraphQL</a> for that, then you need a <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/runtime/talks">runtime</a>, if it's built time and you're using something like <a href="/tags/gatsby/talks">Gatsby</a>, you don't need a <a href="/tags/graphql/talks">GraphQL</a> client. And if it's <a href="/tags/runtime/talks">runtime</a>, 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 <a href="/tags/graphql/talks">GraphQL</a> out of the box, and you're trying to sort of just call some arbitrary API and then render <a href="/tags/html/talks">HTML</a> and just leave it at that, you're probably going to want to include a <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/runtime/talks">runtime</a> 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 <a href="/tags/runtime/talks">runtime</a> maybe, I don't know, my thought is that we tend to build a lot of <a href="/tags/jamstack/talks">Jamstack</a> sites that use a lot of real-time <a href="/tags/data/talks">data</a> consumption and so when we use, when we think of <a href="/tags/graphql/talks">GraphQL</a> on the client side, there's actually not much <a href="/tags/data/talks">data</a> 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 <a href="/tags/graphql/talks">GraphQL</a> conference and so I assume there will be people that know <a href="/tags/graphql/talks">GraphQL</a> and might not know much about <a href="/tags/jamstack/talks">Jamstack</a>. Actually we have some discussion on the chat. So what are your recommendations for those who know <a href="/tags/graphql/talks">GraphQL</a> and want to explore the <a href="/tags/jamstack/talks">Jamstack</a>, 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 <a href="/tags/npm/talks">npm</a> install <a href="/tags/gatsby/talks">gatsby</a>-<a href="/tags/CLI/talks">cli</a> and build a <a href="/tags/gatsby/talks">Gatsby</a> site. You don't have to write any code to have <a href="/tags/graphql/talks">GraphQL</a> work out-of-the-box, you can explore <a href="/tags/graphql/talks">GraphQL</a>, learn how to use it, write markdown content for your blog and then get a <a href="/tags/graphql/talks">GraphQL</a> interface that you can actually consume. So I think it's a great way to use what you already know with <a href="/tags/graphql/talks">GraphQL</a>, but eventually build a <a href="/tags/jamstack/talks">JAMstack</a> site. On the other hand, you can also check out other <a href="/tags/frameworks/talks">frameworks</a> that don't natively support <a href="/tags/graphql/talks">GraphQL</a> if that's not what you want. But if you want to use <a href="/tags/graphql/talks">GraphQL</a> and you want to build a <a href="/tags/jamstack/talks">JAMstack</a> site, <a href="/tags/gatsby/talks">Gatsby</a> 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 <a href="/tags/gatsby/talks">Gatsby</a> 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 <a href="/tags/jamstack/talks">JAMstack</a> with <a href="/tags/graphql/talks">GraphQL</a> and you also want to use <a href="/tags/react/talks">React</a>, then <a href="/tags/gatsby/talks">Gatsby</a>'s pretty much the go-to there. They have great <a href="/tags/documentation/talks">documentation</a>. The framework's pretty dope. You got other options if you're, you know, you don't really need <a href="/tags/graphql/talks">GraphQL</a> natively or you want a different flavor of <a href="/tags/javascript/talks">JavaScript</a>. So if you prefer <a href="/tags/vue/talks">Vue</a>, there's Gridsome, which is basically like a, you can think of as a heavily inspired framework from <a href="/tags/gatsby/talks">Gatsby</a>, but made in <a href="/tags/vue/talks">Vue</a>. You can try that one out. I haven't used the <a href="/tags/graphql/talks">GraphQL</a> integration since they had it, but I used Gridsome itself a long time ago. That was pretty dope. <a href="/tags/next.js/talks">Next.js</a> is also very, very good with <a href="/tags/jamstack/talks">JAMstack</a>. It does not support <a href="/tags/graphql/talks">GraphQL</a> natively, but it's like a, it's a full stack framework.

It does not support <a href="/tags/graphql/talks">GraphQL</a> natively, but it's like a, it's a full stack framework. So it has some things in there. You could add <a href="/tags/graphql/talks">GraphQL</a> to <a href="/tags/lambda/talks">Lambda</a> 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 <a href="/tags/angular/talks">Angular</a>, 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 <a href="/tags/angular/talks">Angular</a>, there's stuff out there for <a href="/tags/angular/talks">Angular</a>. 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 <a href="/tags/next.js/talks">Next.js</a> 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 <a href="/tags/gatsby/talks">Gatsby</a> because that's what they do well. It's really good statically. I know <a href="/tags/graphql/talks">GraphQL</a> so I don't have a problem with it and I know that there's probably a plugin for that, right? <a href="/tags/gatsby/talks">Gatsby</a> 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, <a href="/tags/next.js/talks">Next.js</a> or <a href="/tags/gatsby/talks">Gatsby</a>.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 <a href="/tags/graphql/talks">GraphQL</a>? 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 <a href="/tags/angular/talks">Angular</a> framework is called Scully with a C. So check that out, Scully. Pretty dope. Resources for learning <a href="/tags/graphql/talks">GraphQL</a>, I think, I don't know the exact name of it but I think it's called what is it? Learn <a href="/tags/graphql/talks">GraphQL</a>, maybe? I think it's made by <a href="/tags/prisma/talks">Prisma</a>. 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 <a href="/tags/graphql/talks">GraphQL</a>, so check that out. I also just like to read the <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/gatsby/talks">Gatsby</a> does a really good job of explaining <a href="/tags/graphql/talks">GraphQL</a>, even though they're not <a href="/tags/graphql/talks">GraphQL</a>, right? They're a framework that uses <a href="/tags/graphql/talks">GraphQL</a>. Just by going to tutorials on how to consume <a href="/tags/data/talks">data</a> with <a href="/tags/graphql/talks">GraphQL</a>, 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 <a href="/tags/graphql/talks">GraphQL</a>. The way that I do things is I'm gonna build something and it's gonna use <a href="/tags/graphql/talks">GraphQL</a>, 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 <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/graphql/talks">GraphQL</a> right now is probably <a href="/tags/gatsby/talks">Gatsby</a>. So just go build something with <a href="/tags/gatsby/talks">Gatsby</a> and you'll learn enough about <a href="/tags/graphql/talks">GraphQL</a> that you feel comfortable with it.

Yeah, we did not pay Scott to say that, but thank you, Scott. And yeah, the <a href="/tags/gatsby/talks">Gatsby</a> quick start tutorial, which is at gatsbyjs.com slash tutorial, how to build a blog with <a href="/tags/gatsby/talks">Gatsby</a> from scratch. And it happens to also explain <a href="/tags/graphql/talks">GraphQL</a> 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 <a href="/tags/advanced/talks">advanced</a>, also a big fan of <a href="/tags/gatsby/talks">Gatsby</a>, you can try to create plugins. I think <a href="/tags/gatsby/talks">Gatsby</a>, that's something very interesting with <a href="/tags/graphql/talks">GraphQL</a> because you can extend the schema and you can build very interesting things. So I would say if you're a bit more <a href="/tags/advanced/talks">advanced</a> <a href="/tags/graphql/talks">GraphQL</a> user and you know a little bit of <a href="/tags/react/talks">React</a>, I would suggest, go and try to build plugins, <a href="/tags/gatsby/talks">Gatsby</a> 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 <a href="/tags/graphql/talks">GraphQL</a> and <a href="/tags/jamstack/talks">JAMstack</a>? 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 <a href="/tags/graphql/talks">GraphQL</a> and <a href="/tags/jamstack/talks">JAMstack</a>? 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 <a href="/tags/runtime/talks">runtime</a> and build time. I already spoke about how you'd need a separate <a href="/tags/graphql/talks">GraphQL</a> client to be able to fetch <a href="/tags/data/talks">data</a> at <a href="/tags/runtime/talks">runtime</a>, 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 <a href="/tags/data/talks">data</a> 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 <a href="/tags/runtime/talks">runtime</a> 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 <a href="/tags/graphql/talks">GraphQL</a> and <a href="/tags/jamstack/talks">Jamstack</a> is just an abstraction around <a href="/tags/graphql/talks">GraphQL</a>, to be honest. I think <a href="/tags/graphql/talks">GraphQL</a> is powerful, but I don't think everyone needs to know about <a href="/tags/graphql/talks">GraphQL</a> and how it works. And I think learning <a href="/tags/graphql/talks">GraphQL</a> with <a href="/tags/jamstack/talks">Jamstack</a> 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 <a href="/tags/data/talks">data</a>, you don't need to know how we're doing it, but if you want to look, we're doing this thing called <a href="/tags/graphql/talks">GraphQL</a>. I think just finding abstractions around <a href="/tags/graphql/talks">GraphQL</a> and <a href="/tags/jamstack/talks">Jamstack</a> 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 <a href="/tags/graphql/talks">GraphQL</a> and <a href="/tags/jamstack/talks">Jamstack</a>. See you. Peace. Thank you.

GraphQL Galaxy

GraphQL Galaxy 2020

GraphQL + JAMStack - Panel Discussion

Sid Chatterjee

Alex Lobera

Scott Moss

TestJS Summit

TestJS Summit 2023

React Day Berlin

React Day Berlin 2023

TechLead Conference

I'm attending TechLead Conference 2023 – get your free remote ticket and join me there

TechLead Conference 2024

DevOps.js

DevOps.js Conf 2024

Node Congress

I’m attending @NodeCongress, the biggest conf on #JavaScript backends – by clicking the badge you may get free remote ticket & join me there with 5k other #nodejs devs & 35 great speakers #deno #cloudflare #awscloud

Node Congress 2024

Vue.js Live Conference

I'm attending Vue.js Live 2023 – get your free remote ticket and join me there with 10k other Vue.js engineers and 35 great speakers

Vue.js Live 2024

JS Nation

I’m attending JSNation – the main JavaScript conference of the year. You may join me there for free with 10k other JS engineers and 40+ great speakers. Just follow this badge.

JSNation 2024

React Summit

I am attending the biggest #Reactjs conference remotely. You may get a limited free ticket (50% of talks, no workshops) and join me by clicking this badge.

GraphQL + JAMStack - Panel Discussion

Comments