Recently I was involved in a discussion regarding media management in the Jamstack where I had the opportunity to share my thoughts about some of the best practices as well as available options today for developers. In this article, I will aim to give you the essence of the discussion and to investigate media management options.
In the Jamstack ecosystem today, there are two ways to manage images: either using a static site generator or, a (headless) CMS.
Both of these are viable options, and you could pick any of these in your next project. However, how are they different? Does one work better than the other? Let's take a look.
Are you new to the Jamstack? Take this free, introductory video course to learn more: https://jamstack.training/p/introduction-to-the-jamstack
Using static site generators, we create templates which will be populated at the build process, and the result is going to be a set of "static" HTML files. These HTML files can contain references to images, and each static site generator would have its way to deal with images.
In some, we may encounter an "assets" folder with static files such as images and icons for a given project. Static site generators such as Gatsby can take static assets and run them through various plugins - in the case of images Gatsby utilises a low-level image library called Sharp via the Gatsby Sharp Plugin.
Recently Gatsby has announced parallel image processing for their pipeline. In essence, they are now capable of doing image processing as a separate, standalone process which will not block the actual static site generation.
Using such plugin is an excellent start for having optimised images; however, I see several drawbacks to this approach which I'll elaborate on in a future blog post.
Other generators - such as eleventy - need us to be very specific and provide it with the location of our "images" folder. It'll just copy the content over to the final build location.
For this article, we can establish that having images stored locally for a site, and then moving the images to the final "build" folder is one way of managing our image resources in the Jamstack.
I think that this strategy is useful if we have a limited number of images. Still, if we have a large number of images, we may need to look for another solution, especially if we are building a solution where image-management needs to happen via a GUI of some sort.
Let's imagine a hypothetical e-commerce platform that we are building. Each product could be represented as a Markdown file, with YAML frontmatter blocks:
---
name: 'White T-Shirt'
price: 12.99
image: 'assets/images/white-t-shirt.jpg'
---
This product is made from the most environment-friendly material ...
If we don't want to use a CMS, we need to make sure that the image files are named accordingly, and we need to maintain them on our own as well. This could end up being a cumbersome solution, especially if we wish to add more than one photo of the product.
On the flip side, if we want to display profile pictures of employees - and currently we only have three employees in total, just having three photos is not going to be a big deal.
Now, another approach would be to utilise a CMS which would allow us to manage the content and images as well if we wanted to.
Headless CMSes are thriving today in the Jamstack ecosystem. For those who are not familiar with the term, a headless CMS is a decoupled CMS where the presentation layer and the data layer are separated. In other words, a headless CMS allows us to store and manage data (as well as users and other things that you'd typically expect a CMS to do), but they do not enforce how the content is consumed.
There are git and API based headless CMSes out there today. API based ones usually expose HTTP endpoints to return data, while git-based ones typically manage content via markdown files and git.
Regardless of what kind of headless CMS we end up using, they have one thing in common: they allow us to manage and organise our content, and most importantly, we can have an interface that can be open to non-technical people as well.
Going back to the previous e-commerce system example, we could have a CMS setup where we can easily manage products and images for the products as well. Based on which CMS we use, the images may end up in a database, or some other location but that's transparent to us. What matters is that we can manage them and retrieve them when needed.
Note that the out-of-box behaviour for some CMSes may be different. For example, Netlify CMS will still manage the images on the filesystem (and will use git), whereas Strapi will create an entry in the underlying database of your choice (SQL or NoSQL). Furthermore, both Strapi and NetlifyCMS have ways to upload images to different providers, extending their media management capabilities and giving the users and consumers much better experiences.
So is it better to manage images via a static site generator or a headless CMS? There's no easy answer because you need to evaluate which option fits your project the best. Both ways are valid and have slightly different use-cases.