All I know is there a million other things I would like to see Shopify sort out, rather than trying to optimize for App builders that cannot handle complexity, and would rather Shopify do it for them. With all the missing functionality, and quirks, I would rather be pushing for that, than "my query gets rated as too complex, please help me".
This whole thread emerged from that, and likely won't ever go away. I get it. I am not stubborn, but straight up, there are actual real tough problems we need Shopify to work out, rather than tweaking the lowest fruit on the tree stuff. In order to build non-trivial Apps that will service the next generation of Shopify platform merchants.
A fair opinion. Though it's hard to see raising a rate limit as a difficult fix, and perhaps we're both biased in which parts of Shopify we use most frequently, but as an app developer, it's hard to see this as low hanging fruit. Not when you look at the complexity it'd take for a single employee to evaluate this, provide some insight, and consider modifying how the rate-limiting works, and propagate that up the necessary hierarchy of command. This thread emerged from our building of a non-trivial app. We're still handcuffed by this non-trivial issue, and while we've produced workarounds, there are other issues that emerge from such complexity or relative limitation. It's certainly not the most important item, perhaps it's not even a remotely important item, but over 25,000 shops have used our service to provide a specific set of functionality, and despite how low that number is when compared to 1 million merchants, it's still a fair amount. There may be several other developers who don't get as far as to comment here, who are also handcuffed by the need to now build a sufficiently complex system, and perhaps they abandon their next-generation app idea. All in all, I think this is a valuable issue to look into. Fair enough that we disagree.
To me the takeaway has always been that if they accepted every request at face value, and modded the system to fix, we'd be worse off. If they fixed your issue, the unintended consequences would be chaos for someone else. Balancing off interests and ensuring everything keeps working reasonably well is the clarion call.
When they first released the first API, I made an App that filled a hole in Shopify. To my dismay, Shopify allowed 3 or 4 copy cats into App store, filling same said hole, while telling me to suck it up, competition is good for everyone. I did not cry. I moved on, and learned a lesson. When they started growing and all of a sudden began patching those holes, I found it a bit scary as holes became scarcer to find and fill. Still, I accepted retiring my hole fillers and moved on, lessons learned. When they stopped payments on earned affiliates I brought in because I stopped bringing in affiliates, sure I complained, and rightly could've dropped the whole platform as a reaction. But I didn't. When they forced 'us' to market our Apps with "design" I reluctanctly hired out some design, even though I knew it was a mistake. And sure enough, they changed their minds and made us do complete re-designs. And now we cannot even diddle with our Apps without getting a internal review first (for the most part). And then browsers started their anti-cookie war, and Polaris remains half-baked, and on and on... it never stops.
TL:DR; my point is that while you think it is just one employee that could make all the difference, and do something you think is simple, and that would make 25,000 merchants you service happier, I guess I just don't see it that way. I see it more as wow, the shit we can do with our talents. Regardless of the hoops and struggles. It keeps getting better, and even the worst stuff is still years ahead of the majority out there. Dude. I work with people on Shopify that make millions and yet still, their ERP/CRM is email and Excel. We've got it good. Even though sure, some GraphQL features remain sludgy.
These are fair assessments, but I don't agree that the question warrants such an initial dismissal of the overall idea. It's just a discussion on looking into the GraphQL cost algorithm. It's a discussion, and the opinions can be sorted such that Shopify might have a separate talk internally on whether or not it's worth considering an increase. Telling an app developer to essentially suck it up, is strange.
I'm not going to trivialize the difficulty of performing such an update, but I can trivialize that it would be easy to look into and potentially push up the heirarchu of command. It's not an update that, if done right, would have any negative side-effect at all. It's an increase in a rate limit (or rather, a decrease in the cost of accessing nested variants), it's not the modification of data that is passed back.
The question is also in no way meant to pinpoint this as a need solely for our platform, or to only affect the users of our service. An update in a rate limit might benefit hundreds or thousands of other developers who use the GraphQL API.
Shopify publicly mentioned on Twitter that the public adoption of GraphQL is slower than expected. Perhaps this is an underlying issue people face, which has stunted the adoption. I'm offering my anecdotal experience and opinion to think it is, and to gather constructive feedback. When more apps work with the GraphQL API, that benefits everyone, including Shopify.
We have differing opinions, and that's fine. Our business was built off the back of the exceptional API that Shopify has provided, so we agree that we have it good. Nothing wrong with pointing out where a potential improvement can be made, despite how many improvements are still in the pipeline.
It is true, the machine is not tuned well. I can write a query that exceeds the 1000 limit, and yet the reality of running it would be far less. The heuristics if you will, are off in cases. Are we sure they are monitoring this, and adjusting? Pretty sure. They seem to know a lot, and when questioned, usually have an answer hard to dispute. So if write a query that estimates a complexity of 200 and yet delivers the goods for < 20, am I to be impressed or distressed?
So far these limits have not bothered me, although I am getting tired of just how bad the work-a-day environment is. Not everyone's problems but some that rattle me continue to be:
- this godawful disconnect of snakecase camelcase GraphQL exhibits in it's uses
- error handling with results is arguably stone age at this time
- while cursors work, the overhead of using them is madness and has no DRY
- way too many things are improperly documented, as machine generated documentation boasts of features not yet implemented but exists as stubs
When we point out how nice it would be if we could have XYZ, almost always the underlying reason we get a no is because the original and still going strong mysql database is sub-optimal and does not scale nicely for our sweet spots of need. So much simple SQL could unleash beastly speed, but we'll not get there from here, as lipstick on a pig, is well... you know. I am pretty sure when this Shopify project started, mysql could not handle a select in a select. And even though Shopify has nursed it to a form of superduperforshopifymutantforshopifymysql, I am betting it is getting hard to improve in some ways. I mean their engineering team just published a blog that informed us they discovered composite primary keys make a difference! Huzzah!
What is a dynamic cost predicated on variants? You do not know apriori if you have just 1, or 100. So you have to take that into account. How would you adjust this?
I don't know if it's technically possible, but I don't think it's unreasonable to have the number of variants to not be included in the cost at all when joined with the product. Similar to the REST API, the limit is for the product, not the number of variants included in each product. Sounds like a gross over-simplification and defeats the purpose of the cost model, but if it's technically plausible, there's nothing wrong with making exceptions in the cost model to make this better. This would GREATLY reduce the number of calls having to be made and in a few very small cases where clients actually have a ton of variants should be a drop in the bucket in regards to creating abuse. not discounting the alternative methods, but also not discounting the original post either.
When a requestedQueryCost is 930, but the actualQueryCost is 45, something to me seems obviously unoptimized. For me, this post is about optimization and if fixed, would take product queries in GraphQL to another level in terms of both efficiency and ease of development.
Also, I didn't see either @HunkyBill or @Stephen_Gardner address the youtube video comment I made in your follow up. I'm curious what you guys think about that directly. This really did trip me up when I watched it. Was the limit higher at that time or is there no way this was the actual code behind the page it was suppose to represent?
I think the issue is rooted in how variants have taken on a life of their own in the SQL schema. Where before a variant was simply A Product has many Variants, now we have the fact that:
- inventory is multi-location, and multi-origin
- a single variant can be assigned to N locations, with inventory at each location
- a single variant has inventory cost separate from the variant itself
So now we have a tree where the joins to get at the nitty gritty are not one level deep, but are three. So looking at a single product, and asking for everything that matters about the variants is actually expensive. The fulfillment services, tied to locations, and feeding off of shipping profiles, all that is glued on extras not available with a simple join. So while conceptually viewing variants as a NO COST attribute of a product is logical, the reality of how Shopify glued on an entire resource management structure way after the fact is probably the problem here. In extreme examples, the cost of a query could be 1000+ and I think they use estimates of worst-case rather than scanning the reality. My guess is that even if they scanned for reality to generate the estimate, it would be a waste of time since one product might be trivial, whereas it's neighbor could be a full on nightmare of connections. Since you do not know that, you always guess for the worst and hope for the best. Until they engineer their way out of that rabbit hole, we are stuck writing more queries to expose the info we need.