In computer programming, loosely typed languages do not have strict data type rules. Variable types can change during program execution. The interpreter will try to make sense of the code even if two types don't match. By contrast, strongly typed languages define variables with specific data types. In case a variable is assigned a value that is of the wrong type, the compiler will give an error.
Each approach has its pros and cons, and which one works best depends on the use case. Languages that are loosely typed provide greater flexibility, while strongly typed languages can simplify and speed up development.
At least as an analogy, these principles can also be applied to content data modeling. In a system that represents products, for example, you can define a "loosely typed" Product model that adapts to different product types (e.g., shoes, shirts, bags, etc.) or you can define "strongly typed" models (e.g., Shoes, Shirts, Bags, etc.) that are specific to each product type.
If you are working for an ecommerce platform vendor, you have no other choice but to follow the loosely typed approach. This is because your model must support any type of brand and catalog. Instead, if you're building an ecommerce website for a specific brand, you don't need to support any type of catalog, only yours.
As a result, there is a high chance that the loosely typed approach is overkill and complicates things beyond what is necessary. In that case, you should model your catalog using a solution that provides a flexible schema, such as a headless CMS. This will allow you to define strongly typed product models, simplify your development, and make your merchandisers' lives much easier.
Ecommerce platforms provide loosely typed product models.
The most popular ecommerce platforms all come with catalog management functionality, so they're like content management systems for category and product pages.
As general purpose platforms, i.e. platforms designed to serve any type of business with any type of catalog, their data models are also generic. Typically, they provide a base Product model that includes name, description, and other attributes that must make sense for any type of product.
The reality is that for different types of products, a specific set of attributes and features is needed. As an example, clothing can have material and color attributes; consumer electronics can have different resolutions, memory, or storage capacities; food and beverages have ingredients and nutritional values.
Some ecommerce platforms support this level of flexibility by providing Product Type models that can be configured with specific sets of product attributes. The list of attributes that apply to a Product depends on its Product Type association.
With this model, to create an instance of a pair of black shoes, as an example, you will need to:
- Create a Product Type with name "Shoes" (if not present).
- Create a Product with name "Black Shoes" associated with the "Shoes" Product Type.
- Create an Attribute with name "Color" associated with the "Shoes" Product Type (if not present).
- Create a Product Attribute with value "Black" associated with the "Black Shoes" Product and the "Color" Attribute
The pseudo-code to retrieve a pair of shoes' color will look like this:
It is also common for products to have variants, which can have several options based on the product type. Shoes can have different sizes, monitors can have different resolutions, etc. A way to model this possibility is by creating an Option model and associating it with the Product Type. A Variant is created by combining options, with the possible alternatives determined by the associated Product Type.
To create an instance of a pair of black shoes of size 12, you will need to:
- Create a Variant with name "Black Shoes (size 12)" associated with the "Black Shoes" Product.
- Create an Option with name "Size" associated with the "Shoes" Product Type (if not present).
- Create a Variant Option with value "12" associated with the "Black Shoes (size 12)" Variant and the "Size" Option
The pseudo-code to retrieve a pair of shoes' variant size will look like this:
Engineers like me find this model and approach very linear. Actually, nothing is wrong with it. It is flexible and allows you to support any type of product. However, this flexibility does come at a cost, as merchandisers have to take quite a few steps just to create a simple product with one attribute and one variant. Moreover, in order to get a product out of this model, developers need to join a number of entities that can affect performance and response payload.
As mentioned, platform vendors have no other choice than to provide such a standardized data model. However, if you work for a brand with a well defined range of product types, you can leverage a headless CMS to design a simpler and more tailored model to meet your needs.
Headless CMSs allow you to define a strongly typed schema.
Imagine a brand's catalog contains shoes in a variety of colors and sizes. Instead of a generic Product model, you can define a Shoes model with all attributes that are relevant to shoes, such as their name and color. Likewise, instead of a Variant model, you can define a Shoes Variant with name and size attributes.
To create an instance of a pair of black shoes, with a "size 12" variant, you will need to:
- Create a Shoes with name "Black Shoes" and color "Black".
- Create a Shoes Variant with name "Black Shoes (size 12)" and size "12", associated with the "Black Shoes" product.
The pseudo-code to retrieve a pair of shoes' color will look like this:
And here's the pseudo-code to retrieve a pair of shoes' size:
Can you see the difference? Flexibility is great, until it isn't.
When it comes to designing your product catalog, a strongly typed content model (and a headless CMS) is often the best choice. It is a pragmatic approach that ultimately allows you to be more efficient while managing the right level of complexity.