Blog

As someone who specializes in integrations, I’m hardly ever surprised when I come across yet another CRM platform I’ve never heard of. It feels like there are almost as many CRMs out there as stars in the night sky — okay, maybe that's a bit of an exaggeration, but you get the idea.

I was introduced to another platform while working on a small integration project: Nexudus. Nexudus is a comprehensive system designed specifically for managing coworking spaces, shared workspaces and flexible offices, whilst incorporating the features you’d expect from a customer relationship management platform.

For one part of this integration, newsletter subscribers needed to be stored in Nexudus through a statically-generated site built on Astro, hosted in Netlify. The only way to pass subscriber data to Nexudus is through their API platform, which posed an opportunity to build this integration using Netlify serverless functions.

The Newsletter Subscriber API documentation provides a good starting point for sending through subscriber details and assigning to specific newsletter groups. However, one issue arose during integration whereby the endpoint would error if a user was already subscribed within Nexudus, even if it was a subscription for different group.

It would seem how Nexudus deals with existing subscribers will require a separate update process, as just using the Add Newsletter API endpoint alone does not take into consideration changes to subscription groups. It would be more straight-forward if the Mailchimp API approach was taken, whereby the same user email address can be assigned to multiple mailing lists through a single API endpoint.

When developing the Netlify serverless function, I put in additional steps to that will allow existing subscribers to be added to new subscription groups through the following process:

1. Look up the subscriber by email address.
2. If a subscriber is not found, a new record is created.
3. If a subscriber is found, update the existing record by passing through any changed values by the record ID.
4. For an updated record, the new group ID will need to be sent along with the group ID's the user is already assigned to.

A Github repository has been created containing the aforementioned functionality that can be found here: nexudus-netlify-functions. I may add other Nexudus API endpoints that I have been working on to this repo going forward.

As I have been delving deeper into adding more functionality to my Gatsby site within the Netlify eco-system, it only seemed natural that I should install the CLI to make development faster and easier to test builds locally before releasing them to my Netlify site. There have been times when I have added a new feature to my site to only find it breaks during the build process eating up those precious build minutes.

One thing that I found a miss from the Netlify CLI documentation were the steps to running a site locally, in my case a Gatsby JS site. The first time I ran the netlify dev command, I was greeted by an empty browser window served under http://localhost:8888.

There were a couple of steps I was missing to test my site within a locally run Netlify setup.

1) Build Site

The Gatsby site needs to be compiled so all HTML, CSS and JavaScript files are generated as physical files on your machine. When the following command is run, all files will be generated within the /public folder of your project:

gatsby build

The build command creates a version of your site with production-ready optimisations by packaging up your site’s configurations, data and creating all the static HTML pages. Unlike the serve command, you cannot view the site once the build has been completed. Only files are generated, which is exactly what we need.

2) Run Netlify Dev Command From Build Directory

Now that we have a built version of the site generated locally within the /public folder, we need to run the Netlify Dev command against this directory by running the following:

netlify dev -dir public

As you can see, the dir flag is used to run our site from where the compiled site files reside. I originally had a misconception in thinking the Netlify Dev command would build my Gatsby site as well, when in fact it does not.

Conclusion

If you have a site hosted by Netlify, using the CLI should is highly recommended as it provides you that extra step in ensuring any updates made can be tested prior to deployment. My site uses Netlify features such as redirects and plugins, which I now can test locally instead of going down the previously inefficient route of:

1. Deploying changes to Netlify.
2. Waiting for the build process to complete.
3. Test changes within the preview site.
4. If all is good, publish the site. If not, resolve error and deploy again.

This endless cycle of development hell is now avoided thanks to the safety net the Netlify CLI provides.

Further Reading

• Netlify CLI Command List
• Code faster with these 10 Netlify CLI commands
• Top 10 Netlify CLI Commands
• Top Things You Didn’t Know You Could Do With Netlify CLI

I’ve recently updated my website from the ground up (something I will write in greater detail in a future post) and when it came to releasing all changes to Netlify, I was greeted by the following error in the build log:

7:39:29 PM: $ gatsby build
7:39:30 PM: error Gatsby requires Node.js 14.15.0 or higher (you have v12.18.0).
7:39:30 PM: Upgrade Node to the latest stable release: https://gatsby.dev/upgrading-node-js

Based on the error, it appears that the Node version installed on my machine is older than what Netlify requires... In fact, I was surprised to discover that it was very old. So I updated Node on my local environment as well as all of the NPM packages for my website.

I now needed to ensure my website hosted in Netlify was using the same versions.

The quickest way to update Node and NPM versions is to add the following environment variables to your site:

NODE_VERSION = "14.15.0"
NPM_VERSION = "8.5.5"

You can also set the Node and NPM versions by adding a netlify.toml file to the root of your website project before committing your build to Netlify:

[build.environment]
    NODE_VERSION = "14.15.0"
    NPM_VERSION = "8.5.5" 

I normally like my last blog post of the year to end with a year in review. In light of being in Tier 4 local restrictions, there isn't much to do during the festive period unlike previous years. So I have decided to use this time to tinker around with various tech-stacks and work my own site to keep me busy.

Whilst making some efficiency improvements under-the-hood to optimise my sites build and loading times, I randomly decided to check the security headers on securityheaders.com and to my surprise received a grade 'D'. When my site previously ran on the .NET Framework, I managed to secure things down to get graded an 'A'. I guess one of my misconceptions on moving to a statically-generated site is there isn't a need. How wrong I was.

A dev.to post by Matt Nield explains why static sites need basic security headers in place:

As you add external services for customer reviews, contact forms, and eCommerce integration etc., we increase the number of possible vulnerabilities of the application. It may be true that your core data is on accessed when you rebuild your application, but all of those other features added can leave you, your customers, and your organisation exposed. Being frank, even if you don't add external services there is a risk. This risk is easily reduced using some basic security headers.

Setting security headers on a Netlify hosted site couldn't be simpler. If like me, your site is built using GatsbyJS, you simply need to add a _headers file in the /static directory containing the following header rules:

/*
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
Content-Security-Policy: base-uri 'self'; default-src 'self' https: ; script-src 'self' 'unsafe-inline' https: ; style-src 'self' 'unsafe-inline' https: blob: ; object-src 'none'; form-action 'self' https://*.twitter.com; font-src 'self' data: https: ; connect-src 'self' https: ; img-src 'self' data: https: ;
Feature-Policy: geolocation 'self'; midi 'self'; sync-xhr 'self'; microphone 'self'; camera 'self'; magnetometer 'self'; gyroscope 'self'; fullscreen 'self'; payment 'self'

When adding a "Content-Security-Policy" header be sure to thoroughly re-check your site as you may need to whitelist resources that are loaded from a different origin. For example, I had to make some tweaks specifically to the "Content-Security-Policy" to allow embedded Tweets to render correctly.

My site is now back to its 'A' grade glory!

Useful Links

• Check Your Website Headers People
• How to ensure you have the right security headers
• Netlify Custom Headers
• Netlify Playground - Headers Tester