So if you do this, and it basically tells Apollo never cache anything with the freshest data, you know, don't cache it at all. You can do that, no cache, or stand by. There are a few different options there. So this is how you can have some control over, you know, what it's caching, and so on, and for how long. There's some options for that.
Beyond that though, you're asking about cache invalidation, right? It's like, well, if some data has changed, how do I clear the cache, you know, and tell Apollo to refetch it? And you can do that as well. So that'd be like when you do a mutation. Let's see if we can find the docs real quick. Let's see. Yeah, here we go. So refetching queries or refetching after update. Yeah, so you can do this if you have a mutation that you're doing in your friend JavaScript app where the user is like adding it to do in this case or making some like update to the data. You can tell Apollo client, after this mutation executes, you know, run this callback function. You give it a callback function and say, that you wanna, you know, refetch a certain thing. You get a certain query and say after this mutation, executes, you added to do, and refetch this query over here, that is responsible for fetching the list of to dos, right? So, if you do that, then it knows, okay, I'll refetch that list. And then react will re-render the list of to dos to show, you know, the updated list, which includes the new one that they had just added. And then you can say, okay, so I got my query. I know that I'm going to run it again. And then I go ahead and I'll re-render the list that they just added to the list. So, you can do stuff like that. If it's the user themselves, like making mutations, you can tell a POP client to like blow away part of the cache or refetch part of the cache so that it gets the new data there. As far as any other caching of just server data, that you can control with like the fetch policies. So, if you wanna Google just fetch policies and look at those, that page that we had looked at, that's how you would control that.
Alright, yeah, I think we're good then. How are we doing for time? We can dig into our fragments if we still have time. I think we have 30 minutes remaining. Yeah, my pleasure Stefan, hopefully that was helpful. Their docs are really really good. I found Apollo's docs. If you see I dig into those, you can typically find your answer. All right, yeah, so at this point we could gig into some of the fragments stuff, unless I see in the chat that the group wants to go down to other rabbit holes that I'm happy to use it. I got a rabbit hole. Good, what happens when WordPress is down? This is an interesting question. Yeah, so if you're doing this decoupled architecture that looks like this, right? It's a good question. Like, well, what if Next.js tries to use this API layer to contact WordPress to get through data. WordPress has downtime, right? The server's not there. So this can be handled a couple of ways. One way is in Next.js, if you're using like it's incremental static regeneration feature to like regenerate your pages on a time interval, it will, if it fails to regenerate the page, it'll just keep serving up the stale page actually, which is a really cool feature. So you can tell Next.js, and if you're not familiar, if just Google Next.js incremental static regeneration. If you Google that, if you're not familiar that'll you know, explain kind of what that is. But it's basically tells Next.js, I want this to be a static page, but it should only last for a certain amount of time, you could specify and say, regenerated every 10 minutes, every hour, once per day, whatever you want. On that interval, Next.js will, it follows a stale while revalidate model, where it'll, if a request comes in and realizes the page is no longer valid, you know that time duration has elapsed. It'll still serve up that stale page to that one, you know, that one last user. But then in the background, it'll kick off the process to refetch the data and regenerate that page. As soon as that new page, new versions available, it swaps out the new one for the old one. So then any new visitors coming to the site would get that new version of the cache page. So to them, it's still a very quick, you know response times as though it's it's a static page, but you can add some dynamism there and like refresh on interval by using this feature. But anyways, if you're doing that kind of thing, Next.js will not swap out the old cache page for the new one if it fails to do any of the data fetching. So that'd be one solution to this. So if WordPress had downtime and Next.js is trying to, you know, reach out to WordPress and regenerate the page for a blog post or whatever, and it's unable to, it's fine. It would just keep serving up the stale page until, you know, at a later point when WordPress is back online and it tries again at that point, it would just, you know, start regenerating the pages again. So that's a really cool, robust solution where you can have your front end app just fall back to the cache pages, you know, whenever your data sources in our case, WordPress, like happened to be down. So that's one cool solution. It doesn't handle every case, of course, so like our search page, right? If somebody goes to the search page and tries to perform a search and the WordPress is down at that moment, like then of course, we can't, you know, we can't really do anything about that because we need the actual, you know, data from WordPress. So the best you can do there would just be to follow, to fail gracefully, right? Like on our search page, we just have, if an error happened, in our case, Apollo would call this like a network error, like it tried to send the request to the backend API and got, you know, either a 500 error or it was offline or whatever else. So you just fall back, you know, and fail gracefully and say, sorry, unable to perform searches at this time or whatever and just display a message like that. So yeah, definitely a real concern if WordPress goes down, but, yeah, doing the like the static rendering of pages can really save you sometimes from that being a problem. Yeah, good question there.
Okay. We can dig into some query or some fragment stuff for a little bit then. GraphQL fragments are really cool. Let me show you what they are at a high level. So let's say we, so we had this search post query that we had composed, right like that. What we're able to do with fragments is kind of break up some of this and define it other places. Let me show you what I mean. So if I can type fragment and we'll give it a name. So this will be, so fragment featured image. I'm probably gonna get the syntax wrong for this. Wanna get myself. Get my cheat sheet so I can look at my own app in the syntax here. Look at the post list, oh yeah. I had to refresh myself on the syntax. So featured image is a fragment where we're gonna define, and actually let's do a different one that we'll actually use in our app. So this kind of fictitious one I was gonna do on the search page, let's just dive right into it and we'll start with the real ones on the blog page, how about? Alright, this is the one where we got the first 18 posts and display them on a grid, right? This one, let's say like these nodes here, we don't want this data to live here because actually, if you look at this component, how much of that data does it care about? None, right? It just grabs the posts and sends them straight through the post list component. This component actually doesn't care about all of the fields that we're defining here. The only reason we're putting them in this file is because we need that data eventually downstream for the post list component. So one really powerful pattern is to co-locate your components data needs with the component itself. So what you could do is create some fragments so that this data lives and is defined maybe with this post list component, if it's the one that cares about that data or otherwise with this postcard component. Since it's the one that cares about some of that data, why not just define a fragment in the same file where we define the fields that we need and then immediately below it inside of the component, go ahead and destructure it and use those same fields. Like, wouldn't that be a nicer, more organized code base for us, right? And that's what fragments allow you to do. So we can do that, like, with the blog page and then post list and then post card. So I'll start with, like post card since that's the most granular, I guess. That's like the, it doesn't render anything else. It just gets rendered by post lists, which gets rendered in turn by blogs. So let's start with like post card. I'll show you what I mean by creating these fragments. This is what you would do like above this thing, you would do, so we'll export a constant from this file.
Comments