Make it easier to get started with webhooks

[byrichardpowell]

WHY are these changes introduced?

We want to make it easier to get started with declarative webhooks

WHAT is this pull request doing?

1. Provide the config for mandatory webhook topics
2. Add a product create webhook, so partners can see a webhook trigger when pressing "generate a product"
3. Separate each webhook topic into it's own URL

Test this PR

shopify app init --template=https://github.com/Shopify/shopify-app-template-remix#declarative-webhooks

1. Run npm run dev. Do you see a message like this: webhooks │ APP_UNINSTALLED webhook delivered
2. Click generate a product in the UI. Does the product create webhook trigger?
3. Does the webhook config match the routes correctly?
4. Does the code in each webhook make sense?

Checklist

• I have made changes to the README.md file and other related documentation, if applicable
• I have added an entry to CHANGELOG.md
• I'm aware I need to create a new release when this PR is merged

[lizkenyon]

A while back we had talked about using snippets as a way to share common code patterns with developers, and I feel like this could be a good use case!

I would like to confirm with the webhook team, but I am thinking for the privacy webhooks we want to be able to process them even if the app is uninstalled/has no session.

[cdarne]

That's a great way to tidy all the webhooks handling! Most of the webhook endpoints should not rely on a session or admin to be set, as the app could be already uninstalled for app/uninstall and compliance webhooks.

Ideally, we'd like to encourage receiving webhooks and respond ASAP and then do the processing asynchronously or using a job queue. (I understand that's probably out of the scope of the template)

[cdarne]

You're comment is right: the session might not be defined when processing a webhook request. From what I can understand, authenticate.webhook will first validate the webhook origin (by checking the HMAC signature from the headers) and then it will try to load an offline session and admin. But this can fail so we can only count on the shop, payload to be defined here.

TLDR: you can drop the session check IMO.

[byrichardpowell]

We are effectively using the session check here to say "Did we already process this?". Using shop, I think we'd need to do something like this:

  const { shop } = await authenticate.webhook(request);

  // Webhook requests can trigger after an app is uninstalled.
  // If the app is already uninstalled, the session may be undefined.
  try {
    db.session.deleteMany({ where: { shop } });
  } catch (error) {
    console.error(error);
  }

Try/catch is the recommended way in Prisma to delete without raising exceptions if the record exists. I don't think try/catch is quite as nice.

WDYT @lizkenyon & @cdarne ?

[lizkenyon]

I think for this case it makes sense to check for the session!

We could add another sentence for clarity if we wanted 🤷

// Webhook requests can trigger after an app is uninstalled. 
// If the app is already uninstalled, the session may be undefined, which means it has already been deleted.

[byrichardpowell]

@lizkenyon @cdarne please can I get a second review?

Note i also updated the README to steer partners towards app-specific webhooks