Fetching, caching and 3rd party SDK
Unanswered
New Guinea Freshwater Crocodile posted this in #help-forum
New Guinea Freshwater CrocodileOP
Hey guys, I'd like to open a discussion about caching of 3rd party SDK. I am currently switching my simple project to fetch data using Directus SDK rather than directly communicate with DB using Prisma and I've found myself repeating API endpoints to benefit of Next native caching features.
So question 1: do I have to rewrite API endpoints (which already exists in Directus CMS) to Next API Router, so I can fetch data in my SSR Components and being able to use cache tags as well? Because that's what I am currently doing. So I am ending up with basically two identical API endpoints one accessible from Directus CMS app and second from my Next app.
Quesiton 2: The other thing is, when I am technically replicating these endpoints I must set revalidate to 0 at the top of each route. If I don't do that and I call revalidateTag, e.g. faq, the data in my faq component will not get updated. Revalidation itself gets triggered, this is not an issue, but the fetch function fetches old data from my API router. Is it possible that directusSDK while using fetch is using the extended version of Next and that's why it is cached twice?
So question 1: do I have to rewrite API endpoints (which already exists in Directus CMS) to Next API Router, so I can fetch data in my SSR Components and being able to use cache tags as well? Because that's what I am currently doing. So I am ending up with basically two identical API endpoints one accessible from Directus CMS app and second from my Next app.
Quesiton 2: The other thing is, when I am technically replicating these endpoints I must set revalidate to 0 at the top of each route. If I don't do that and I call revalidateTag, e.g. faq, the data in my faq component will not get updated. Revalidation itself gets triggered, this is not an issue, but the fetch function fetches old data from my API router. Is it possible that directusSDK while using fetch is using the extended version of Next and that's why it is cached twice?
7 Replies
You can directly fetch your Directus stuff in your nextjs app(i don't know what directus is but I assume it's hosted online so you can fetch it directly with a link)
I dont get your question 2. Basically your fetch is going to get cached unless you are opting out of cache (whether intentionally or unintentionally)
To opt out, you can use revalidate: 0 or manually invalidate the cache using revalidateTag.
However revalidateTag only works on the request.
To opt out, you can use revalidate: 0 or manually invalidate the cache using revalidateTag.
However revalidateTag only works on the request.
New Guinea Freshwater CrocodileOP
Yeah I can fetch the API directly, but the question is if I can use revalidate while using it's SDK, which means it does the fetch under the hood itself. If not, then this will be definitely the way I'd go, as I don't want to replicate the existing API routes.
The second question was about my route. I don't use fetch there, however directus sdk uses fetch, so I am confused how come the route is cached. Is it beacuse the sdk is using fetch or is it beacuse the api route is being cached natively, e.g. code:
The second question was about my route. I don't use fetch there, however directus sdk uses fetch, so I am confused how come the route is cached. Is it beacuse the sdk is using fetch or is it beacuse the api route is being cached natively, e.g. code:
import cmsClient from "@/directus/client";
import { readItems } from "@directus/sdk";
export const revalidate = 0;
export async function GET(
request: Request,
{ params }: { params: { slug: string } }
) {
const data = await cmsClient.request(readItems("faq"));
if (data.length === 0) {
return Response.json(new Error("Not found"), { status: 404 });
}
return Response.json(data, { status: 200 });
}@New Guinea Freshwater Crocodile Yeah I can fetch the API directly, but the question is if I can use revalidate while using it's SDK, which means it does the fetch under the hood itself. If not, then this will be definitely the way I'd go, as I don't want to replicate the existing API routes.
The second question was about my route. I don't use fetch there, however directus sdk uses fetch, so I am confused how come the route is cached. Is it beacuse the sdk is using fetch or is it beacuse the api route is being cached natively, e.g. code:
import cmsClient from "@/directus/client";
import { readItems } from "@directus/sdk";
export const revalidate = 0;
export async function GET(
request: Request,
{ params }: { params: { slug: string } }
) {
const data = await cmsClient.request(readItems("faq"));
if (data.length === 0) {
return Response.json(new Error("Not found"), { status: 404 });
}
return Response.json(data, { status: 200 });
}
Yes, it should be able to revalidate if I'm correct. IIRC the cache is done based on the link itself and its done per page, so whether its a route handler or external api shouldn't matter.
The fetch call is memoized automatically inside a component, from what i know fetch calls inside a api route aren't cached automatically.
The fetch call is memoized automatically inside a component, from what i know fetch calls inside a api route aren't cached automatically.
New Guinea Freshwater CrocodileOP
And that's the thing. I forgot to mention the code above is my "api/faq/route.ts" . If I don't specify revalidate=0, the data is cached here as well. So If I make a call to revalidate tag 'faq' set in fetch function in my component faq.tsx, the component will refetch the old data.
Now back to the point you've mentioned:
Now back to the point you've mentioned:
it should be able to revalidate if I'm correct . If the SDK should be able to revalidate how should I trigger this revalidation? Aren't we getting to the part of Next.js documentation where I should enclose the code in cache function and revalidate by path?The fetch memoization happens in the page, not the route, since that auto memoization has to do with the React Tree.
So it doesnt matter if you use an external api or your own api route, as long as its being used in a "Page" and its not opting out of cache for some reason, the link and its result will be cached
So it doesnt matter if you use an external api or your own api route, as long as its being used in a "Page" and its not opting out of cache for some reason, the link and its result will be cached