We (finally) have the ability to decide what webhooks we want to recieve and what to exclude. This has some great implications, the major one being less compute resources being used so your servers cost less.
While all of this is going in a single commit, here's the entire log on what's changed and the reasoning behind it:
-
isInitialLoad.js
We no longer need thewebhookRegistrar
function to register webhooks. So now that we're not making that GraphQL call to register webhooks, the initial load times of the app is much faster, helping with overall LCP. -
[...webhookTopic].js
This is an autogenrated file now. It creates aswitch/case
statement to handle all your webhook landings. This won't contain a case if you're using an external HTTP server, AWS EventBridge or Google PubSub, since theswitch/case
only handles requests that come to this server. -
shopify.js
Instead of using theaddHandlers()
function, we're now passing it asshopify.user.webhooks
, which doesn't affect how the baseline works and this isn't that big of a change, but how you declare webhook topics have changed. -
tomlWriter.js
andwebhookWriter.js
This is the secret sauce of parsing files and creating TOMLs and other configuration. I highly suggest to not mess with this.
- Managed webhooks don't show up when you make the GQL call to get active webhooks, so the webhooks Debug card is now useless.
- If you're migrating your live project from
webhookRegistrar()
/ GraphQL based webhooks to managed webhooks, you need to manually remove the older webhooks, or both the webhooks are going to fire twice.
- Filter
:
is actually=
and not a fuzzy search, unlike the rest of theShopify Search API it's following - Scope errors requires multiple pushes sometimes. Comment the webhooks in
shopify.js
, runbun run update:config
to push your access scopes, uncomment the webhooks and runbun run update:config
again and it'll work as expected.