Understanding metafield design

Solved
Tourist
4 0 12

Hey there.  I'm an experience software engineer, but new to the Shopify platform.  I'm working on a simple app that would be used to add metadata to products and product variants that would then be used in another part of the integration.  For example, let's say I'm selling food items and want to add calories and other nutritional data to my product records, and then have an app that generates nutrition labels based on that data.

 

When I started exploring the Admin GraphQL API, it seemed that metafields fit this bill perfectly.  They can be "owned" by various resources in the entity graph and can store arbitrary data.  So far so good.

 

However, it seems that the entire idea of metafields is organized around the idea of individual instances - i.e., there's a field called "calories" on product 1234, and there's a field called "calories" on product 1235, etc. etc.  There doesn't seem to be any concept of a field called "calories" that presents itself on all product records.

 

I don't understand the rationale for this.  Why would you ever want one product to have a field and another product not to?  What's the use case?  Looking at the fields available out of the box in the bulk editor, it seems to me that *all* of those fields would logically exist on every product; never just some.  As best as I can tell, metafields should be an extension of all those out-of-the-box fields.

 

As a result, in order to ensure that every product has a "calories" field, I would have to host an app somewhere that receives webhooks on the product create event and then react by creating the desired metafield on that individual product.  If nothing went wrong, that would at least work.  But it increases the operational cost of hosting and maintaining the app and I don't understand the benefit to this approach.  But further, as anyone who has ever touched a distributed system knows, things will go wrong.  Webhooks will fail to fire.  Webhook handlers will fail to receive correctly.  The handler's attempt to create metafields via the AdminAPI will fail.  What will result is data inconsistency, where some products have the field and some don't, and then the integration on the backside fails: nutritional labels come out incomplete (at best), or more likely, errors are produced because required data is missing.

 

Can someone from Shopify shed some light on the way this was designed?  Using metafields in this way seems like what they should be perfectly suited to do what I'm wanting to do, but there is so much friction here that it makes me ask the question: how were metafields intended to be used?

0 Likes
Highlighted

Success.

Shopify Expert
9811 92 1574

Metafields are resources attached to objects like a product but are not part of it.
They are not defined across all of the same type of object, and you’re not redefining the default fields in the product object.

 

I can see many reasons why a metafield should not exist across all of one type. An easy example is a store that sells food and recipe books. There’d be zero value adding an calorie metafield to a book. Well I guess you could but that would be weird! 

 

For a metafield to exist it can’t be blank. So if you’re looking to add the exact same value to every single product then a metafield is likely not the right way to go about things. If you are adding different values to each then it don’t see why it matters if they are global or not - you still need to make the API call to add.

 

Sounds like for your needs the app will need to have some sanity checks put in place so you can warn the user if something is missing or unexpected.

★ Winning Partner of the Build a Business competition. ★ http://freakdesign.com.au
1 Like