Replies: 1 comment 2 replies
-
Does not sound like a Function so much as an enhancement to how webhooks are generated internally by Shopify. At scale, it makes sense that an order is dispatched as one paid or created to the end-point set, end of the story. Yet Shopify does allow primitive filtering in their old RestAPI with fields. One can ask for only a small subset of the whole to make the payload smaller. So why not enhance that ability? Make a webhook on behalf of a merchant, but run a small feisty bit of code and if it passes through that black box as input, the output is a special webhook. Since WASM functions are running code in the browser, but webhooks are generated internally to Shopify, it does seem to not be a Function in the same sense, but I could be wrong. Anyway, would provide greater control to Apps that do have to process millions of webhooks to get at a small subset that may be of interest. |
Beta Was this translation helpful? Give feedback.
-
I was visiting Shopify Toronto last week and speaking on a panel to the DevX / Education team.
One of the points I mentioned around webhook events, is how amazing it would be if there were a function which could allow me to filter webhook events by resources I care about.
EX: I care about one specific product being updated, I don't need 10M webhook events for all products (this gets expensive as larger PLUS stores install apps).
EX: I care about orders being created with a tag or specific line-item, not all orders.
Typically apps will run a background polling / sync mechanism, and/or receive all webhooks. Firehose style. Being able to possibly use metafields on the app or the shop which contain some filter properties would reduce many bandwidths around the globe!
For products, being able to filter on the product ID would be incredible.
For orders, being able to filter on the product/variant ID in a line item would also be incredible.
Happy to discuss further, DM me on twitter @releod :)
Beta Was this translation helpful? Give feedback.
All reactions