Thank you for hearing us all!
Also very open to discussions or sharing our own metrics. I have a lot of insight into LTL and multiple modals on Shopify. Hoping to make our integration public soon. Private users are doing really well with Shopify and LTL.
At the very least our failure modes are more robust now and fallback rates are going to be a thing after some more testing.
Thank you for backtracking, mistakes can (and do) happen to the best of us.
I'm one of those whom run a 'classic integration' service between Shopify and a shipping company. Upon investigation, my system only adds a few milliseconds to the request time, so there is not much to work with.
Perhaps Shopify would be able to make some kind of guide and/or supply some kind of statistics which would help convince shipping companies (i.e. the real source of the shipping rates) to improve the response times and/or add result streaming and/or some kind of deadline parameter, so that the net result is a better checkout experience for end-users in Shopify.
Ha! It would be nice to ask FedEx, DHL, UPS ad nauseum to improve their API services and speed, but unfortunately, they are not beholden to anyone but themselves.
As Tobi rightfully pointed out some time ago, while Shopify may be nicely maturing in the commerce storefront concept, it is way behind Enterprise Logistics companies like that. These companies may have an interest in shaving off seconds here and there, but since they serve the world, and the world has to wait for them, to them, there is no real reason to speed up inquiries to JOE BLOW NOBODY. As long as their own rate generation mechanism works for their own purposes AND it serves the outsiders in an acceptable manner, they do not have to do much.
In other words don't hold your breath that you'll start seeing logistics companies try and achieve sub-second rate generation to satisfy Shopify checkouts or Big Commerce checkouts, or Magento checkouts, when really, they could care a less if a customer waits 1, 2, of heck even 8 seconds. It is all about being fair, correct, and available to them. I think this whole issue is super silly.
As long as a customer sees that the rates ARE being calculated, whether it takes less than second, or 5 seconds, or even 15, when they do see the correct rates, in detail, to choose from, they will choose and carry on. This is not where customers ABANDON their carts and throw in the towel. It simply a pain point internal to the way Shopify built itself, and hence they can engineer their ways to a better way, without bothering anyone else out there.
Ha ha yes!
See @Shopify I tell you that it was just a joke! your engineers just doing a joke for funny friday! but it was not an error
I tell my merchants that it is just a joke too and they don't think it is a funny joke but I let them know it is very funny
I wonder what the next joke will be! maybe it is the publications api? that is already very funny joke for very long time!
That's great news!
What I can suggest is that Shopify will give us in the carrier request the geo location of the shipping address.
I'm sure many "slower" CarrierService API apps (ours included) are using an external service to geocode the address, which takes most of the response time.
And since Shopify geocode it anyways (You can tell based on the nice map in the thank you page), why don't you give this data to us and shave off very valuable seconds?
While we're at it, and actually more importantly - why aren't discounts factored in the cart prices that we're getting with the carrierservice request?
Most apps let the merchant offer discount on shipping based on cart total (just like Shopify's shipping rates offer), and ignoring the discount just breaks it.
It's just a tiny field to add to the request... please add it
Can somebody from Shopify help us app devs understand where the API rate request originates from? Is there a specific geo location?
The reason I'm asking is that our server is located in Ohio and responding to a request from a server in Europe can add 1/2 second sometimes vs a nearby origin.
If we could roughly "co-locate" in the same region(s) as Shopify then that could be a quick win on improving response times.
Bump ^ @Alex_B
I know the frenzy of this thread is over, but if we are all concerned about reducing the rates call roundtrip time this would be great info to provide developers. Could shave 1 second off in some cases.
Our Production Engineering team has revisited this issue with all of the community feedback in mind and has decided to implement a new dynamic timeout for rate requests, rather than a wholesale change for all requests in order protect the platform in specific scenarios. This means that the timeout values for rate requests will only drop in high-volume situations. The timeouts will have a new, tiered dynamic value based on the how many requests per minute (RPM) are made by the client. These limits are applied to each app-shop pair. The new timeouts are as follows:
These values are upper limits and should not be interpreted as a goal to develop towards. The requests are also treated as tiers, so only those requests above a given threshold will be given a lower timeout.
We have heard the feedback given here in this thread and beyond and believe this is the best way forward to both protect the Shopify platform and help maintain the current performance of your apps. Our data has shown that since these new timeouts will only come into effect in high-volume situations, this tiered system will have a minimal impact. In fact, any app that times out in this new system would have been highly likely to time out in the old system as well.