Hello! We’re trying to connect Strapi, Cloudinary, and Gatsby together.
While I’ve found a lot of information on Strapi + Cloudinary, and I’ve found a lot of information on Gatsby + Cloudinary, I haven’t seen any content covering all three.
So to that end, what’s the appropriate way to connect the three? Here are some of my thoughts:
In the naive implementation, I’d integrate Strapi and Gatsby with Cloudinary independently. That means that I would:
- Strapi: add Cloudinary as a provider for image storage
- Gatsby: add gatsby-source-cloudinary to produce the nodes
- Gatsby: add gatsby-transformer-cloudinary to do the transformations in lieu of gatsby-image
The potential pitfalls I’m unsure about are:
- gatsby-source-cloudinary says it loads photos from a Cloudinary folder. Does that correspond to how Strapi’s Cloudinary provider will store photos in Cloudinary?
- Strapi already provides image nodes in GraphQL. Will it be a problem if Cloudinary is also creating image nodes? Can I use the Strapi nodes as an input for gatsby-source-cloudinary?
If anyone has any guidance on how we should go about connecting Strapi, Cloudinary, and Gatsby, it would be much appreciated! Thanks!
As you already aware Strapi is a flexible headless CMS and API that easily integrates to any frontend framework. A headless CMS has a backend where content is prepared and that’s it. The content and its data are only accessible via calls made to the API - be it REST or GraphQL. This enables developers to customize how they handle their data through various options within the API and how they can access that data using Strapi’s built in Graphql.
To answer some of your questions, here is what I’ve done in order to connect Strapi, Gatsby, and Cloudinary, simultaneously.
I begin by creating my project using traditional Gatsby.js files and CSS markdown. If I see that I would need to somehow reuse the same message on multiple platforms for various purposes, then I use Strapi to help with this process.
Since images are involved, I would have to connect to some sort of cloud service so that they can be viewed publicly. In this case, I used Cloudinary.
To use cloudinary, I installed “strapi-provider-upload-cloudinary” (the 3.0.0 version not the 3.4.1) using
npm i strapi-provider-upload-cloudinary. The reason is that I could not get 3.4.1 to work within the config file. Then I input my parameters from cloudinary into this json file.
Now, this allows Strapi to connect to your cloudinary account using a server anyone can publicly view, hence, “cloud”. If you build and deploy your Gatsby application without a cloud network, your images will not be displayed since its using your “localhost” url.
If you follow my process you will see a couple of things.
Since Strapi is using your cloudinary parameters, any image you upload from the API will automatically have a url associated to your cloudinary account. Not only does this points to that url address, it also stores that files once you save, test, build and deploy your Gatsby application.
If you find yourself using a different cloud network for hosting, you might have to upload your images manually and then copy/paste their associated urls to Strapi. This back and forth process is too time consuming and prone to errors if those urls contain the same keys (url addresses).
I personally never encountered image nodes provided by Cloudinary, just Strapi’s image nodes. Thus I’d recommend sticking to Strapi’s nodes as an input for gatsby-source-cloudinary.