Sean's blog

Pos Malaysia e-commerce shipping quote with AJAX

spider.my is long gone: the shipping API has moved to Shipping-Quote.net

Pos Malaysia shipping quote at spider.my – part 1

Here’s a first shot at an AJAX-powered Pos Laju shipping quote. As I said in my previous article on a Pos Malaysia shipping quote API, there should ideally be two: one simple one for blogs and low-volume e-commerce sites, and one for large-volume businesses. The shipping quote demo at spider.my is very simple: just enter a weight and a destination, and click on a ‘Quote’ button to get an up-to-date quote from Pos Malaysia’s website. This is a terrible way of doing it, as spider.my retrieves a whole web-page from Pos’ website, just for one price!

You can see how slow it is if you submit the form. Part of that is nothing to do with Pos Malaysia – spider.my is on a server in the USA, so there’s massive latency between your browser (probably, if you’re in Malaysia), the spider.my server in the USA, then back to Malaysia for the quote request, then back to USA with the quote page, where it’s processed using pattern matching to extract the price, then back to your browser with the finished page.

To demonstrate the simple Shipping rate quote API, I’ve added an AJAX updater to the page. That’s a little bit of asynchronous javascript that executes in your browser. When you change the weight of the parcel, or its destination, that script will request a quote matching the new details from spider.my. To give you a feel for how an API at Pos Malaysia’s website would respond, the AJAX updater only provides responses for previously-cached quotes at spider.my. That way, there’s no need to make another long request to www.pos.com.my!

Request timings for AJAX XML shipping quote request

Have a look at the XML sent by the shipping rates demo – it’s extremely small. Comparing the timing (again from Chromium) for the transfer of the XML response from spider.my to the timing of the transfer of the quotation webpage from www.pos.com.my from yesterday. Remember that the spider.my server is in the USA, so network latency is going to be higher. Pos’s local latency isn’t great – but their server must build that page before it can transfer it. Spider.my is only building a very small (less than 100bytes!) XML message. The real benefit comes when the data is transferred. The XML message is so small, Chromium is probably defaulting to 1ms for a timing. The whopping great page from pos.com.my takes nearly a quarter of a second to transfer! For user interaction, that leaves very little time for anything else.

Notice that getting the price update via AJAX from the USA takes a total of just under 300ms, while the local method, from Pos’ website, took just under 350ms. Even with the handicap of being served on the other side of the planet, the AJAX technique is much faster. It should be clear that if the AJAX response was coming from Pos’ server, not only could the response be hundreds of times faster, it would be hundreds of times more efficient in bandwidth.

I’m not ready to try to convince Pos again to provide an API. To make it more convincing, I need to handle any quote that Pos can handle. For that, I need to acquire their rates. That sounds like hard work, since Pos don’t make their entire rates available in any other format than photocopies (I have a set – I won’t be using them). I have a cunning plan for that. Once I can provide super-efficient one-shot quotations from my server, I’m going to tackle a client-side solution for businesses that might need to (a) not depend entirely on Pos’ server being available (b) get the fastest possible quotes. That depends on my cunning plan working so that there’s an efficient way of getting an update from Pos whenever they update their rates across the board.