Best rendering method Next.js + Prismic in Docker CI/CD Setup?

I'm a backend developer and relatively new to Next.js. I'm working on a Next.js project and using Prismic as my CMS. After reviewing the Prismic documentation, I noticed they recommend using Static Rendering (SSG) for fetching data. However, I'm struggling to understand how this fits within my CI/CD pipeline, especially regarding data fetching during build time.

My main concern is about the reliability and performance of fetching data from Prismic during the build step in my pipeline. I'm using Docker to build the app and create a Docker image which is then deployed to my EC2 instance. From my experience, I'm always cautious about making requests to external resources/services/APIs during the build stage due to potential issues (like the service not being available), build times and reliability (if the service is failing then my build will fail as well).

Given my setup, I'm trying to determine the best rendering technique to use: SSG, SSR, or ISR.

  • Is it common practice to fetch data from a CMS like Prismic (or any other external service) during the build step in a CI/CD pipeline if I want to use SSG?
  • How does fetching data from Prismic or any other external service like my Spring Boot API during build time affect the reliability and performance of the CI/CD pipeline?

I found this GitHub discussion where they comment about similar issues with fetching data during build time. They talk about some of the concerns I have, such as the impact of network requests during the build process and one suggestion is to use a user-defined environment variable to skip pre-rendering pages during build time which apparently goes against what Prismic suggest in their documentation.

Appreciate any advice from those who have experience with Next.js and Prismic or with similar setups.

Hi @markcosta15, great questions.

Is it common practice to fetch data from a CMS like Prismic (or any other external service) during the build step in a CI/CD pipeline if I want to use SSG?

Yes, it is common to fetch CMS data at build time to generate static pages.

Fetching all data at one point in time is more performant than fetching it on every request. Visitors are likely to visit your website more frequently than content is updated in Prismic. Thus, you can reduce the total time fetching data from Prismic by performing all the requests in one batch at build time.

Next.js has a unique data caching model that allows you to incrementally rebuild pages when content in Prismic changes. If you publish new content in Prismic, all pages will be invalidated and rebuilt as visitors access your pages. This means visitors will see fresh content quickly without waiting for your whole website to be built. That new version is cached until new content is published again.

How does fetching data from Prismic or any other external service like my Spring Boot API during build time affect the reliability and performance of the CI/CD pipeline?

Fetching content from Prismic acts like any other API request you would make at build time, including your Spring Boot API.

If a Prismic or any other network request fails during the initial build, an error will be thrown and the build will fail. Ideally, your CI service would notify you of the failure, giving you a chance to retry the build or fix the issue.

After the initial build, Next.js acts in on-demand revalidation mode, where pages are rebuilt one-by-one after new content is published. The same rule applies: if a network request fails, an error is thrown and the request will fail. Again, ideally you have a system set up to notify you of the failure so it can be fixed.

Prismic's Document API (the one you use to fetch content) has great uptime. I don't have any numbers to share with you, but you can check the API's status history here: https://status.prismic.io/

In general, we recommend the setup used in our starters. You can use our multi-page starter as a reference: GitHub - prismicio-community/nextjs-starter-prismic-multi-page: Next.js and Prismic multi-page starter