DEV Community: Thor Galle

Migrating static redirects from Gatsby Cloud to Vercel

Thor Galle — Fri, 22 Sep 2023 12:37:42 +0000

Since Gastby Cloud is being discontinued in favor of Netlify's offering, I was looking for a new home for my personal website, which was hosted using Gatsby Cloud's free tier.

The suggested migration path logically led to Netlify, but since I already hosted some other sites via Vercel, I wanted to try that option first. Luckily, Vercel has built-in support for Gatsby.

The migration was mostly a simple matter of linking my GitHub repository to a new Vercel project, bulk-copy-pasting environment variables, and clicking "Deploy", however, there was just one thing didn't work out-of-the-box: static redirects.

I couldn't find specific migration documentation on this, but it wasn't hard to figure out either. Hence this short writeup!

Recap: redirects in Gatsby Cloud

Redirects in Gatsby Cloud were made available through the plugin gatsby-plugin-gatsby-cloud. In your gatsby-node.{js,ts}, this plugin interacted with the createRedirect action. Wildcard replace rules were also supported:

exports.createPages = ({ actions }) => {
  const { createRedirect } = actions

  createRedirect({
      fromPath: "/posts/*",
      toPath: "/articles/*",
  })

}

Static redirects in Vercel

In contrast to Gatsby Cloud, Vercel does not seem to automagically transform createRedirect calls during the SSG build stage into runtime redirections.

Instead, Vercel understands a configuration file called vercel.json in the root of your repository, which can be used to configure Vercel's build & runtime behavior for a static site.

It also allows you to specify redirects, including wildcard replacement rules. The example above can be encoded as follows in vercel.json:

{
  "redirects": [
    {
      "source": "/posts/:path*",
      "destination": "/articles/:path*"
    }
  ]
}

So, to migrate:

Transform the format of your rules into Vercel's JSON format (see docs). If you have many rules, you can use tools like VSCode regex search/replace, multi-cursor editing, or GNU sed to automate this process.
Put those rules in vercel.json at the root of your repository.
Remove all traces of createRedirect() from your code, remove gatsby-plugin-gatsby-cloud from your gatsby.config.js, and remove the plugin package using your package manager.

That's all there is to it!

Running multiple Google Cloud functions locally with the functions-framework

Thor Galle — Thu, 27 Oct 2022 10:47:17 +0000

So, you want to run multiple node.js Google Cloud Functions locally at the same time using Google’s functions-framework?

You might have previously written cloud functions in Firebase, where the Firebase Local Emulator Suite allowed you to run all your functions simultaneously, on a single local server, with a single command (firebase emulators:start).

The function framework does not provide an emulator that can do this out-of-the-box. However, you can very easily write one yourself, and approximate Firebase’s local development experience this way.

This approach combines your functions in a single Express “meta” app for development purposes only. You can still deploy the functions individually to Google Cloud.

Example setup

In this example I have the following directory structure:

├── package.json
└── src
    ├── index.js
    └── functions
        ├── firstFunction.js
        └── secondFunction.js

The function scripts

The two functions themselves are full-fledged Express.js handlers, like they would be in Firebase.

To test that the two functions can interact, the first function returns HTTP 302 redirect, which redirects to a GET request on the second function.

// src/functions/firstFunction.js
export const firstFunction = async (req, res) => {
    res.redirect('/secondFunction');
}

// src/functions/secondFunction.js
export const secondFunction = async (req, res) => {
    res.send("OK! You were redirected here.");
}

package.json

The package.json refers to the src/index.js as the main node script. We also need to tell the functions-framework to target the index export within the index.js module:

// package.json

...
"type": "module",
// Tells the functions-framework where to look for exports.
"main": "src/index.js", 
"scripts": {
    "start": "functions-framework --target=index", // Select target export
    "debug": "functions-framework --target=index --debug"
}
...

index.js

The index.js file is the core of this setup. It’s where we will expose all functions combined on a single local address, as well as expose functions individually.

// src/index.js
import express from "express"
import { firstFunction } from "./functions/firstFunction.js";
import { secondFunction } from "./functions/secondFunction.js";

// Solution to expose multiple cloud functions locally
const app = express();
app.use('/firstFunction', firstFunction);
app.use('/secondFunction', secondFunction);


export {app as index, firstFunction, secondFunction};

The local functions-framework will target the index export exported from index.js, see the package.json above. The index export is only meant for local development purposes, so we can run multiple functions at once locally.

We still export the individual functions too, so we can easily deploy both functions individually. See “Deploying functions individually” below.

Running the functions together

Now if we run npm run start, a development server will start on http://localhost:8080.

Running curl http://localhost:8080/firstFunction will print OK! You were redirected here., demonstrating that both functions are running at the same time.

If you still want to test a function in isolation, you can run functions-framework --target=firstFunction instead, after which you can call it as usual with curl http://localhost:8080.

Deploying functions individually

Functions can still be individually deployed, with the gcloud CLI:

gcloud functions deploy firstFunction --project=my-project --runtime nodejs16 --trigger-http --allow-unauthenticated  --security-level=secure-always --region=eyour-region --entry-point=firstFunction --memory=128MB --timeout=60s

gcloud functions deploy secondFunction --project=my-project --runtime nodejs16 --trigger-http --allow-unauthenticated  --security-level=secure-always --region=your-region --entry-point=secondFunction --memory=128MB --timeout=60s

The key here is --entrypoint firstFunction flag, which is similar to --target flag on the functions-framework command. It selects the module export of the index script that should be seen as the entry point for the cloud function.

You could also deploy the index export as a single function that combines all functions in one, but then you would have call /index/firstFunction and /index/secondFunction on the cloud, and you then can’t scale or modify the function runtimes individually anymore.

Caveats

Using Express “sub apps” this way is not a 100% watertight way to emulate multiple individual functions running in Google Cloud. There are some caveats.

`req.originalUrl` ⚠️

Express Docs

This property is much like req.url; however, it retains the original request URL, allowing you to rewrite req.url freely for internal routing purposes. For example, the “mounting” feature of app.use() will rewrite req.url to strip the mount point.

req.originalUrl doesn’t behave as it would in a real production Google Cloud multi-function setup.

On Google Cloud, req.originalUrl excludes the function name. This is likely due to some internal redirections that Google Cloud does.

With the index.js emulator proposed by this post, req.originalUrl will still include the function name.

Make sure that your code does not depend on the value req.originalUrl for some decisions. If it does, you might need to adapt this code.

`req.path` behavior ✅

In Google Cloud, accessing req.path in a function running on https://your-google-cloud-domain/firstFunction will yield /, and not /firstFunction (somewhat suprisingly).

With the above caveat, you might wonder, does this behavior also not copy to our local emulator setup?

The answer is: this behavior remains the same. See the Express documentation for req.path:

When called from a middleware, the mount point is not included in req.path.

When we call app.use('/firstFunction', firstFunction);, we register firstFunction as application-level middleware onto the app with the “mount point” being /firstFunction.

More?

There might be other caveats I’m not aware of with this setup, but for now it suits my purposes, and the added local development convenience is worth any future complications.

References

Closing note: this solution is based on an answer in a related GitHub Issue thread that you might have seen already when researching this issue.

I wrote this post because that thread contains several approaches to this issue that were less relevant to my use-case (and, the thread was also filled with more drama than necessary). I hope developers used to the Firebase functions model find this setup suggestion helpful.

What makes a good programmer? A misleading question.

Thor Galle — Wed, 24 Nov 2021 12:50:05 +0000

This is a response to "Cargo cult programming is killing the (Sri Lankan) software industry" (direct link, Readup link). I was writing a comment on Readup, but it became its own blog post!

As a person who programs for a living, I think it's easy to have an opinion and personal bagage related to the skills and knowledge you need to succeed in your job. The topic of the article speaks to all of us, it plays on the question: what should a good programmer know, and what should they be able to do?

It's a misleading question however. I don't think there is, and there should not be, one single kind of programmer.

First of all, the genius programming nerd with all the right skills in computing doesn't exist anymore. They might have existed a few decennia ago, when computing was an offline niche with very few applications. But today's computing world is too diversified for this human to exist.

Intimately knowing networking fundamentals, and how the Linux kernel interacts with networking hardware, doesn't automatically make you the good front-end web developer that can learn Svelte quickly after having built web apps in React for five years. In fact, you might not know much about the DOM at all.

Computer systems in the hands of end-users are massive contraptions where millions of people and brains had a hand in: from the person who assembled a website, to the people who designed the HTTP protocol, to the admins of the cloud service that serves the web server container, and many more. I'd argue that since computing is "eating up" much of the global economy, the incomprehensible complexity of the economy becomes the complexity of computing too. That complexity is timelessly illustrated by the essay I, Pencil (a recommended read!).

A good point of the author though, is that we need to be able to distinguish different jobs in computing. "Programmer" or "Engineer" doesn't cut it. A "WordPress Technician", as the writer would call them, who knows all the best WP plugins and understands a little bit of PHP, can assemble a website fit for an indie magazine much faster, cheaper and better than a "cloud engineer" at Google who's creating algorithms for efficient load distribution of incoming network requests. They're people with totally different jobs doing totally different things.

Another good point is that for many jobs in computing, it's a good idea to dig a little deeper down the levels of abstraction than would seem strictly necessary. But depending on your career goals and interests, you could constrain that effort to what might be useful for you. A React front-end developer that entered programming through a one-month bootcamp would be wise to understand how React interfaces with the DOM, because that will indeed make understanding Svelte easier when React goes out of fashion (hypothetically). Learning sorting algorithms might be useful too, if they are trying to remix a big dataset for some purpose, with a triple for-loop in JS that makes their laptop overheat. Soon they will also need to adapt their jobs to be able to build front-end apps for the VR internet in 10 years. But is it essential for them to know how heaps and stacks work? Not really. That's why we have abstraction: to manage complexity. You only need dig deeper if you want to do something that would require that knowledge, or if you're just curious.

This reminds me too of a self-deprecating twitter thread of Lauri Voss, one of the NPM founders:

"I am, at best, a developer of average ability. [...] I have come to accept that I'm never going to invent some brand-new algorithm that changes the world."

But he comes to terms with this own assessment of his abilities in developing algorithms:

If there's a thing I'm above-average at, it's spotting patterns and weaving a narrative around them to explain what's going on. I explain. [...] Given that's my deal, being a mediocre developer is weirdly kind of helpful. I tend to see things the way most developers do.

In the capacity as a teacher, he has likely made a massive contribution to the computing economy. And that's just fine.

The point of this blog post response was to illustrate that there are different skillsets in programming, and that this is just fine. The article it responds to however also talks about a "brain drain" in relation to tech workers in Sri Lanka. It's another issue which I assume is related to late-stage colonialism and outsourcing.

The Basics of Dependency Maintenance in NPM/yarn

Thor Galle — Mon, 07 Jun 2021 09:22:35 +0000

Think back: you're about to start contributing to a web project. You clone it, run npm install, and then... you get one error after the other. You can probably name at least one of these experiences. In the worst case, this can lead us to abandon our plans of contribution. The bad news is that this bad experience is ubiquitous. The good news is that it is entirely avoidable, and it's not even that hard to avoid!

This post is a collection of best practices regarding dependency maintenance in NPM, they help you keep your project in a healthy state so that if you ever have to hand it over, invite collaborators, or revisit it, it won't be an absolute pain in the ***.

The tips

Make sure you understand Semantic Versioning
Use & commit the lockfile
Update dependencies regularly
Take on less dependencies

(clicking will lead you to the specific section)

I wrote this as a synthesis of my experience maintaining a Nuxt.js website project for two years at Columbia Road, and working on several other projects in a sub-optimal state. It is intended for readers with some general JS-stack web development experience, but with little experience maintaining a web project.

Note that the focus here lies on the consumption side: the managing and updating of dependencies in a web project you're working on. This is not discussing how to maintain an NPM package that you have published, although there should be some overlap in best practices. Basic familiarity with git is assumed.

1. Make sure you understand Semantic Versioning

First things first: whether you're installing dependencies, updating dependencies, or you're publishing your own package and making changes to it, understanding semantic versioning (semver) is essential.

Most software projects today use semver to tag versions of their program releases (eg. v1.2.15). The versions have three numeric parts: major.minor.patch. The major version should be increased by one ('bumped') when the software interface of the dependency has breaking changes (which means: your code will break or behave differently if you update the dependency without changing your code). Even when the breaking change is seemingly small and simple, like a changed function name, the major version should have been bumped. If package publishers do not respect this, it can easily lead to problems when people consuming those packages update their dependencies: they end up installing incompatible dependency code!

Another important realization is that semver defines several range types of versions, that is, saying that any version that is included in a certain range of versions is OK to install as a dependency. The caret range (~) in particular is the default version notation used when you run npm install some-package to add a new package to your project (thus, in your package.json). It mostly allows variations in the minor and patch versions, which is usually safe. However, its exact definition is important to check out, as there is an exception that allows more versions than you might expect!

2. Use & commit the lockfile

Both NPM and Yarn have had a system a lockfile for some time now: package-lock.jsonin NPM or yarn.lock in Yarn. But what does this file do?

This file keeps track of the exact versions of all your dependencies and their sub-dependencies. Concretely, it lists which dependencies are stored in your node_modules folders at this moment.

This is very useful, because another developer with the same lockfile can install exactly the same dependency tree on a fresh npm install. Without a lockfile in place, different dependency versions could be installed at different times despite being installed from the same package.json. The reason for this is that "desired versions" in package.json are often specified as a relatively loose range, such as the caret range discussed before.

The problem with having a different (newer) version of a dependency than another team member, for example 3.7.24 instead of 3.5.2, is that it always carries the risk some changed behavior that breaks your code in one way or another.

Commit your lockfile so that everyone shares access to it, and changes to the dependency tree are tracked in git. This will even enable you to time-travel (roll back) to the exact state of an older version of your project via git.

Note also that in general, you should avoid mixing the usage of npm and yarn in your team, because using two different lockfiles may lead to problems where you end up installing different package versions despite having a lockfile. The risks of having such issues have decreased over the last years (npm now also reads yarn.lock, which it didn't before), but even if it's just for consistency & simplicity, picking one is better.

3. Update dependencies regularly

Check for new dependency updates regularly, for example, every 2-3 months, depending on how frequently you work on your project.

Why not just stick with what works now?

Not updating your dependencies means incurring technical debt. This debt will make it progressively harder and costlier to update later, when you really need to.

For the example's sake: let's say you didn't update dependencies for two years, this can can cause major headaches. Here's why:

The JS ecosystem moves fast. Some of your dependencies might already be deprecated in two years time!
It may become harder to update the dependencies, because dependencies typically make assumptions about their environment or other ('peer') dependencies (for example, sass-loader is built for a specific Node.js and webpack version). The latest version of one dependency might not fit in your old, potentially deprecated, environment anymore, causing issues.
Changelogs and migration guides become progressively harder to find as time advances. Guides to update to a new major version are sometimes stored on a project's website, which might lose history quicker than git. It then requires detective-level work (e.g., the Internet Archive) to find back these migration guides. And when finding them, they may be outdated. I had this issue when updating from Nuxt 1.4 to Nuxt 2, which had been released a year before I did the update.
Community support is better for fresh issues. When developers notice an issue in a fresh update, they usually file a GitHub issue on a project. This makes it possible to find quick workarounds and solutions that you can apply as a community. But if you research issues two years later; A) chances are no one cares anymore to help with a two-year old issue. B) It may be harder to find old solutions amongst a mess of other search results: search engines seem to prioritize more recent search hits.

Now imagine that your product has a critical security flaw caused by one of its dependencies. To fix it you might encounter any of the above headaches. In the worst case, you have to do heavy refactoring or simply restart your project.

Hence, spending maintenance time to keep things up-to-date is probably cheaper in the long run. Here's a simple routine of how to do it:

Dependency updating routine

Use this routine to update your dependencies:

Run npm outdated or similar to know which dependencies are outdated.
- "Wanted" describes the maximum version of a package that is allowed by the range in your package.json (which is usually the caret (~) range, which excludes major breaking versions).
- "Latest" is the last version available (includes major breaking versions when available!).
For each dependency, check the changelog or version notes of all the versions ("releases") of the dependency between your target version, and the one you have currently installed. This step is crucial when you're doing a major-version update. It could be useful when doing a minor-version update; and can often be skipped when it is a patch-level version (see the section about semver.

👆 Caveat: watch out when you use exact packages and you see a major upgrade

If you use exact version definitions and are on an old major version, the Wanted column will only show the version you have installed (for example, vue-router@3.5.3) When Latest shows a major version upgrade that you don't want (vue-router@4.0.14), this can obscure minor/patch updates that you do want.

In this case, also run npm view vue-router@3 version to get the list of available v3.x.x package, and manually check if you can bump the minor/patch version.

👆 How to find the changelog of a dependency?
There are various approaches that open-source package maintainers use to keep a change log. But mostly, they use GitHub's versions and releases pages to write notes on what changed (and updating instructions).

To find the GitHub Releases of a package:

In a browser: go to https://www.npmjs.com/package/ and click "Repository" to find the GitHub repo of a package. Then, on the right in GitHub, click "Releases".
Fun trick: run the npm CLI command npm repo <package-name> to immediately open the GitHub repo of a pack

👆 What if there is a major version (breaking) change?

Always read the release notes/changelog of breaking changes. Breaking changes might require you to change your code in some places when doing the update. Watch out especially for notes that relate to other dependencies: maybe a breaking change in one package requires another dependency to be updated or installed alongside it? Maybe it requires a new Node.js version?

3. If updating seems safe, perform the updates.
👆 Choose the applicable update method depending on the version you want to update to
Choose the applicable update method depending on the version you want to update to
- npm install <package_name>@<version_number>, always installs the given version, ignoring whatever version ranges are specified in your package.json. In fact, it will by default modify your package.json to hold the version you're installing. You might need to use this method to bump the major version, or when you don't use caret version ranges but exact versions in your package.json.
- npm update <package_name> installs the latest version permitted by your package.json, for example: new minor and patch versions when you were using a caret version range.
👆 Update strategy: include limited update in a single commit

Updating one dependency per commit, or at least, updating outdated packages in batches, may be useful when doing many updates after not updating for a long time. I usually do it like this:

I bundle patch-version updates in a commit
Minor/major versions are in their own commits

Why? This way you can more easily find back the dependency update that broke something in your project.

If you do npm update with a list of 30 dependencies to be updated, there is a high likelihood that something will go wrong. And it might be hard to pinpoint which (combination) of those 30 dependencies was the culprit.

Test after each update

Ideally you have a fully-automated & reliable test suite that can test whether things broke or not on every update. This is often not the case however, so you most likely should:

Do a build and run the project after an update. Resolve any errors that appear. Commit
Repeat the above
After the final update, do a more thorough testing round by trying out most paths in the app. If something seems off now that you didn't see before (e.g. something doesn't render, but there was no error thrown on build time), use the next method to detect which dependency caused it.

Detect a problematic commit (= dep update) with `git bisect`

If you do 1 update with 1 commit at a time, and an issue surfaces at the end, you can efficiently detect which dependency update introduced it with the git tool git bisect (docs, included in git). Instead of rolling back the commits one-by-one to see where the issue was introduced, this tool guides you through a "binary search" through a commit range, asking you to mark a commit as "good" or "bad" depending on their behavior, quickly narrowing down the range of potential commits that might be the culprit, ending at a single one!

👆 ⚠️ Don't have a lockfile? Duplicate the project before updating!

Do you have functioning project installed locally without lockfile that has (very) old dependencies, e.g. it was running on node 4? Don't start updating immediately! You risk losing control over the project beyond repair.

Make a duplicate of the entire project folder to start the update, there's a high chance that an update will break something. Without lockfile, you can't travel back to the original functioning state. By duplicating you can preserve your original node_modules which enables you inspect a functioning version of the project if needed, or to roll back if you're really stuck.

4. After updating, run npm audit to figure out which dependencies have a security vulnerability. Is a fix announced? If not, maybe you can switch to a different dependency.

👆 What if a sub-dependency is causing a security issue?
If a sub-dependency (dependency of a dependency, or even further) is causing the issue, but your direct dependency does not offer a new version that updates the sub-dependency, you can try to "override" the sub-dependency in the direct dependency using in Yarn using selective version resolutions (since yarn v1, released on Sep 16, 2020, we're at 1.22.5 at the moment of writing).

4. Take on less dependencies

It's obvious but worth mentioning: the easiest way to avoid dependency issues is to avoid having dependencies. Taking on a dependency is always a trade-off between the value or time-savings it offers, and the maintenance costs of managing code that you didn't build yourself.

Recap: action points

Here are action points to follow-up on these best practices.

Learn about semver
Make sure your lockfile is committed to git
Set up a scheduled recurring task in your calendar/task manager to update your dependencies

I hope this helped! In a possible next post on this topic, I may look at some more advanced ways of future-proofing & debugging, such as:

Preventing issues with a ci install
Using exact semver versions for all your dependencies
Best practices specifically for Node.js projects

Credits

Apart from my own experiences, these notes were partially based on the talk "Future-proof dependency management in TS projects talk" by Olavi Haapala

Tech Weeklies - Future-proof dependency management in TS projects - 05/20 - Olavi Haapala

Finding the original mp4 video of a GIPHY Capture

Thor Galle — Mon, 03 May 2021 08:18:12 +0000

What if you're using GIPHY's fun Capture tool on macOS, spend some time creating recordings, only to realize that GIFs are not the best format for your recordings?[^1] Or, you just want to archive/share/reuse a higher-quality version of your recording?

The tool does not offer a solution to export the original recordings, but it does store them somewhere! And that somewhere is here:



/Users/YOUR_USERNAME/Library/Containers/com.fasthatchapps.gifgrabberosx/Data/Documents{% raw %}`
```

![video-location](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bah4xtgqv0n0h3kslx82.png)

You can enter this directory by hitting `Shift+Cmd+G` in Finder, copy-pasting the above path, replacing `YOUR_USERNAME` with your username into the above path, and clicking "Go".

Hope this helps someone on the internet (hi! 👋).

## How did I find this?

All thanks to the nifty tool [AppCleaner](https://freemacsoft.net/appcleaner/). It's intended to erase programs from your Mac entirely, but it seems to work just as well as a forensic tool.

![appcleaner](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2vx3inygmo8ytv92q3tx.png)

[^1]: GIFs are enormously inefficient and bulky compared to MPEG/web format videos. Too bad we're stuck with them for our daily dose of internet madness.

Use image-set() while supporting Firefox with dynamically loaded background images

Thor Galle — Fri, 27 Nov 2020 14:20:14 +0000

You don't need to do anything special anymore 🥳 There is full support for image-set in Firefox since version 89 (released Jun 2021). Go browser standards!

Here's a demo. You'll see it works in Firefox:

The below is an INVALID, old article about a problem that once existed when Firefox didn't support image-set. Only kept for questionable archival purposes. I will probably unpublish this article later.

<div style="
/* fallback */
background-image: url('fallback-img.jpg');
/* responsive */
background-image: -webkit-image-set(url( ... responsive image set ...));">

Solution: put those rules in a <style> tag instead to support fallbacks.

Note: this blog post was a learning from a project at Columbia Road, an updated version can be found on the company site: Tech logs: Use image-set() while supporting Firefox with dynamically loaded background images

Modern browsers widely support the HTML srcset attribute that enables responsive images (MDN, CanIUse). But for its CSS background-image equivalent image-set() (accessible through -webkit-image-set()), there is no support for IE11, Firefox, Firefox for Android and Opera Mini (MDN, CanIUse). (I'm ignoring IE11 overall).

Support of major browsers for image-set() as of November 20, 2020. Source: CanIUse

Of course you'll want to have a non-responsive fallback image for these non-supporting browsers. Well, that's not as obvious as it sounds.

Problem: using `style=""` doesn't work

You might be tempted to try the following CSS with a fallback url() expression, that gets overwritten with the -webkit-image-set() expression whenever available.

<div style="
/* provide a fallback for Firefox */
background-image: url('../img/image-2x.jpg');
/* override with a responsive image */
background-image: -webkit-image-set(url('../img/image-1x.jpg') 1x, url('../img/image-2x.jpg') 2x);
">

Unfortunately, if you add the above code to a style="" attribute (as you would often do when you generate responsive background images somewhere), Firefox 84 will complain with this error in the console:

⚠️ Error in parsing value for 'background-image'. Declaration dropped.

How sad. It dropped the whole style attribute value because it could't load the -webkit-image-set(). As a result, it does also not display the fallback.

Solution: use a `<style>` tag

The following code works however:

<head>
    <style>
        .my-image-id {
            /* provide a fallback for Firefox */
            background-image: url('../img/image-2x.jpg');
            /* override with a responsive image */
            background-image: -webkit-image-set(url('../img/image-1x.jpg') 1x, url('../img/image-2x.jpg') 2x);
        }
    </style>
</head>
<body>
    <!-- this div should have an image background on it -->
    <div class="my-image-id background-box"><div/>
</body>

It seems that a style tag can still be parsed, even though one rule in it is not supported by the browser.

A few things to consider here.

You need a unique class name for each image.

The reason you came here in the first place might have been that you wanted to use the style="" attribute, because you were dynamically adding background images to a template using client-side/server-side image data.

In that use case, you now you need to perform a few intermediate steps:

Generate a unique class name for the background image set
Add that class to the desired <div> (or other element)
Add a CSS rule for that class to a <style> tag somewhere. This could be a new tag in the <head> OR <body>. It should contain the fallback & responsive background-image URLs for that specific images.

For step 1, you could use a GUID generator. In my project however, I used a JS function to generate valid class names from an alphanumeric image ID string that I got from an API.

Tricky to add style rules to the `<head>`?
You could add them to the `<body>` too!

If you were previously trying to add the styles to a style tag, it might be tricky to add styles to a <head>, for example, when coding in a restricted server-side template where you can't access the <head>

One solution: it's actually possible to add <style> tags to the <body> as well. This is not a good practice since it's non-standard. But it seems to work in most browsers. I tested this in BrowserStack, and so far only UC Browser on Android seemed to have problems with this technique. Here's an adaptation of the previous example with body style tags:

<!-- this div should have an image background on it -->
<div class="my-image-id background-box"><div/>
<style>
    .my-image-id {
        /* provide a fallback for Firefox */
        background-image: url('../img/image-2x.jpg');
        /* override with a responsive image */
        background-image: -webkit-image-set(url('../img/image-1x.jpg') 1x, url('../img/image-2x.jpg') 2x);
    }
</style>

Hope this helped! Feel free to leave a comment if anything is not clear.

HubSpot's Undocumented Image Resizing API

Thor Galle — Thu, 19 Nov 2020 17:34:22 +0000

TL;DR: Resize your HubSpot-hosted images by using URLs of the form https://f.hubspotusercontent40.net/hub/${PORTAL_ID}/hubfs/${IMG_NAME}.jpg&width=400&name=${IMG_NAME}.jpg. Your mileage may vary, read the post for more info!

If you are looking for image optimization on HubSpot CMS templates only, HubSpot supports that by default. You can stop reading here 🙂

This article is about requesting resized versions of images that are hosted on HubSpot, but from a non-HubSpot site. You might be in this situation when you're getting HubSpot-hosted image URLs through the HubSpot CMS Blog API, CMS Files API or CMS HubDb API (possibly others too).

Note: this blog post was a learning from a project at Columbia Road, an updated version can be found on the company site: Tech logs: HubSpot's Undocumented Image Resizing API

Nowadays, responsive images are not a gimmick anymore. With a web that has an equal share of mobile and desktop users, responsive images are a must if you don't want a user to bounce on a slow-loading, image-heavy web page.

Modern browsers widely support the HTML srcset attribute that enables responsive images (MDN, CanIUse) and its CSS background-image equivalent image-set() (CanIUse). But automatically creating responsive image sets is not trivial. You usually use a specialized media hosting service or Digital Asset Manager for that (e.g. Cloudinary or Contentful). HubSpot also provides this service, but it is somewhat hidden. Read on to learn how it works.

Problem: no documented HubSpot Image API

In a project at Columbia Road we recently became stewards of a site driven by Nuxt.js. Large images on the site were causing long loading times. Many of these images came from HubSpot: the Nuxt.js site used the HubSpot Blog API to generate a listing of blog posts, and these blog posts had featured images that were hosted on HubSpot.

To reduce the loading time we needed to implement responsive images, but while HubSpot magically supports responsive images and on-demand image resizing in its own HubSpot CMS template pages, it did not expose a documented API for doing that externally on a non-HubSpot page.

Solution: an undocumented API

Here's how we did get access to an API anyway. Since HubSpot has an internal mechanism for generating responsive srcset attributes and specifying a certain image width, we could figure out if we could somehow influence that mechanism from the outside. A starting point was by looking at the output of responsive images generated by HubSpot.

Modifying the image size

To inspect the output of HubSpot's responsive image resizing mechanism, we made a test Coded HubSpot CMS Blog Page Template in HubL. We included the following source code that handles the featured blog image, as suggested by the image resizing documentation for HubL pages:

{# Note: this is an excerpt of a Coded HubSpot Blog Template to use as an illustration, it's not a fully working template #}
<img width="200px" src="{{ content.post_list_summary_featured_image }}" />
<img width="600px" src="{{ content.post_list_summary_featured_image }}" />

When looking at a preview of a blog post with the above template, the corresponding HTML output was generated for the images (see this by inspecting the HTML of the preview page):

<!-- Variable Portal ID and image title are omitted for the privacy of our client -->
<img width="200" src="https://f.hubspotusercontent40.net/hub/${PORTAL_ID}/hubfs/${IMG_NAME}.jpg&width=400&name=${IMG_NAME}.jpg">
<img width="600" src="https://f.hubspotusercontent40.net/hub/${PORTAL_ID}/hubfs/${IMG_NAME}.jpg&width=600&name=${IMG_NAME}.jpg">

We see here that the <img> tag that got a width="400px" attribute in a Coded HubSpot Blog Template now has a corresponding URL ?width=400 query parameter related to image resizing. This starts to reveal a solution to our problem: we can modify this parameter to request a different size of the image.

But we're not ready yet. How do we generate these image URLs ourselves?

Transforming a generic image URL into responsive URLs

Let's consider our original input in Nuxt.js, which we got from the Blog API data: in the response of the official Blog API, we found that the HubSpot Blog API gave us generic image URLs in the following basic formats:

# URL type 1 - for featured images
https://cdn2.hubspot.net/hubfs/${PORTAL_ID}/${IMG_NAME}.jpg

# URL type 2 - for featured images
https://f.hubspotusercontent40.net/hubfs/${PORTAL_ID}/${IMG_NAME}.jpg

# NOTE: this might vary on your portal.
# The HubSpot File Manager suggest that you can also use branded domain name from the site for these two types
https://brand.com/hubfs/${PORTAL_ID}/${IMG_NAME}.jpg
# A third image type for author icons also exists, but won't be covered here as they are already small thumbnails.

Here I should note that these input URLs might vary based on your Portal and the source of the URLs. Check the API response you're looking at or HubSpot's media manager to find your input URLs. The output URLs might also vary. If you don't know what they are, replicate the template test I did in the previous section.

For the URL types 1 and 2 that we encountered it was possible to extract the PORTAL_ID and IMG_NAME from the Blog API responses with a regular expression, and then reconstruct a URL of the output form which we saw in the last section. The resulting transformed URL succeeds in loading images of the requested size: mission accomplished.

The following function on CodePen implements this transformation. Feel free to adapt it to your needs!

Caveats

There are some caveats to mention:

'Undocumented' probably also means 'unsupported'. If HubSpot would break or change this functionality, and you can not respond quickly to revert the image URLs to their original form, images on your site could break without warning. See Alternatives & Improvements on how to mitigate this situation.
Give it some time. For some images it took some time (tens of seconds to minutes) from the first requested resized image in order for the actual resized image to appear. This could be due to scheduled resizing processes or variable time in CDN distribution at HubSpot's side.
No complete support. For some reason unknown to us this resizing only works for ~90% of the images where we tried it on. For some images the original resolution is returned, no matter what size parameters we give it.
Only width & height controls. Other Image optimization APIs pformat format (e.g. WebP) and quality parameters. This API doesn't clearly expose those. Note: it seems that HubSpot is serving WebP by default when using these resizing options APIs.

Alternatives & improvements

One important improvement on the above code would be to load images via JavaScript. In such a case, you could detect potential 400 or 500 error codes when HubSpot changed this API's functionality or signature, and you could automatically insert the original URL instead.

Another sure-fire approach to the whole problem would be to implement a microservice that scrapes the images from the HubSpot Blog API and uploads them to Contentful on a regular basis. This would protect you from API changes. However, this approach also has disadvantages. One, it's more costly to architect & develop. Two, it's more costly to operate because you need to manage an extra service. Still, it could be a solution if you need a massive number of HubSpot-sourced images on an external web page and you have a very low fault tolerance. At least one person on the internet has done something similar.

And with that thought put out there, this post is a wrap! I hope it can help someone who - like me - Googled for a solution to this problem unsuccessfully. It is pretty annoying that HubSpot does not have a documented API for resizing images.

DEV Community: Thor Galle

Migrating static redirects from Gatsby Cloud to Vercel

Recap: redirects in Gatsby Cloud

Static redirects in Vercel

So, to migrate:

Running multiple Google Cloud functions locally with the functions-framework

Example setup

The function scripts

package.json

index.js

Running the functions together

Deploying functions individually

Caveats

req.originalUrl ⚠️

req.path behavior ✅

More?

References

What makes a good programmer? A misleading question.

The Basics of Dependency Maintenance in NPM/yarn

The tips

1. Make sure you understand Semantic Versioning

2. Use & commit the lockfile

3. Update dependencies regularly

Why not just stick with what works now?

Dependency updating routine

Test after each update

Detect a problematic commit (= dep update) with git bisect

4. Take on less dependencies

Recap: action points

Credits

Finding the original mp4 video of a GIPHY Capture

Use image-set() while supporting Firefox with dynamically loaded background images

Problem: using style="" doesn't work

Solution: use a <style> tag

You need a unique class name for each image.

Tricky to add style rules to the <head>?You could add them to the <body> too!

HubSpot's Undocumented Image Resizing API

Problem: no documented HubSpot Image API

Solution: an undocumented API

Modifying the image size

Transforming a generic image URL into responsive URLs

Caveats

Alternatives & improvements

`req.originalUrl` ⚠️

`req.path` behavior ✅

Detect a problematic commit (= dep update) with `git bisect`

Problem: using `style=""` doesn't work

Solution: use a `<style>` tag

Tricky to add style rules to the `<head>`?
You could add them to the `<body>` too!