Webhook timing & error reporting issues

[vrio_dave]

Builder content link

Builder.io: Drag and drop Visual CMS

Builder public api key
95f85218ff0341d89359f81dfab08c7a

What are you trying to accomplish
I want to set up a webhook to build with Gatsby whenever a page is updated. The API endpoint works, I’ve tested it thoroughly. However, I’m having 2 issues:

1. The Gatsby build seems to only work the second time I run it. For example, if I make a change and click publish, I build the site (I can see that the command is running). However, there are no changes to the site. When I make another change, the command runs again, and the change I made before is now shown. I have useCache: false in my gatsby-config.js for the Builder plugin.
2. When I run the webhook, it returns an error that there was a problem with the webhook even though it does run. I can get rid of the error if I allow the webhook to return without completing the build; however, that prohibits me from returning errors to Builder that the webhook fails.

Screenshots or video link

Code stack you are integrating Builder with
Gatsby → S3 + CloudFront. Webhook is through API Gateway via SST.

[manish-sharma]

Hi @vrio_dave,

1. The issue with changes not reflecting as intended, could be resolved by adding cachebust: true to the options in your graphql query for the content.

export const landingPageQuery = graphql`
  query($path: String!) {
    allBuilderModels {
      landingPage(
        target: { urlPath: $path }
        limit: 1,
        options: {cachebust: true},
      ) {
        content
      }
    }
  }
`;

2. For the webhook error, you can try disabling the Disable proxy option

Let us know how that works for you. Thank you!

[vrio_dave]

@manish-sharma, the cachebust: true did the trick on the timing issue, thanks!

However, I’m still getting the error even after disabling the webhook proxy. Do you think it has to do with timing? The call takes between 15-25 seconds to complete because it returns a response after the build is successful. Could it be that Builder expects the webhook to return after 10s and it times out if not?

[manish-sharma]

Hi @vrio_dave,

We verified the timeout for the response and the builder doesn’t expect a response within 10-15 sec. Could you check and let us know what error you are getting in the browser console when this error pop-up appears?

[vrio_dave]

In the end, we had to change our methodology to an asynchronous Lambda function with a URL mapped to a CloudFront CDN origin and behavior. And we switched from building SSG with Gatsby to Next.js.

However, I’m back to having issues with cachebust in Next.js. I’ve got the following getStaticProps function:

export async function getStaticProps({ params }) {
  const page = await builder
    .get('page', {
      userAttributes: {
        urlPath: '/' + (params?.page?.join('/') || ''),
      },
      cachebust: true,
    })
    .toPromise();

  return {
    props: {
      page: page || null,
    },
  };
}

That doesn’t appear to be clearing the cache as every build is showing changes from the trigger before.

I also tried the following BuilderComponent code:

<BuilderComponent
  model="page"
  content={page}
  options={{ includeRefs: true, cachebust: true }}
/>

And that also doesn’t work. What should I change?

[manish-sharma]

Hi @vrio_dave,

When using nextJS there is no need to use build webhooks, however, you can try using Seconds to cache content. This sets the maximum age of the cache-control header response header. A set value is higher for better performance, and lower for content that changes frequently.

We use a technique called stale-while-revalidating caching which updates the data based on how frequently data is requested. For example, if you update the content, but no one visits your site, your content may not update right away. The next time a user visits the site, they’ll see the cached version, while the latest version is fetched in the background and the cache is updated. The next visitor (after a few seconds) will see the new version.

You can control the cache length via query params in the request to our content api . We recommend keeping the default values though, since reducing cache time can negatively affect performance. Generally speaking, a development site (that is not live) could be a little stale, but a live site with real traffic will always be fast and fresh. If you want to manually ensure pages are updated, but you have no one on your website visiting them, you can always just visit them once or twice after updating to ensure we fetch the latest version.

[vrio_dave]

Hey @manish-sharma ,

Thanks for responding. With our implementation, we do need to use webhooks because we are using it like Gatsby to generate SSG that is piped to S3 buckets. Since we use Next.js for our previewing methodology, it makes sense to stick to it for SSG; however, the deployments are completely different.

In the end, setting cacheSeconds to 0 was the trick. I’m just perplexed why that’s necessary if cachebust: true; it seems like cachebust should do that as well.

Anyway, thanks for the explanation as well, that helps me understand how the @builder/react.io package works a little better.