Using Sanity CMS to model a product catalog.
Commerce Layer approaches building digital ecommerce experiences differently. We focus primarily on transactional commerce. We offer a highly flexible and unopinionated API for brands that want to go composable. However, our focus opens the door for questions that stem from more traditional “monolithic” thinking. For example, we are often asked, “Do you manage the product catalog and product content?” We don’t and don’t want to. We believe that the product catalog is just content data, and it is best managed by a composable service like a headless CMS. (It could also be a PIM, by the way.) CMSes are built to store content and model how data will be used by a client application like a webstore. Moreover, a number of leading headless CMSes are very capable of managing a product catalog. In this post, we will describe a baseline integration we built with Sanity to manage a product catalog.
This is not a code tutorial, but it is a semi-technical article that leads down the correct path to using our Demo Store Application with Commerce Layer as the commerce engine and Sanity as the CMS. To utilize the examples we share and build on your own, you will need the following:
- Commerce Layer account
- Sanity account
- Github account
- Any IDE you want to use to modify the code
What we built and how it works?
Commerce Layer offers a Demo Store application hosted on our Github page. The Demo Store serves as a reference app that any business can use as a starting point for as they consider rebuilding their digital ecommerce experience. It can also be used to see how we demonstrate a clear separation between content and commerce data. In this post, we’ll explain how we configured Sanity as the CMS to power all the content on the Demo Store, including the product catalog. All Demo Store content data is modeled and stored in the CMS, and all commerce functionality is managed by Commerce Layer.
The Demo Store serves two purposes as a prototype application: it can demonstrate and test integration capabilities between Commerce Layer and other components in a composable architecture. It is essential that it works easily with as many CMS schemas as possible. For this reason, we have created an event-driven architecture that uses the CMS webhooks. In this example, it’s Sanity’s. The webhook triggers a GitHub action that maps data from the CMS to the schema expected by our Demo Store application. In reality, such an implementation wouldn’t be necessary in a production where no data transformation would be required.
The basic Demo Store application uses a reference set of JSON files as the data model for the product catalog. We manually created those files so the app had a basic, functional catalog. But, that example falls short of production-ready capabilities. With this new demo, we take a step closer to what an actual reference stack might look like using Sanity as the content data model for the catalog. The result is that Sanity becomes the application responsible for generating the JSON files that the Demo Store application uses for its catalog.
Like other CMSes, Sanity’s Visual Studio web application opens with a blank page that requires content data modeling. For this demo, we used Sanity’s code editor to create the content model. The Code Editor is a very powerful developer feature that Sanity provides. You can do the same, working in your preferred IDE, to model anything you want. For the product catalog, we created a model that is now hosted on our Github page linked here. Feel free to clone or fork this repository to use it in your proof of concept. Below is a screenshot of the folder structure we created for the content data model for the Demo Store.
Sanity provides a templated top-level folder structure. You define the subfolders. The code in each subfolder defines what users see in the Visual Studio interface based on the data model we created. Let’s look at the items that define the product catalog:
- Catalog: The actual product catalog. There could be multiple product catalogs (i.e. one per country with different taxonomies and product reference) or a single instance for the whole website.
- Products: Base Product with related size/color variants (skus).
- Taxon: a product category. Can either contain product references or other categories (sub-categories)
- Taxonomy: the full set of categories used to model the catalog.
Sanity Webhooks
Now that the product catalog data model is created, we can seed Sanity with content and build the demo store. We created a continuous integration (CI) job that runs on Github with Github Actions. Every time new content is added to Sanity or the layout in Visual Studio changes, a web hook sends a callback to the Github Actions and the Demo Store gets updated by the CI job. To achieve this, we configured a webhook in Sanity. Let’s look at the webhook configuration:
This is a webhook configurator entitled "Trigger SSR build". The name says what it does, it triggers a server-side rendered build of the demo store any time someone creates, updates, or deletes anything in this specific Sanity space. The user just selects those options for when to trigger the hook. Then the webhook sends a payload of information to the callback URL that is input in the field. In this case, it's just a Github Action that dispatches a build. The projection box is a simple JSON file that tells Sanity exactly what to send in the callback's payload.
Github Action
The Github Action triggered by the Sanity webhook calls a sanity_exporter script to get everything we want. The process pulls content from Sanity and generates JSON files that will be published on Github pages and accessed by our Demo Store. The screenshot below shows all the data that is exported from Sanity as JSON.
This is possible because the Demo Store can read remote folders using this env variable:
NEXT_PUBLIC_JSON_DATA_FOLDER=https://commercelayer.github.io/demo-store-data-ssr/sanity/
The full set of env variables needed by the Demo Store can be found in the project documentation on Github.
Benefits of Sanity and Commerce Layer
Sanity’s philosophy of “Content is just data” aligns closely with Commerce Layer. Since the product catalog is content, it can be considered “just data”. This approach is how both Sanity and Commerce Layer are able to offer some of the most flexible, unopinionated solutions. Both companies offer a suite of powerful developer tools that enable things like data modeling in an IDE, developer collaboration and version control, and simple webhook configurations. Sanity also offers every user a clean slate to model content. With this level of configurability, it is a perfect tool to manage all content, including the product catalog data. In doing so, all content gets managed by Sanity alongside Commerce Layer, which manages all commerce/transactional data. This is the cleanest separation of concerns imaginable. Your teams can focus independently on the tools they need for their workflows. Content lives in the CMS. Commerce lives in Commerce Layer.
What’s next?
In the near future, we will also debut a Sanity Commerce application, which will be the next level of the integration. Sanity Commerce is an initiative to accelerate projects that utilize Commerce Layer as the ecommerce engine. Sanity will manage all content, including the product catalog. The result will also serve as a pre-sales tool to demonstrate the potential content architecture in a composable commerce system. The final deliverable will be a Sanity plugin that, once configured, creates a content model for a product catalog.
Our focus makes us a truly composable solution, and aligns directly with the MACH Alliance’s core principles: “Designed to easily integrate, MACH tools are easy to add in and take out of your stack so you can select best fit solutions for each domain, instead of one large platform that works “ok” for multiple domains.” The combination of content and commerce leads to a very clean separation of concerns, which truly unlocks all the benefits promoted by the MACH Alliance.