Previously, product/update webhooks were not always sent for changes to product metafields depending on how those changes were made. The logic for sending the webooks has now been unified across all methods. A product/update webhook will be triggered for:
Will a webhook be triggered for *all* metafields or only *your app's* metafield?
For example: if my app A is connected to a store that has a different app B connected, when app B adds a metafield to the store's products, will app A get the product/update webhook?
I'm worried about getting a lot of product/update webhooks that show no apparent change without making an extra query to check for metafield changes.
Why would you send a webhook for a Product that changed when in reality it was the attached Metafield Resource? By all means send a Webhook saying "Hey endpoint listening, YOUR metafield was changed"... but don't pollute the whole universe with mickey mouse metafield changes.
Why do these things happen? Makes little to no sense. Kind of like metafields having no owner.
Yeah I agree with Bill and Ian here, and I'm concerned about the volume of webhook requests this could potentially represent.
Don't get me wrong, it would be great to have a new webhook event to register for that provides the metafield updates, something like "product_metafields/update" or whatever, but I'd prefer not to get blasted on my existing "product/update" webhooks where I don't care what's going on with the metafields
This is consistent with the behaviour of webhooks and metafields on other models, such as orders. Metafields are public and do not have an owner; in some cases they are shared between apps. This is particularly important for apps which do any kind of syncronisation. The metafield is understood to be part of the product, so when a metafield changes, the product has changed.
This is consistent with the behaviour of webhooks and metafields on other models, such as orders. ... The metafield is understood to be part of the product, so when a metafield changes, the product has changed.
Wait, so are you saying that for consistency sake we'll also be getting orders/updated when order metafields are changed? Ditto for customers/updated when customer metafields are changed? And shop/update when shop metafields are changed? Just trying to understand the implications here
Edit: Just tested out creating an order metafield and saw that it does indeed fire the orders/updated webhook, I hadn't realized that was the case, so I guess this new product metafields change is consistent with how the other resources operate. Though I would have preferred to see the consistency applied the other way, and not fire parent resource update webhooks when metafields are changed.
There is no doubt that a metafield belongs to a parent resource. This is not a debate about that, but it is about the decision to render consistent behaviour across webhooks.
There is justification for it, but there is no demonstration from Shopify that this so-called consistency is a good thing. For who? What are the expected changes in performance for Apps across the board. Arguably, a change to an ORDER metafield is going to occur way less than ones to a PRODUCT.
Where is the data supporting this is a benefit to all as opposed to a benefit for a few and a problem for many?
I have many Apps all listening to Product Update webhooks and I PAY FOR THAT. Now I am seeing my available bandwidth to process these webhooks shrunk by a change I had no say in, and that benefits me not at all.
There are so many holes in using metafields, it seems a shame effort is expended on making them even more cumbersome than less.
Consistency is a tough row to hoe. You can be consistently wrong, and pursue consistency for wrong reasons. To be consistently behaving poorly is not a goal one really wants to polish.
As an example, using the API, one can ask for resources from Shopify and page through them. There are also methods in the API where you cannot do this, and you are limited to 50 resources no matter how many exist. This inconsistency is arguably way more important to address rather then if a metafield changes, something only the App that created it cares about and should program for.
So yay! Work towards consistency, but not by imposing changes without demonstrating the how and why we benefit when it costs us our bandwidth to deal with an already immense amount of overhead.