The first time I looked into Strapi was 2019. It looked like a project going in an interesting direction, but I didn’t play with it much. With time to spare on my hands over the last few months, I figured I’d look at Strapi again. It’s come a long way!
There are plenty of great resources online about Strapi, so I’ll try to avoid being redundant. There’s a great post on the Strapi blog about a building a starter blog that even has a one click deploy to Heroku! I figured that would be a great starting point to learning the basics, and it saved me the hassle of doing my own deployment. More importantly, it got me looking into Cloudinary (I’ll come back to that in a minute).
After playing around with that, I received an email from Strapi about building a corporate website using Next and Strapi. This is a great intro to the Strapi concept of single types as well as components.
The basic idea with this repo being that you have a global set of components for setting your core metadata, favicon, navbar, notification bar, and footer that will be used on all pages. Of course, the metadata component is also placed on the page collection type, allowing you to define the metadata on a page-by-page basis. You then add the components you want (and the Strapi team has built a fair number of common website elements as components) so that you have a fully functional website CMS.
Both of those demo repos use Cloudinary for their media management, so I took a dive into Cloudinary to see what it’s all about. WOW! What a great DAM system! They have an excellent free tier to get your feet wet, and realistically handle any developer prototyping you might come up with. The image transformation features are DEEP, and the best part is they have a ton of documentation and training/tutorials available to get up to speed quickly.
There was one issue though… Strapi was placing everything into the root Cloudinary root. So, I figured it’s time for me to make my first npm package. To be clear, I really just stole the existing strapi-provider-upload-cloudinary package and modified the code to give you the ability to specify a folder structure when you upload an image using Strapi as well as define a default folder.
So, let’s say you are using your Cloudinary account for more than one project (Project A and Project B). For Project A, you make your default_folder project-a, and for Project B, you make your default_folder project-b. Then when you upload the images/videos, they will default into their respective project folders. And if you want to have sub-folders, you just change the name to include the folder structure at time of upload. Further details and images are available on the GitHub page for the package.
Let’s say you have assets that you want to use on Project A and Project B… Well, just upload the resource with a leading / and it will place it into your Cloudinary root (along with any folder structure you provide), and then use it for all your projects!
One import note regarding new Cloudinary accounts and PDF files. By default, Cloudinary blocks the delivery (not upload but delivery) of PDF files for new accounts. According to their support, you can email them to have that restriction lifted. I have yet to confirm that, but based upon how responsive Cloudinary has been on everything so far, it’s likely valid that they’ll lift the PDF delivery blocking if you request it.
All that said… I’m loving Strapi for rapid API prototyping and Cloudinary for an extremely powerful DAM platform!