With the newly formatted webhook body that only includes the IDs of the extended variants, it requires a bunch more expensive API calls to get the details of those variants if you want to save their data to some external system, like an ERP.
For apps doing this kind of syncing, they *have* to fetch and re-fetch all those variants by ID each time a webhook arrives because there's no way to tell what might have changed with them. If you want to update titles or published status or whatever you can't tell from the webhook payload if that may have changed or not, so you must refetch every omitted variant every time. This makes it remarkably easy to consume an app's entire GraphQL rate limit just fetching and re-fetching these variants, leaving no headroom at all for doing other useful work in the app (like syncing changes back the other way).
I get why Shopify needs to send condensed payloads -- the full payload of 2k variants is too big to send all at once. But, it seems unsustainable, and like it will generate a bunch of unnecessary load on Shopify, if every app that syncs variants has to re-load all those variants each time a webhook comes in.
One way around this would be including an `updated_at` in the condensed payload. Instead of sending just the GID, send both the id and the `updated_at` that Shopify already stores. Syncing apps can then compare each variant's new updated_at to the previously witnessed one, and avoid re-fetching/re-syncing if it hasn't changed. All the variants would still need to be fetched up front during an initial sync, but after that things get snappy.
Webhooks are so powerful because they don't consume any rate limit at all, but now, we're forced to use up precious precious rate limit just to re-assemble the webhook payload we actually want before even doing the actual business logic of the app. Please throw us a bone and let us know if anything has changed!
