Exploring the WordPress Graph with Next.js & WPGraphQL

Rate this content

Headless Wordpress using its built-in REST API is a powerful solution to scale WordPress to the web, but complex relationships can easily turn into chains of requests, making maintainability difficult along with the potential cost of performance.

With WPGraphQL, we can harness the benefits of GraphQL, leading to a better developer experience and optimized request logic, making sure we’re only delivering what we need to our users.

We’ll explore these advantages and how these pieces fit together with modern tools like Next.js to build great experiences for the web.

Slides & more

23 min
09 Dec, 2021

Video Summary and Transcription

WordPress is widely used, and it now supports a REST API for headless usage. Serving static HTML files allows for infinite scaling and surviving viral traffic. GraphQL can be used to interface with WordPress data, reducing complexity. WordPress can be coupled with plugins like Yoast and ACF, and WPGraphQL works seamlessly with these plugins. GraphQL allows for selecting only necessary data and has performance advantages over REST APIs.

Available in Español

1. Introduction to WordPress and Headless CMS

Short description:

WordPress is still widely used, with 37% of the top one million sites using it. It now supports a REST API, allowing for headless usage. Static site generators and modern web frameworks can do the heavy lifting before the page loads, avoiding the need for client-side requests to WordPress.


You can pretty much find me anywhere on the web by just Googling my name, as I'm the only one in the world. So let's start off by addressing the CMS in the room. It's 2021, and some developers would still cringe at the thought of using WordPress. But frankly, we're still living in a WordPress world. According to Build With Trends a little bit ago, if we look at the CMS distribution of the top one million sites, 37% of websites are using WordPress. That's a huge percentage. And I'm sure it's gonna have gone up by now, and I'm not quite sure how accurate it is, but if you look at the number of detections on the Build With site, it's over 960 million installs of WordPress. That's almost one billion. That's a staggering number.

While we might not all want to use WordPress, it's realistically around to stay for the foreseeable future. But hold up, why am I even talking about WordPress? Well, jumping back a bit, WordPress, as we traditionally know it, is an all-in-one CMS and website solution. It works side to grab all the data from the database, render it to HTML, and then send it over to the browser. But since 4.7, WordPress now supports a REST API. This means right out of the box we actually can use WordPress headlessly. If you haven't heard of the term headless before, what does that actually mean? Well, with our traditional stack like WordPress, somebody will visit a page in the browser. The browser reaches out to the server, the server will do the work like make those requests to the database, render the HTML for the page, and then send that response. If we're lucky, it'll return it cached. Finally, the browser will display that response to the person who's visiting that site. With a headless approach, that request to the server might be asynchronous on the client. In this particular example, the person would visit a page in their browser and immediately get a response straight from storage. Once that page loads inside of the browser, the browser will kick off another request to a server which can load all of that dynamic content. But I would imagine you probably wondering why would we want to make a client-side request to WordPress for a CMS? That's not necessarily the recommended approach. That's where static site generators and modern web frameworks come in. They do all the hard lifting before the page actually hits the browser. We can use front-end frameworks to get all that data at compile time or with server-side rendering, avoiding that cost inside of the browser. Now, if this all sounds new to you, it might sound like a lot of work. Why not even, why even bother with an API? Why not use WordPress out of the box like we always do? So let's focus on this example of using an API with a static site, where the only time we reach out to that API is at compile time. And we store the HTML files directly in storage. We get a lot of benefits from actually avoiding hitting the server directly on each of those requests. With most of our base solutions, server-based solutions like WordPress, there's a lot of options to help speed things up.

2. WordPress and Headless CMS

Short description:

WordPress plugins and custom work can help with caching, but each page is still a server hit. Static HTML files, served from storage or a CDN, are faster. Load balancing and auto scaling are not perfect solutions. Serving static HTML files allows for infinite scaling and surviving viral traffic. Storage is cheap, and managing servers can be costly. The REST API in WordPress allows for fetching all data, including blog posts and author information.

For WordPress specifically, that includes some plugins to cache or some custom work under the hood, but each page is still a server hit, which is still prone to its ups and downs. On the other hand, with our statically compiled site, a static HTML file is just going to be fast. Instead of spending time rendering on a server, you serve a static file straight from storage or a CDN. While you can do this by default with WordPress, it's often much more complicated. And some of the plugins that cache might serve an HTML file, but they still serve it from a regular server, not static storage.

With any server, we're typically paying for how much we expect our traffic to be. While most of the time that is predictable, we all hope to one day have a viral post, and if that happens, the people visiting our site will be the ones paying for it with slow speeds or timeouts. There are solutions like load balancing and auto scaling, but those aren't perfect solutions, and we might not always be able to handle that certain traffic.

Back to the fact that we're serving static HTML files, because we're serving files straight from storage, or better yet, statically from the CDN, buzzword alert, that means our user-facing website is going to infinitely scale. That static site will survive the Reddit hug of death when your post goes viral. But managing servers isn't always cheap. While a low traffic personal blog could maybe manage a few to be a few dollars a month, the more that traffic grows, the more that cost is going to grow. While you do still have those options like load balancing and auto scaling, the services add up really quickly. Without it, you, again, risk your site slowing down, or worse, downtime. But storage is cheap. It's really cheap. We can maintain huge static projects in AWS using S3 for a really low cost. But even if we still manage a server, the usage is going to be much, much lower because we're only having to deal with content managers or requests at compile time.

Now, I hopefully convinced you as to why headless is a good thing. Or at least set up some context about what's actually coming next. So, how do I apply this to WordPress? Well, back to the REST API. If I want to start building out my new static blog, I'll ultimately need to fetch all my data. I'll start off by going to WP.json, which is going to be some basic info about my website, along with a list of routes showing what endpoints are actually available to hit. Next, I want to add my blog posts. So, I can hit the post endpoint and easily get them all. I can then simply load them up inside of my application and iterate through all of them inside of the UI. But I want to add more details to this. I want to know, for instance, who the author is. So, I find the author ID in the post, and it probably doesn't make sense to hit each, every individual author one by one, because that could be a lot of authors. So, I hit the author's endpoint, and I try to match up the data.

3. Using GraphQL to Interface with WordPress Data

Short description:

To avoid making multiple requests and dealing with complex data relationships, we can use GraphQL to interface with our WordPress data. By installing the WP GraphQL plugin, we can query our WordPress data with GraphQL, fetching only the necessary data with intact relationships. This reduces data management and complexity. When making requests in the browser, the cumulative impact of KBs and milliseconds becomes noticeable, especially on large sites. Next.js and WPGraphQL can be used together to build a beautiful WordPress blog, with the GraphiQL Explorer providing an interactive way to explore and query the data.

But now I also want to show some categories in that page. So, again, I find the IDs, but this time for the categories, and I request all categories. And, again, match up the data. Looking back at what I just did, though, I just made four separate requests to get the data that I need for the page. Luckily, in my example, I'm statically compiling so that might not necessarily end up costing the user, but that will certainly make development a bit slower.

On top of that, added complexity of managing all of that data and filtering it down so that I don't actually pass all of that data as giant arrays as props into the actual page, along with generally the extra strain on the WordPress instance for all those requests. Now, this isn't meant to shame the WordPress API, nor is it meant to say that REST is inherently bad, but we're dealing with complex relationships in our data. We don't want to be limited by individual endpoints, leaving us with long chains of requests and more data than we actually need. We want to be able to provide the best experience we can.

Now, this is GraphQL Galaxy, so I think you probably know where I'm getting at here, but we can seriously level up the way that we're interfacing with our WordPress data by using GraphQL. And to do that, thanks to Jason Ball, who created the wonderful WP GraphQL, along with all the other hardworking contributors, we can add the power of GraphQL to WordPress. We can do this by simply installing it as a plugin right inside of our dashboard, giving us the ability to query our WordPress data with GraphQL.

So before, I was talking about how I didn't like the idea of having to make all these four requests all chained together. So instead, we can load up our GraphQL client like Apollo, and we can make a single request with our query. Instead of having to manage four full dumps of data, where we need to match everything up and have complicated logic and actually avoid bloating the application, I can query for only the data that I need, with all my relationships already intact, meaning there's less data that I have to manage and far less complexity. Now, again, I'm going to do this during compile time, but we can see the realistic impact of what those requests would look like by making the request inside of the browser. While those KBs and milliseconds might not seem like a lot, it really does add up, and it becomes more noticeable inside the rendering experience. Not to mention, I don't have a lot of posts on the endpoints that I'm actually hitting here, so imagine a huge site that has a ton of posts. Also, that was on my Fast Files connection. It's a little bit different when we see what that looks like when throttling with something like Fast3G connection. The post endpoint with my small amount of posts still took three seconds, so it really starts to become a huge difference. Now, ultimately, we want to pull this into our application. We want to build that beautiful WordPress blog. So this is where Next.js comes in. Like I mentioned earlier, WPGraphQL is a WordPress plugin install away. Once that's installed, you immediately have access to all of your data. The cool thing is with GraphQL, the GraphiQL Explorer is that it's installed by default with WPGraphQL, and it lets you interactively explore all of your data. You're able to click through and see everything that you're actually able to query right inside of that dashboard, and as you're doing that in the middle column, it's actually building the exact query that you need for your app. And I've done just that with creating what I call the Next.js WordPress Starter, which lets anybody spin up a WordPress site with Next.js super easily. Like you'd typically expect from a WordPress blog, the homepage is full of the most recent posts.

4. Using getStaticProps and getStaticPaths

Short description:

I take advantage of getStaticProps to request all posts at compiler time and build the page with pagination. By using getStaticPaths, we define the routes for our posts and fetch the data again using getStaticProps. To avoid hitting the server for search functionality, I created a Webpack compiler that fetches posts at compile time and creates a static search index with titles and paths.

I take advantage of getStaticProps, where I request all those posts at compiler time. That gets injected into the page, and I can build out my page exactly how I want with all of the pagination.

Now, of course, I want to make sure that we have all of the routes for our posts, so we can take advantage of getStaticPaths, which is how we can tell Next.js exactly what paths or pages that we want to make sure get built. And once we define those paths, we can then look up the data again using getStaticProps with each of those parameters.

I would imagine someone would typically expect search as well, and the WordPress API provides search capabilities, but like I mentioned earlier, I'm trying to statically compile this, so then we would still be hitting the server, which I don't want to do here. So I took advantage of Next.js sitting on top of Webpack, and I created a Webpack compiler that fetched all the posts at compile time. It would then create a search index, a static one, with titles and paths right inside of that static file. It then loads that into memory, or it loads it asynchronously on the client, and we can make sure our search is right to that index.

5. Coupling WordPress with Plugins and WPGraphQL

Short description:

We can couple WordPress with familiar plugins like Yoast and ACF, providing flexibility in content and data management. WPGraphQL works seamlessly with these plugins, allowing for querying data relationships with a single endpoint.

The nice thing is we can couple this with all of our WordPress plugins that we are used to, like Yoast and ACF, where this gives us a lot of flexibility for how we actually manage our content and data. And these all work perfectly with WPGraphQL. So you're still querying all those data relationships with that one endpoint, with everything right intact.

So I know you all don't want to just see some screenshots of some code, so let's do a really quick walkthrough. So here's what we're going to do. We're going to first jump into an existing WordPress instance. I'm going to show you how we can simply install WPGraphQL. We'll then open up the GraphQL Explorer so we can just kind of poke around and query our data a little bit. And then finally, we're going to create a new application using an example starter that I created where we can see some existing requests and maybe tweak those requests just to see how we can pull in new data. So let's dive in.

6. Querying Data with WPGraphQL

Short description:

We're going to install the WPGraphQL plugin to query post data with GraphQL. After installing and activating the plugin, we can use the Graphical IDE page to explore and build queries in real-time. By opening the post in the query editor, we can see and add attributes such as date, ID, and title. With WPGraphQL, we can query and retrieve data for each post. We'll use a simpler example starter to demonstrate querying data in real-time and modifying the query. To get started, we'll copy the yarn create command and use create next app to clone the example project, install dependencies, and reset the git history. We'll then add an environment variable, the GraphQL endpoint for our WordPress instance, by creating a .env.local file in the project root.

All right. So we're going to get started with pretty much a fresh new WordPress instance I have from WPEngine where I have a little bit of pre-loaded content in here, including some posts and some pages, just so that we have something to actually query here. But really, the point I'm trying to make is that there's really nothing special going on in here yet. And we can even see under the plugins that we don't have any plugins installed, but our goal is to ultimately actually query all this post data with GraphQL.

So what we want to do is we want to install that WPGraphQL plugin to actually be able to do that. So the first thing I'm going to do is I'm going to click Add New under plugins. And I'm going to go to Search, and I'm going to search for WPGraphQL, which we can see that I've done before. And as soon as I make that search, we can see that right now in the first slot is that WPGraphQL plugin that I'm going to install. And then as soon as it's done, I'm going to activate it. And we can see as soon as it's activated, over in the left sidebar here, I now have this GraphQL tab. And I can even click this Graphical IDE page, where it's going to load up and we can see that we have this graphical editor.

Now, as I talked about earlier in my talk, we have the ability to actually real-time go through all of our data using this query editor. That way we can both see all the data that we have available, but we can build our query so that we can later use it inside of our application. Now, to see how this works, let's try to check out what our posts look like. So if I scroll down inside of this Explorer panel, we can see that I have my post right here, where if I start to open that up, we can then see in the middle column that it's starting to build that query in real-time. Now, let's add some data to that, where if I start opening up the edges and the node for those edges, we can now see all the attributes that I actually have for each of those posts. Where, let's grab some things that make sense, like the date, and we have our ID for each of the posts. And how about our title for the post, where now, if we click play, we can see that in this far right column, I now have all that data for each of my posts. We can see exactly what we showed over in this post page, but we now are able to query that with our WP GraphQL via GraphQL plugin. So now let's actually try to see how we can take this data and use it to build an application.

So what we're going to do to do that is, because the Next.js WordPress starter that I actually create is probably a little bit too complex for trying to walk through in this demo, I have this simpler example starter, where it really is just a basic demo of adding some posts to the page. That way we can see what it looks like to actually query the data in real time, and we can even tweak that query so that we can see what it's like to actually build the query, modify the query, and actually update it. So if we scroll down on this page, we can see the instructions for how we can get started with this, which is actually going to be similar to the Next.js WordPress starter, where we're going to copy this yarn create command, where we're going to use create next app in order to do so. So if I head to my terminal and I actually paste in that query, and let's call this application my-graphql-galaxy, and what this is going to do, if you're not familiar with create next app is it's going to first basically clone down this example project that I have here. It's going to then install all the dependencies, and it's even going to reset the git history. Basically it's going to get us immediately ready to get started and get productive with our application. So now we can see that it's done. I'm going to go ahead and cd into that directory, and we can see that we actually have one more step before we try to spin up this page, where we need to add an environment variable, and this is going to be our graphql endpoint for our WordPress instance. So as we can see next.js convention we're going to add this .env.local file. So I'm going to first open up my code editor with my new project, and at the root of the project I'm going to create a new file called .env.local, and inside here I'm going to add that environment variable.

7. Querying WordPress Data with GraphQL

Short description:

We installed WPGraphQL to query WordPress data with GraphQL. We updated the GraphQL query in our application to include the author for each post. By passing the updated query as props, we were able to display the author's name on each post. This demonstrates the power of using GraphQL and WordPress to query complex relationships and access data.

Now over back on the instructions I'm going to copy and paste that right inside, and next we don't want to try to query yourhost.com, we want to actually query our WordPress GraphQL endpoint, and that endpoint is going to by default be basically wherever your WordPress instance is installed slash GraphQL. So for instance, if I open up my spacejellydemo.wpengine.com slash GraphQL, we can see that while I do get an error here, we are able to see that this is a working GraphQL endpoint. So I'm going to take the same URL, and I'm going to paste it right into my environment variable, where we can see we now have this WordPress GraphQL endpoint set to my actual URL.

And now let's try to spin up our development server by running yarn dev, and we can see that immediately it's going to spin up a new server pointed at localhost port 3000. And if I actually try to open that up inside my browser, we can see that next.js is going to start to compile that page, where basically, it's pulling down that information for us, and it's going to actually build that page in real time. So we can see here now that I have my new blog post, my blog page, that is, my blog website, and we can see that if we start to scroll down here, we have all those posts that we saw right inside of WordPress, but now we're actually getting them inside of the application inside of our browser. So now we can see that we have each of the titles, and we have a description, and we even have a link for each of our posts, but we want to add a little bit more context to this. How about, what if we want to add the author to each of these posts. First, let's dive into the code to see how this is actually happening. So I'm going to go back to my code editor, and I'm going to particularly go to source pages index.js, which is going to be our home page, and if we see at the top here, if you're already familiar with React, there's really nothing special going on here. Really, we have our home component that's taking two props, and it's rendering that out into the page. But what is special is if we scroll way past that React component, we have this function that we're exporting called get static props, which is the Next.js way to fetch data that's going to be static for our application at compile time, where we can see that we're getting our Apollo client, and we're building this GraphQL query, where we're grabbing some general settings for our website, but we're also grabbing all those posts, just like we saw that we did before inside the Graphql Editor. Finally, once we have that data, we're going to just clean it up a little bit, and we're also going to construct the path that each of the posts is going to be available at, and then we're going to simply pass them as props, which again, if we scroll back to the top of the page, we can see that page and post props that we're passing right to the React component. And then at that point, it's just like any other React component, where we're grabbing those posts, we're iterating through, and we're able to render each one of those inside of the DOM, where then we have our Space Jelly demo blog site. So now, like I said, we want to add that author to it. I'm going to first grab that existing Graphql query that we saw right here, the one that we're actively using inside this project, and I'm going to go ahead and paste it right into my Graphql Editor here, going to click Printify here, just to fix the indenting, but I'm going to click Play, and we can see this is exactly the data that we're getting and passing into the application. We see that we have all the posts, we even get the excerpt here, but we also get that title and description, which we can see at the top that we're showing. So now, while we have all this other information for our posts, we want to also add the author to it. So we're going to find that posts section, which is right here, we have our posts, and for each of those edges in the node, we also want to add the author. So I'm going to simply start to open up that author, query the node for each of those authors, then we can see we get all the attributes for the actual author on the post, or in this instance, we probably want to grab the ID, since that's something that we usually want to have for each of our nodes, but then we want to also grab the name, which if we click play now, and I start to scroll down on the received data, we can see that we now see the author for each of these posts, which in this particular instance, it's myself. We see Colby Fayok here, but we were able to see how easy it was to paste in our existing query, update it, where now, just as easily as we pasted it in, let's copy this, and let's paste it right back into our application. We're now going to fix the indentation there. We just updated the query inside of our app, and to see that this is actually working, I'm going to console log out the actual posts prop here, where if we go inside our browser, I'm going to refresh the page, and I misspelled that there, so instead of console logs, there's only one of them, but we can see when the page actually reloads and recompiles, we have this array of data, which is all of our posts, but we now have this author property here, where if I start to expand everything, we can then see my name, KolbyFayal. So let's actually add this into our page, so I'm going to head down inside this react component, where how about right under the title, let's add a new paragraph tag, and let's say bye, and we're going to add our user name, let me close this paragraph tag, but we're going to specify the post.author.node.name, and just for my sanity purpose, the node.author.node.name. So let's see if that works. So now if we reload the page, and it actually probably should have fast reloaded, we can see that I do have Bye KolbyFayal there. And of course the spacing probably isn't the best, we can fix the styling later, but we can see how easy it was to update our query, simply add a little bit of data to that by updating that GraphQL query and we were able to immediately have that available on that post prop that we just passed right into the application, and we were able to do that because we now have the power to query those complex relationships, even the categories if we want, by using GraphQL and WordPress. All right, so let's actually recap what we achieved here. We first took an existing WordPress instance, and we installed WPGraphQL. Once that was ready, we were able to see how easily we can query all that WordPress data with GraphQL.

8. Flexibility of WordPress with GraphQL

Short description:

We bootstrapped a new application that takes advantage of querying with GraphQL, showing the flexibility of WordPress when coupled with GraphQL. It's a compelling option for data management, providing powerful solutions and a great experience for users and developers. Check out Next.js WordPress Starter on GitHub and my course, eCommerce on the Jamstack, on leveluptutorials. Find me at Kolbifeok to learn more or chat about the talk.

Finally, we bootstrapped a new application that takes advantage of querying with GraphQL, and then we added some extra info on top and with the UI. Now the goal here wasn't to get everybody, all of you, over to jump ship to WordPress, but it's to show the flexibility of it and why it's still a compelling option for a data management solution when coupled with GraphQL. We can come up with some pretty powerful solutions that provide a great experience for both our users and our developers.

If you want to check out my work, Next.js WordPress Starter is completely open source on my GitHub, and if you want to learn how to actually do all this in practice, you can check out my course, eCommerce on the Jamstack, over on leveluptutorials. And that's it. If you want to learn more or chat about the talk, you can find me everywhere at Kolbifeok. I'll also tweet out some of the stuff you've seen here today. Thanks, everybody.

9. WordPress and Modern Development

Short description:

WordPress works with modern development architectures, although not all plugins are supported for custom work. Most WordPress sites work well with WP GraphQL.

So we will start first with the question which you asked, and we will see, like, how the people voted on that question. So, just to recap, the question was, does WordPress work with modern development architectures? And it's amazing if you see the results. It's, like, 100% yes. So everyone voted for yes. Did you expect that? I guess that question was a bit obvious. No, I did not expect that. You know, I think, for the most part, it does work with every site, right? But there's the plug-ins, for instance, not every plug-in is going to be supported, especially if you're doing very custom work with WordPress. But, generally speaking, most of the WordPress sites are going to work pretty well with WP GraphQL.


WordPress and GraphQL Integration

Short description:

I started in the era of headless CMS and didn't know much about WordPress. I have a few questions for you. Does GraphQL support WordPress blocks? Generally, it doesn't natively support it, but there is a plugin that can scrape the content. WP GraphQL works with most WordPress websites, but some custom work may not work out of the box. It's developer-friendly and works well with plugins like advanced custom fields and custom post type. From a performance perspective, GraphQL and REST API have their advantages and considerations.

This is nice, I mean, because this is something which even I did not know much about, for me. So, I started in the era with the CMS when the era was of headless CMS. So, I didn't really know much about WordPress. So, I definitely learned a lot.

So, I have a few questions for you, and the first one is, does GraphQL support the WordPress blocks? Yeah, so, that's an interesting one because, mainly, that's what their newer editor is using right now. And unfortunately, it doesn't natively support it at the moment. It's because the way that Gutenberg's created is it doesn't save the content inside of the WordPress database as traditional WordPress content would. But there is a plugin that, my understanding, Hackly does that, where it'll scrape the content, I guess. I'm not too familiar with it. I haven't used it, but I know that there's some solution around that. But, generally speaking, most of the time, you'll use the HTML string that's rendered from WordPress.

Okay. So, we have found a hack for almost everything. There's always a way. So, if you're determined, there's always a way. Okay. So, I just wanted to know, you talked about WP GraphQL. So, I mean, will it work with any sort of WordPress website? Yeah. So, generally speaking, yeah. The tricky thing is, sometimes, there's a lot of custom work that you can do with WordPress, right? Because of just the nature of WordPress is, it's developer-friendly, where you can do a lot of different things and customize it to exactly your needs. And a lot of those custom things... Well, I shouldn't say a lot of those custom things. Some of those custom things might not work out of the box with it, right? But that said, because of how WP GraphQL's kind of hooked into the core of the WordPress database, a lot of that stuff should kind of just work, including a lot of the plugins that you might be familiar with already, like advanced custom fields or custom post type, those kinds of things.

That's interesting. Definitely. So we have talked... We are talking a lot about GraphQL and all, and previously... And now also we use REST API also in some of our projects. So I wanted to know your perspective on what do you think about from a performance side? So you talked about performance in the talk. So like...

Performance of GraphQL vs REST APIs

Short description:

GraphQL allows you to select only the necessary data, reducing unnecessary bytes downloaded in the browser. Making additional REST requests can add up, while a single GraphQL request makes one round trip. However, the performance depends on the specific scenario, and it's important to test and find the best solution. GraphQL's flexibility makes it a great tool for data relationships.

How do... What do you think about the performance when thinking from using GraphQL APIs while thinking REST... Or while using the REST APIs? Yeah. And I think there's a little bit of a caveat with my answer, because every situation is different. But I think it really... Some of the benefits of being able to use GraphQL is first of all, you're able to select just the info that you need, which really reduces in some instances where some REST APIs just give you a dump of all the data. And if you're getting that, those are extra bytes that that person has to download in the browser. But also in addition to that, if you're making additional REST requests, kind of like I showed in the talk, those network requests are going to add up as well, right? Whereas that single GraphQL request is going to just make that one round trip. But again, like it always... It's always really dependent, right? Because if you're just making one simple REST API request, and that REST API already is giving you limited data, of course it might be faster than that GraphQL query in your particular scenario. So it's really important to always test those things and try to make sure that you're really getting the best solution for you. But GraphQL generally is just so flexible in its nature. It's such a great tool to be able to use for data relationships.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.
GraphQL Galaxy 2022GraphQL Galaxy 2022
16 min
Step aside resolvers: a new approach to GraphQL execution
Though GraphQL is declarative, resolvers operate field-by-field, layer-by-layer, often resulting in unnecessary work for your business logic even when using techniques such as DataLoader. In this talk, Benjie will introduce his vision for a new general-purpose GraphQL execution strategy whose holistic approach could lead to significant efficiency and scalability gains for all GraphQL APIs.

Workshops on related topic

GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Featured WorkshopFree
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
Prerequisites: - Node.js installed on your machine (12.2.X / 14.X)- It is recommended (but not required) to use VS Code for the practical tasks- An IDE installed (VSCode recommended)- (Good to have)*A basic understanding of Node.js, React, and TypeScript
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura
React Advanced Conference 2023React Advanced Conference 2023
102 min
Fetch, useEffect, React Query, SWR, what else?
In this workshop, first, we’ll go over the different ways you can consume APIs in React. Then, we’ll test each one by fetching content from a headless CMS (with both REST and GraphQL) and checking in detail how they work.
While there is no advanced React knowledge required, this is going to be a hands-on session, so you’ll need to clone a preconfigured GitHub repository and utilize your preferred React programming editor, like VS Code.
You will learn:- What diverse data fetching options there are in React- What are advantages and disadvantages of each- What are the typical use cases and when each strategy is more beneficial than others