Part 58: Enhancing CMS Integration in Next.js: Optimizing Data Fetching and Static Generation

[App] Headless CMS

[App] Headless CMS

In our ongoing journey to optimize a Next.js application, we've made significant strides in streamlining how we fetch data from a CMS. Previously, we refactored our getReview and getReviews functions to eliminate redundancy. Now, we're turning our attention to two additional functions: getFeaturedReview and getSlugs. We'll explore how to make data fetching more efficient and ensure that static pages are generated seamlessly using CMS data.

Optimizing getFeaturedReview

Currently, getFeaturedReview simply calls getReviews and returns the first review from the fetched data. While this approach works, it's not the most efficient, as getReviews retrieves six entries when getFeaturedReview only needs one.

Future Optimization Consideration

In a future update, we might consider optimizing getFeaturedReview to fetch only a single entry from the CMS directly. This would reduce the amount of data transferred and improve performance. However, for now, our focus is on ensuring that the home page displays the most recent review correctly, which it does.

Re-implementing getSlugs for Dynamic Routes

The getSlugs function plays a crucial role in generating static parameters for dynamic routes in Next.js. Previously, it relied on reading local Markdown files to obtain slugs. This approach, while functional, doesn't align with our goal of utilizing CMS data.

Fetching Slugs from the CMS

To align with our CMS-based approach, we refactored getSlugs to fetch slugs directly from the CMS. This change ensures that the slugs used for generating dynamic routes are always up-to-date with the content available in the CMS.

Here's the updated getSlugs function:

export async function getSlugs() {
  const { data } = await fetchReviews({
    fields: ['slug'],
    sort: ['publishedAt:desc'],
    pagination: { pageSize: 100 },
  });
  return data.map((item) => item.attributes.slug);
}

Key Considerations:

• Pagination: We set a high pageSize to 100 to ensure we fetch all slugs, as Strapi limits responses to 25 entries by default. If our content grows beyond 100 entries, it might be reasonable to generate static pages for only the most recent reviews.

• CMS Synchronization: By fetching slugs from the CMS, we ensure that our static pages are generated based on the latest content, eliminating the reliance on outdated local files.

Cleaning Up Log Statements

During development, we often add console.log statements to debug and track application behavior. However, these can clutter logs and make it difficult to focus on relevant information.

Streamlining Logging

We performed a cleanup of unnecessary log statements, commenting them out rather than removing them. This approach allows for easy reactivation if needed in future debugging sessions. Here's an example of this cleanup in action:

// console.log('[HomePage] rendering');

Testing the New Setup

With the refactoring complete, we tested the new setup by running a production build. This allowed us to verify that the static pages were generated correctly based on the CMS data. The logs confirmed that all slugs were received by the generateStaticParams function, and static pages were generated for the available reviews.

Conclusion

By refactoring our code to fetch slugs from the CMS, we've ensured that our dynamic routes are generated based on the latest content, enhancing the reliability and efficiency of our Next.js application. This change, coupled with the optimization of data fetching in getFeaturedReview, sets a strong foundation for future enhancements.

In upcoming updates, we'll continue to refine our application, exploring ways to further optimize data fetching and enhance user experience. Stay tuned for more insights into the world of Next.js and CMS integration.