feat(gatsby): add support for image-cdn

[wardpeet]

Description

Improve remote file handling by adding a new interface "RemoteFile" to GraphQL. This new interface allows source plugins to lazily download images and has native compatibility with gatsby-plugin-image.

To enable support for RemoteInterface, you'll need a couple of fields to be present on your node:

  url: `https://remote-url-to-file`,
  placeholderUrl: `https://remote-url-to-file?w=%width%&h=%height%&q=%quality%`,
  mimeType: `image/jpg`,
  filename: `name.jpg`,
  filesize: 10000,
  width: 800,
  height: 600,

As noted about only url, filename and mimeType are mandatory for regular files. Images also need width & height specified. The placeholderUrl field is a bit special as we added the option to give use a url with macros, so we can generate a smaller image to generate a placeholder to speed up query running.

With these nodes the RemoteFile Interface adds custom resolvers to your GraphQL type, without you needing to know how they work.
It adds publicUrl to generate a public facing url, resize to resize an image to a specific size and gatsbyImageData to give you a compatible data blob to use with gatsby-plugin-image.

---

The implementation is a bit hard to follow as everything is added inside gatsby-plugin-utils to support older gatsby v4 versions as well. You can upgrade gatsby-source-contentful without upgrading gatsby itself.

A source plugin can implement Gatsby's image CDN by wrapping the GraphQL type with the addRemoteFilePolyfillInterface in `createSchemaCustimization like this

import { addRemoteFilePolyfillInterface } from "gatsby-plugin-utils/polyfill-remote-file"

addRemoteFilePolyfillInterface(
  schema.buildObjectType({
    name: `PrefixAsset`,
    fields: {
      // your fields
    },
    interfaces: [`Node`, 'RemoteFile'],
  }),
  {
    schema, // schema you get as an argument from createSchemaCustomization
    store, // the redux store of gatsby also part of createSchemaCustomization
  }
)

Last but not least you'll need to add some extra routes to the dev server as well.

import { addRemoteFilePolyfillInterface } from "gatsby-plugin-utils/polyfill-remote-file"

addRemoteFilePolyfillInterface(
  schema.buildObjectType({
    name: `PrefixAsset`,
    fields: {
      // your fields
    },
    interfaces: [`Node`, 'RemoteFile'],
  }),
  {
    schema, // schema you get as an argument from createSchemaCustomization
    store, // the redux store of gatsby also part of createSchemaCustomization
  }
)

Documentation

Related Issues

[TylerBarnes]

@wardpeet nice work! 🙌 The polyfill means it will work for users upgrading source plugins while staying on an old gatsby version. What about the other way around? Users upgrading gatsby but not source plugins. Will that break their existing GraphQL queries? I think we need to release a breaking change release for source plugins, but for gatsby we should probably put the new resolver changes under a flag or some other opt-in mechanism (perhaps a new gql field to make it opt-in?)

[LekoArts]

Only managed to look at the first couple of files, need to look at it again tomorrow

[wardpeet]

These changes are necessary as lmdb can also be required from gatsby-core-utils which can lead to multiple versions. Wich leads to different paths and we want to patch all lmdb versions that need patching.

[wardpeet]

make the test reach other lmdb modules

[wardpeet]

Changes necessary to pass tests, without it name conflicts happen

Fixed, we'll update todo later

[nrandell]

Quick question on this. If you do a 'gatsby clean' on your development machine, does this delete the cache folder containing any processed images?

I love the feature though!

[TylerBarnes]

@nrandell it does 👍 On Gatsby Cloud images will be cached even when the site cache is invalidated but locally the images will be deleted. The nice thing is they're only fetched and processed once you visit localhost in gatsby develop, so it's not such a big deal if they're deleted