Source from Cloudinary and process with gatsby-transformer-sharp?

[polarathene]

I'm aware of the similar gatsby-transformer-cloudinary package, which seems to do the opposite(upload images to cloudinary for transform and use URLs from cloudinary in production). I would like to process images locally at build via sharp, with images remotely retrieved from cloudinary.

The contentful source plugin is capable of this, it has an option to expose a localFile node in graphql that sharp transformer can operate on. In the examples for this cloudinary source plugin, I get the impression this is not possible?

The docs are not entirely clear, but is this not doing any download of Cloudinary images for deploying with a build either, and just providing an image URL to cloudinary? If the remote content is retrieved at build for deploying images as local files with the rest of the build, then being able to leverage sharp at build time for gatsby-image would be a nice feature.

[Chuloo]

Hi @polarathene actually, eliminating the use of sharp due to the long build time is the reason we use gatsby-transformer-cloudinary and gatsby-source-cloudinary. This impact of sharp may be negligible with a couple of images but when these images run into hundreds and thousands, running a build take a long time. Whereas with gatsby-transformer-cloudinary, you get the features of gatsby-image and Cloudinary in your app with much-reduced build time. with the gatsby-source-cloudinary plugin, the images are not downloaded and bundled with the project only the URLs are retrieved.

[polarathene]

with the gatsby-source-cloudinary plugin, the images are not downloaded and bundled with the project only the URLs are retrieved.

Yeah... I'd like to distribute the images with the rest of my build. I'll be looking into Cloudinary soon to try it out, but from what I can tell I can get public URLs(which is equivalent to what these cloudinary specific packages end up providing afaik?) and use those with gatsby-plugin-remote-images.

That'll then acquire the image if not in the local cache and process with sharp(again if not already processed and cached from prior build), then I'll get my processed images to distribute with the rest of the build to Netlify for example which already provides a CDN, thus one less handshake(increasing TTFB) is required.

---

I already have my project using the remote images plugin, but that image host(Unsplash) is doing something odd to some images whenever they are transformed via their Imgix API, I don't get that problem with sharp locally. As netlify does not support git-lfs(which I use for local development as my internet is not great for remote transfers of ~150MB whenever I need to clean the cache as I tweak image processing params), the remote plugin comes in handy, however needing to host the images remotely elsewhere, I had heard of good things about Cloudinary so chose to give that a look.

gatsby-transformer-cloudinary isn't as appealing to me, as it's replacing gatsby-transformer-sharp but API differs, requiring my graphql queries to be converted, but they seem to differ a bit in functionality. I assume base64Width was added to match what gatsby-transformer-sharp offers but the default differs(20 vs 30), I implemented that parameter, including some others that the cloudinary transformer lacks(eg JPG input, but with webp format base64).

Local transforms or hosting also allows for less concern about API credits on Cloudinary if they're not needed. That's not to say I don't see the benefit in what Cloudinary offers, and I'll probably consider trying it's transform API through the plugins and it's CDN in future, but supporting local download is a nice feature to transition users with existing projects to Cloudinary.

Contentful plugin did not support this request either, due to the similar intention to utilize their CMS CDN service in production. I was the one who implemented the local file download feature for the same reasons I bring up here.

---

eliminating the use of sharp due to the long build time is the reason we use gatsby-transformer-cloudinary and gatsby-source-cloudinary. This impact of sharp may be negligible with a couple of images but when these images run into hundreds and thousands, running a build take a long time.

I understand that, but it's not ideal for me for local development, I prefer not to depend on remote resources during development as my network connection is not always reliable. Especially when I travel, in China network transfer outside of China was quite unreliable for me, with builds failing when an image transfer(upload or download of original image) failed, requiring to repeat the process, including on those that were successful.

My current project is small, only ~300 image transformations for a clean build, it takes longer to download ~150MB of image data than it does to process the ~300 transforms. I have two branches, one that uses git-lfs for the images, and another that uses remote images to download. It's niche, but my use-case is that I expect to be able to use the same graphql queries for both branches, not maintain different ones for different plugins, with different output image results.

Perhaps Cloudinary isn't suitable as an image host in this way(serving content for builds, rather than users).

[polarathene]

Closing as supporting local/offline content from Cloudinary that can be used with other plugins such as gatsby-transformer-sharp is not considered useful for the typical developer using Cloudinary.

Main advantage, besides value for small projects where offloading compute and hosting of transforms to Cloudinary isn't important:

• Supporting existing projects to more easily adopt Cloudinary
• Supporting transition from deploying local image transforms with build to hosting of local transforms output via Cloudinary.
• Supporting migration of graphql queries from local transforms to remote transforms via Cloudinary.