Data fetching in react server components

🆘 Support
1

Hey Datos,
Hey Community,

now that we have React Server Components (RSC) we are able to fetch data at component level.

Previous to that, if we take Next.js as our example framework, we had to fetch data on the route level using getStaticProps or getServerSideProps. So we had a huge GraphQL query for each route which fetched all needed data for the route, and passed it from the top down to the components.

With RSC we can now break that huge GraphQL query up, in smaller single one’s and move them to the component level (the component is fetch it’s needed data). This of course results in more queries per route.

Now our question is what approach is the recommended way for GraphQL using Dato as our CMS backend? Or what’s your take on how data fetching, explicitly GraphQL, should be done in an RSC environment?

Best,
Martin

2

Hey @martin.palma,

Generally speaking, Next.js’s App Router has its own built-in caching mechanism which actually overrides the vanilla fetch() function and adds invisible caching: https://nextjs.org/docs/app/building-your-application/caching

Using that together with cache tag-based invalidation (which we just recently launched) would allow you to cache fetches and invalidate them only when specific content changes: https://www.datocms.com/docs/next-js/using-cache-tags (which also links to the demo repo https://github.com/datocms/nextjs-with-cache-tags-starter).

That should work reasonably well for your typical marketing landing page site, etc. (anything that is read-often, write-rarely).

If you have a particularly complex schema on the frontend where data frequently changes (e.g. real-time or near-real-time) and is shared across many components in different permutations, that standard system might result in a lot of invalidations all the time, and you might want to consider some other system (time-based, for example) instead, or maybe do some client-side fetching alongside the RSC, depending on component, etc… really depends on the specifics of your project.

What do you think? Is there a specific kind of use case you’re concerned about? Maybe we can explore and test that together?

Also, for simpler sites, many of our our customers are now exploring Astro.js instead of Next, because it’s so much simpler in implementation and mental model.

The App Router (and RSCs, if they ever go mainstream… or have they already?) might be nice more complicated apps (like complex dashboards with a mix of baked content and real-time data updates), but it can also be overkill for simpler sites that are essentially just a collection of static landing pages. The additional power & complexity isn’t necessarily the right fit for every type of site, and sometimes it may make more sense to just use the Page Router or another framework instead… it just depends?