Here are my findings so far.
1. Shopify does only allow 1 shipping provider /rate per order.
2. Hence, it sends all the request to every CCS endpoint.
3. Timeout for each CCS request is 10 seconds. Such that requests are sequential in no specific order.
4. Each request has a list of line items.
5. Each request has the same signature for destination if properly hashed using a key of shop's domain name.
6. Such that each request cannot be found in a specific order. Which complicates the matter. It is sent in the order in which the cart is organized at the time of request.
7. However, given the complications it should be possible to arrive in a routable list of waypoints and destinations.
8. OSRM / Google Map should be able to deduce the list of waypoints into a series which are pickups and a final delivery location.
9. Once we have the routed list, we map the line items into the waypoints. Hence a final route is produced with weight & packages.
Last three steps are repeated, as long as there are new requests coming. The longest distance covered by a delivery service will always be a longest. Any location in between would adjust the distance length by a different margin, but shall not reduce it. Hence the price may become valid for certain services. At the end of the CCS requests, there will be a route of waypoints and final destinations. The cost can be calculated.
The one which I configured in the server now, uses a simple local redis instance. It can be scaled to have a Cluster. In a cluster, max response time could not be more than 500ms. Single 1GB redis instance should be sufficient to do a minimum of 1000 carts per 15 mins.
Which gives 8.5 seconds for the request to complete safe manner.
At the end of order submission, when shopify marks the items fulfilled, it would be possible to capture each block and push them into a same order for the shipping provider if the provider was choosen.
I do not think this can be much of a realistic solution.
Is the idea that you log all the CCS requests, hash by address, then on the last (nth) CCS request calculate the price for the entire route and return a rate?
How will you work out if said request is the last one? (i.e. find n)
I think for the responses to the other CCS requests (1 - n-1) you will also need to return the same rate names as what you intend to return on the nth request and set those rates to 0, this way Shopify will combine the rates correctly.
The idea is that each request is handled on full for each request until all requests are fulfilled. There is no need to worry about N number of requests. Each request is also cached in parts allowing to reconstruct the route each time.
As long as request are sequential, the requests would either extend the route length / fall inside / extend by a smaller margin. We add the difference in margin to each sequential request as the rate. Shopify will finally combine. No need to worry about the next request until it comes. We only need to keep a list of previous requests and the line items up from that point. We build a route for the shipment company using that. The same code for shipment would be used.
This is in the hope that pricing for a shipment would not go down.
I have been exploring this problem in my mind space for couple of hours. I have one more question, given that Store having multiple inventories, Shopify will send multiple requests for the same item to be delivered from different locations? If this is a no, Then the flow control logic I have been thinking should be valid to process for an order.
Ah i see, your use case is a bit different to mine, as you want the rates to be added anyway, this doesn't really pose a problem, whereas in my use case, the customer wants to apply a rate over the entire cart, i.e. free shipping if entire cart is > $x, in which case we will need wait til the nth request so we know what the entire cart is, or use a cart token to look it up before hand (however all the unknowns makes this method inaccurate).
For multiple locations, if multi-origin shipping is enabled (and this is where the inconsistencies lie anyway), Shopify will try and find a single location which can fulfil all items in the cart, if it can't find a single location, it will work its way down the list of locations stored in the Shopify admin and try and fulfil as many as possible at each location until all locations are fulfilled. From what i can tell, once it's split the order into these 'shipments' it should send a single request for each location and those items, unless that request receives no rates in response, in which case it may try another location.
I was wondering if there was any update on this, especially with regard to news/ETA on the new API you mentioned?
We would love to implement local delivery accross our stores, but we also have a custom shipping rate calculation that is based on the contents of the whole cart, and it's a deal-breaker for us if we can't keep this :(.
Are there any further updates to when this new API will be ready? We are finding increasing number of merchants finding that multi origin shipping is impacting their ability to set accurate shipping rates. It would be really good if either multi origin shipping can be turned off by default or more focus be made on this to make it easier for merchants to setup their rates.
I'm hearing reports from merchants that Shopify is no longer allowing them to disable multi-origin shipping.
I have a large number of merchants approach us still looking for a workaround to this as multi-origin shipping won't allow them to set a rate across the entire cart at all, this means it is impossible for them to offer say free shipping > $100 across their entire store and is a major deal breaker for new merchants, and also existing merchants who have inadvertently enabled multi-origin shipping without understanding the new behaviour.
Over the past few months, merchants have been able to successfully request via Shopify support for multi-origin shipping to be disabled, has a decision been made to stop this workaround? Without any updates to the Carrier Service API, there are currently no workarounds at all with or without an app for merchants. What is the recommended course of action here?