Auto build Gatsby application using custom Webhook on Wordpress

Shoyeb Inamdar
Technogise
Published in
4 min readMay 5, 2020

Overview:

At Technogise, we recently did a project for one of our clients, which is an EU based multinational pet food producer. The client has multiple websites in Wordpress and every website has a lot of content, including photos and videos. They also add multiple blog posts every day to the platform.

The challenge:

With so much content, the website response time from Wordpress was very slow. They did not want to add more & more servers to manage the traffic and were looking for a more logical solution.

Our Solution:

After our analysis, my colleague Ankita Saxena and I realized that most of the content is static in nature. There were few forms or business critical user flows which still had to be supported. Our approach was to first make changes in one microsite and see the results. If it met the business needs, then we would replicate the same for other sites. As the content was static, it was very clear that we should be leveraging CDN capabilities to take data more closer to the users while still having the power to update the cache when the data changes. To achieve this, we used Gatsby.

Gatsby with Wordpress

Gatsby is a blazing fast modern site generator for ReactJS. Gatsby can pull data from any data source like Wordpress, Drupal, YAML, JSON, Databases, etc and then build static web pages with the help of GraphQL queries.

In this article, we will focus more on building Gatsby site with Wordpress as a datasource. We created a sample project using Gatsby which builds a static website from Wordpress data. For further details, please refer to official documentation of Gatsby for sourcing from Wordpress.

Gatsby Overview

Let us take a 10,000 feet overview of Gatsby’s build process.

After a successful Gatsby build, it generates all the required assets to run the website in the public folder. The assets include minified files, transformed images, JSON files with information & data for each page, static HTML for each page, and more. The final build is just static files which can be deployed anywhere.

To reflect changes in the generated static assets corresponding to the change in source, we have to rebuild and redeploy.

Ways to automatically rebuild

To keep the Gatsby site updated with Wordpress, we must always automatically build our site whenever there is an update on Wordpress data (like addition of pages/posts/menus). Based on the nature of the website, following are the approaches to automatically rebuild:

  1. Cron Job : Schedule a Gatsby build at a time interval to rebuild the assets.
  2. Webhook using plugin : Build a Webhook that rebuilds the website whenever there is change in the source. Here are a few ways you can trigger the webhook:
  • — Install Build Trigger for Gatsby plugin and configure webhook URL. This can be a Jenkins job URL. However there is very limited customization available here.
  • — Use external tools like Netlify or Vercel, which can quickly build our website.
  • — Build custom plugin to securely call the webhook

In our case, the content was supposed to be published multiple times in a day and as soon as it was changed. This left us with the option of going with the webhook approach. Client was hesitant in using a third party app, so we went ahead with building our own custom plugin.

Custom Webhook on Wordpress

To configure a custom Webhook, we have to do the following two things,

  1. Configure Wordpress to trigger the webhook on any change in content
  2. Create an endpoint to rebuild the site using Gatsby

Now let’s get into the details of each step:

Configure Wordpress

To configure wordpress to trigger the webhook, add the following code snippet to wp-includes/functions.php.

Note : This snippet is for Wordpress posts only. For other entities in Wordpress, we have to add relevant snippets.

Custom Webhook

To create a custom webhook, we have to create a basic endpoint (in any language of our preference). We used Java - Spring Boot as a reference implementation to create a webhook. This endpoint triggers Gatsby build to generate static website. For complete source, please refer wordpress-gatsby-webhook repository.

If your data is changing too frequently, then the reference implementation of webhook can further be improved by queueing the request for a window of say X mins, and then trigger the build. This will avoid multiple rebuilds.

Conclusion

The above approach of using Gatsby and custom webhook helped us instantly rebuild and deploy updates/changes in wordpress at runtime. This helped the client to not only serve the website faster, but also make frequent changes and quickly see those on the live website.

Next steps for us is to make the build flexible to generate assets for the updated content only.

Feel free to fork, use or contribute in the following repositories:

https://github.com/technogise/wordpress-gatsby-webhook
https://github.com/technogise/gatsby-wordpress

I would like to thank my teammate Ankita Saxena for her collaboration and contribution to this project as well as this article.

--

--

Shoyeb Inamdar
Technogise

Software Maker, Clean Code enthusiast and Automation Lover