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.

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.

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.

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.

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 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.

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.

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.

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.