The Shopify Functions API is great, but the input query complexity limit is a major blocker. It means that, if you use Functions in a public app, you will eventually hit a wall where you can’t add the features merchants want without workarounds that degrade user experience.
Problems:
- Why does every single user of a Function have to share the exact same input query? In public apps, it’s extremely rare for the same two users to have the same logic. Most fields end up unused, but you still pay the price. Function instances can already have instance-specific query variables, so why not instance-specific queries? This wouldn’t require increasing the limit past 30, and it would open the door to tons of customizability. See Can the input query complexity be dynamic based on actual input values? · Shopify/function-examples · Discussion #566 · GitHub .
- Why are we penalized for querying
CartLine.id,DeliveryGroup.handle, orDeliveryOption.handle, when those are necessary for Functions to be able to target them? - Why are we penalized for reading a
DiscountNode’s configuration metafield? Other metafields are understandable, but if the configuration is essential for the Function to work, why should it have the same cost?
Currently, the only workarounds are:
- Create multiple discount types with slightly different queries (confusing for users).
- Remove features from existing Functions to make room for other fields in your query. It’s not always possible to be 100% sure of which features are in use, because your access tokens (which would enable you to read the Function configurations) may be missing or expired. If you don’t already have your own backups of every Function’s configuration, it’s a risky guessing game.
I would love to have a discussion about this to hear what other Functions users think.
Best,
Tobe