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 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 that's going to last or what's coming after this? 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 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. And yeah, 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. We 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 and how 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 we'll 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 the company, just a really big fan of jamstack and graphql. Thank you, Scott. So let's go straight to it. Why graphql and the jamstack are a good match? Why is it? You want me to start? Okay. I know you're talking. All right. 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 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 is specifically from the client side, is meant to follow some of those same guidelines. You only want to get the data that you asked for and nothing more. You want to limit how much formatting you have to do before you throw it in a render, 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, 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. If you want to use a service that helps you build out forms, that could have a separate api, which you could call. Or if you want to embed comments from Disqus maybe or some other platform, you could use its own api. And the idea is that you use the best tool for the job and you don't reinvent the wheel for everything. I think graphql turns out to be a really good interface 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, their own APIs and with 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. 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 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 Tattoo CMS 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 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 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 in gatsby is 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 don't have to understand the sort of shape of every single api independently. Just write a query, which you can sort of auto complete in graphql 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, hella 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 these unify a language that can help connecting and simplify all these mesh that you were mentioning, Sid? 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 WP graphql. And if you 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 for sort of instance of it. And that's where WP graphql came from because it turns out a lot of these were wordpress instances and WP graphql sort of does a great way to sort of syndicate data between them. So coming back to 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 OneGraph and the sort that let you, that sort of let you consume them together. I think gatsby is also an example there, whereas while you can't run that in production, you could use it 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, 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 going to 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 going to 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, or to build, or even sometimes run time, 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. 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. So I was looking at the jamstack.org website yesterday and I was looking at the different headless CMS and site generators, and there are a lot. And I was looking at which ones are using graphql and both on the headless CMS and on the site generator side of it. And not all of them use graphql. Not all the site 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, right? I've read a lot of issues, I've 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 sort of 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. Like 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 trade off 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, or that code that, I mean, it's code that could, 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, like 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 site 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, 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 code you have to write. With gatsby, you don't need to write any of that. I think that's what sort of 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 sort of 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, you know, 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 auto-complete. 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, 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 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 CMSs, 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 about content that is more than just here's some free flowing content like a blog post or something like that. Like, is there structure, are there objects, are there arrays? Is it some nested data, is it 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 case of something 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 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, you know, that might not, 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. You know, a lot of these static site, you know, frameworks were made a long time ago and they just haven't been updated to, you know, what's coming and what's trending. So that could be one thing. But 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 trade-offs. 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. You know, less dependencies to know usually means faster, but then again, you got more code to manage later on and, you know, it has to be tested and developers have to agree and all this other stuff. So there's trade-offs. 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 certain costs 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? This is 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 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. 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 like 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 in 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 into either server side rendering or a hybrid page. Yeah, I think that's a great answer. And I think to sort of 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 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 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 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 run time, which there are perfectly valid reasons to do. I mean, for instance, if you have, let's say a site with a blog and 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. And in case it's not a single page app, even if it's, 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 run time. 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 run time, if it's built time and you're using something like gatsby, you don't need a graphql client. And if it's run time, 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 log in 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, 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 client 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 build time and then run time 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, build time and run time. Maybe, I don't know, my thought is that we tend to build a lot of jamstack sites that use a lot of build 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 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 jamstack. Actually, there were 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. Yeah, go ahead. This answer is super biased. I'll just say go ahead and, you know, 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, you know, 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. And I mean, if you hit something and if you get 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 like if you're looking for, you know, jamstack with graphql and you like, you know, and you're also wanting to use react, then I mean, gatsby is 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 think of as a heavily inspired framework from gatsby, but made in vue. You could 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. So you can pretty much do whatever you want in 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 going to kill me if I don't say the name right now. Oh my goodness. What is it? Hold on. Let me see if I can get static site angular. If you're into angular, then I just, I can't remember the name of it. I mean, I'm kidding. If you're into angular, there's stuff out there for angular. Just Google it. 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, I like next.js because I like the full stack frameworkness of it all. I like to put everything there and 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, there's a plug-in for that. gatsby has a plug-in 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, like, is it a word, sorry, a blog, a good place to start if you know graphql or it's an overkilling thing where 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 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 like, what is it? Learn graphql maybe? I think it's made by like prisma and, oh, how to graphql. I think that's what it is. Yeah. So how to graphql is a really good resource. I've learned, I use 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 I 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 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 going to learn graphql. Like the way that I do things, it's like I'm going to build something and it's going to use graphql. And then I kind of run into a problem that I can ask that question and I can move forward versus like, I'm going to learn everything about graphql without building anything. Like 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 graphql in case like you didn't know it. 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. Yeah, that's a good idea. And I would suggest for those who are maybe a bit more advanced, I'm also a big fan of gatsby, you can try to create plugins. I think gatsby does something very interesting with a graphql because you can extend the schema and you can build very interesting things. So if 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 going to 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 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 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 already spoke about how you'd need a separate graphql client to be able to fetch data at runtime in your 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 on 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 go back and query it the same way 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 yeah, take care and enjoy graphql and jamstack. See you. Peace. Thank you. Bye-bye.