What's your weirdest use case for a Netlify feature?

Hey folks! I am curious to hear your workflows that you’d consider “unexpected” that you use on our service. I ask not to penalize anyone for holding it wrong, but because we on the Support team are often surprised by novel applications of our service and go on to suggest those workflows to other customers with similar problems to solve.

Here’s some examples:

  • using event triggered functions from a form submission to delete the entry from Netlify’s DB via API. This allows you to manage your own user-submitted data with confidence that it’s not hanging out on our servers.
  • using our CLI within a build within our own CI environment, to run a copy of your site via netlify dev, so you can use a function (run locally) during build, since they are otherwise not available until after the deploy has completed.
  • I once heard of a user who rebuilt their site every minute, to change a timestamp on the front page. This is not something they persisted in doing once we started charging for build minutes :wink:

What interesting use case have you seen/experimented with? Did you accomplish something that seems otherwise impossible on our platform? Tell us more!

1 Like

Here at Netlify, we use Chromatic to deploy our Storybook (full context in this blog post) and run visual regression tests.

We’re using a combination of several Netlify features to help us have predictable URLs pointing to Storybook preview deployments: Branch Deploy Previews, custom build command, and redirects.

Chromatic

Our Storybook is published to Chromatic’s secure CDN for every commit so we can quickly share work with the team at URLs of this type:

https://ba40e1a--62c6e888ff406488a4648aed.chromatic.com
  • ba40e1a: first 7 characters of the commit hash
  • 62c6e888ff406488a4648aed: our Chromatic project token

Before we used Chromatic, we had gotten accustomed to deploy preview URLs of this kind: https://deploy-preview-123--storybook.netlify.app/, and I thought it’d be neat to keep them.

So I set a custom build script for storybook.netlify.com in the Netlify UI under Site settings > Build & deploy > Build settings:

Important: deploy previews are enabled.

And now every time we push commits to a pull request, this build command runs:

echo "/ https://${COMMIT_REF:0:7}--${CHROMATIC_PROJECT_TOKEN}.chromatic.com" > _redirects

The command composes a URL pointing to the Chromatic CDN, and writes it to the contents of a _redirects file (taking advantage of the Netlify redirects feature).

This way, our pull requests all have a unique URL pointing to the latest published Storybook, for example:

https://deploy-preview-14724--storybook.netlify.app/
points to https://f785161--62c6e888ff406488a4648aed.chromatic.com/

Bonus developer experience tip

In our GitHub pull request template, we have this code:

## Test plan

1. Visit the [Deploy Preview](https://deploy-preview-{{prNumber}}--app.netlify.app)
2. Visit the [Storybook Deploy Preview](https://deploy-preview-{{prNumber}}--storybook.netlify.app/)

Notice the {{prNumber}} tags? They automatically get replaced by a GitHub action to match the number of the pull request – and now we instantly have a link to Storybook, ready to quickly share with our teammates :tada:

2 Likes

I haven’t implemented it myself (yet), but you gave me an idea with the event triggered functions bullet point! It may make for a great article on the Netlify blog as well.

In theory, a user could utilize an event triggered function to handle some conditional logic behind the scenes when a form is submitted.

In combination with the Netlify Email integration, an email could be fired off to a certain individual or group based on data in the form.

For example:

If the user selected “Sales” in a dropdown, send the form submission to sales@domain.com
If the user selected “Customer Support”, then send it off to support@domain.com

This could be taken one step further by bringing Supabase into the mix or another database tool. Allowing you to pull any existing information you have on the form submitter and adding it to the internal email.

If you want to take it even further, you could use the Netlify Edge Function and the HTMLRewriter to store information on the form submitter in hidden form input fields. For example - their country, referrer, etc. This would be great immediate context for logging submissions in a CRM. While this can be achieved with clientside Javascript, it is not always 100% accurate, and it wouldn’t work for users who have JS disabled as well.


Another use-case for the event triggered function could be using the OpenAI Moderation API to automatically delete a submission if it triggers a red flag. This would be useful for a blog post comment submission form or customer feedback form. This could also be achieved using no-code, through Netlify’s Zapier integration and OpenAI’s Zapier integration.

Aside from form submissions, the event triggered functions could also be used in tandem with a tool like LogSnag when a site deploy fails. You can use LogSnag to track the number of times a site deploy has failed and even have it send a push notification to your desktop or mobile device.


Scheduled functions could be used to have your “own” uptime monitoring configuration as well. You can have one check if your site is still live on an hourly basis and when an error code is returned, notify the respective individual(s) using the Netlify Email Integration.

Alternatively, you could use a third-party uptime monitoring tool and still combine it with a Netlify function. Most, if not all, tools allow you to specify a webhook URL when your site goes down. You could add your Netlify function endpoint here and then essentially extend the functionality of that tool. If they don’t for example, support sending you a Slack message, you can have the Netlify function handle that.

Or you could (again) use the Netlify Email Integration to notify your customers about the downtime, with an entirely custom-branded email sent from your email address. As opposed to being restricted by the style customization limitations offered by the tool with their email notifications.

If you want to really have some fun, you could have a button added to the Slack message or an internal email that lets you roll back a site deploy using the Netlify API. You can have the button link to a Netlify function endpoint and when it’s done running, have it send you to your site or the Netlify dashboard. This way, if you make a change that breaks your site, you can rectify it immediately.

4 Likes