+1 for this
One call per product to get the metafields is way too much when you have to deal with thousands of products.
+1 for this
One call per product to get the metafields is way too much when you have to deal with thousands of products.
Soon enough we'll get GraphQL calls and then we can all get the associated metafield resources needed, and this whole silly thread can go away forever.
Do you have non public knowledge about this?
As far as I understand GraphQL is currently limited to "customer facing" entities.
It's not clear to me exactly where the boundary between customer facing and back office entities is, but I'd think that metafields are considered "back office"..
No dude, I have no secret info. But that is almost certainly where things are going. Eventually we will have GraphQL access to objects and resources. Until then, we deal with the RESTful API and do 100,000 API calls in ~14 hours. YMMV.
Therefore, whether we like it or not, we understand that using Metafields is non-performant when your call count is high. Use a different strategy. That is the secret. Knowing how to squeeze performance.
I get X calls per week from merchants that complain to me about Apps that bungle this performance issue, and there is zilch I can do for them, except to tell them they cannot use an App that is architected to fail on big product counts.
Using a lowest fruit hanging from the tree approach (sometimes Metafields), is clearly easy, but has hazards. It is obvious from the get-go, so expecting magic and a sudden elimination of this performance is not likely. We could wake up tomorrow with metafields available, but then again, if it was easy, we would've had that 8 years ago. Clearly, it is best to wait for the internal wiring to catch up, and when it does, using Metafields will likely be suitable for a wide range of uses currently not practical.
+1
Pulling in 1,000 products with their metafields currently takes around 10 minutes to complete because of the API call limit.
As others have suggested, the ability the pull metafields based on owner_resource and namespace would significantly reduce the number of calls required.
Something simple such as 4 metafields returned per product could reduce the total number of API calls from 1,004 to 20.
It's easy to play a numbers game, but you know what will happen. Some joker will figure out that with the owner resource and namespace, they can jam 100, 500, heck even 1000+ things on another resource. So what is the point? You can ask for your metafields, and if you have 2 or 3 or 7 or some modest number sure, it's a simple join, la-dee-da, off we go. But you know people will abuse this. And so you are just offloading poor performance from one area to another. And granted, it may bridge certain gaps, it will almost certainly bog down others.
Don't forget, peoplez can writez terrible codez if you let them, and flush Shopify internal performance down the drain, and so the wiring for this has to be done carefully... so ya.. it's a nice thought experiment.. but not realistic for reasons probably due to DB structure, and SQL efficiency, and the like.
Joel - why does 10 minutes matter? It's not like you're sitting there processing them by hand. Can you explain the pain point you're seeing? If this thread is going to keep being revived I'd like to at least understand the context / reasons / pain etc.
If you are grabbing that content all the time why not just cache that on your end and save the call entirely?
I must say I don't always understand why many people seem to very often push back on feature requests.
This is just that, a feature request.
I don't expect Shopify to implement all of them. I trust they have the intelligence and inside knowledge to prioritize the various requests based on the number of people asking for it, complexity of implementation, risk, peformance, etc... If they don't implement it that is fine, but are we allowed to at least express that we would like some enhancement?
Yes the work around is acceptable, but why wouldn't we strive for better? Again I don't expect Shopify to implement all requests, but it seems to me they are the one that have the knowledge to priortize. One important input is the number of people requesting it in the forums.
IMO Jamie's answer was good enough, but +1 are ok.
I really wish that Shopify would use something like uservoice to keep track feature requests.
Something like Xero does: https://xero.uservoice.com/forums/5528-xero-accounting-api
Regarding the question at hand, my own context is that I want to generate a large report that shows some metafields.
My comments are not push back, though I do like more info on the whys.
Context is important and this thread is seen internally.
I cache the retrieved data once it's received so the call doesn't go out often. However should the shop owner wish to resync their product data manually then it's a 10 minute wait while everything is re-cached.
For now to get around this long wait time I'm just storing all custom meta data on my end and skipping Shopify's metafields.
I can see HunkyBill's point that should the feature be introduced it could have a negative impact on Shopify as people might cram all their misc data into metafields.
However should the shop owner wish to resync their product data manually then it's a 10 minute wait while everything is re-cached.
If you're storing the product updated_at value you can use that as an early indicator if you even need to sync a product or not. If it matches your last cache time you know the metafields haven't changed. May save you a call or two.
Good point, thanks.
In the script editor I get three errors:
discount code requirements not met (your cart)
discount code requirements not met (empty cart)
discount code requirements not met (no customer)
The cart isn't empty and I have a customer selected. My script:
Input.shipping_rates.each do |shipping_rate|
if (shipping_rate.source == "fedex" && shipping_rate.code == 'FEDEX_GROUND') || (shipping_rate.source == 'usps' && shipping_rate.code == 'Priority')
if Input.cart.discount_code.code && Input.cart.discount_code.code == "FREESHIP"
shipping_rate.apply_discount(shipping_rate.price * 1, message: "Discounted shipping")
end
end
end
Output.shipping_rates = Input.shipping_rates
Dear Team
When I POST product data to products.json file via API using PHP below error is comming. Please Advice me
{"error":"822: unexpected token at '------------------------------d0d3b3e0e857\r\nContent-Disposition: form-data; name=\"product\"\r\n\r\nArray\r\n------------------------------d0d3b3e0e857--\r\n'"}
Thanks
Regards
Hi, I am a bit lost here.
I can create Webhook using the API but where is the secret key that I need to use to calculate the HMAC?
If I create Webhooks using the ADMIN, then I can see the secret key to use to calcualte HMAC but creating webbooks via API I am not able to figure out which secret key to use to calculate HMAC.'
Please Advice.
I'm seeing the same "access denied" error when calling checkoutCompleteWithCreditCard. Using Mobile-Buy-SDK 3.1.2 on iOS with Shopify private app storefront access token. Our test payload looks very similar to powerleydev's. Our shopify payment is also in test mode, and the credit card info is the same test credit card number(4242424242424242). Please let me know what additional info I need to provide to figure out what's wrong.
Reposting with shopify shop connected account: I'm seeing the same "access denied" error when calling checkoutCompleteWithCreditCard. Using Mobile-Buy-SDK 3.1.2 on iOS with Shopify private app storefront access token. Our test payload looks very similar to powerleydev's. Our shopify payment is also in test mode, and the credit card info is the same test credit card number(4242424242424242). Please let me know what additional info I need to provide to figure out what's wrong.
Hi Alex,
could you tel me what a polling backgorund job is please
Cheers
Barry
I Managed to get this working by having the verification in a controller and routing to the controller, but it had to be in the construct, wouldnt work in the index method