Today is the day that one of the coolest things I had the pleasure to
develop so far in my life has gone live to production use.
One installation of PopScan is connected to
a SAP system that had at times really bad performance and yet it
needed to be connected even just to query for price information.
This is a problem because of features like our persistent shopping
basket or the users templates which cause a lot of products to be
displayed at once.
Up until now, PopScan synchronously queried for the prices and would
not render any products until all the product data has been assembled.
When you combine this with the sometimes bad performance of that SAP
system, you’ll quickly see unhappy users waiting for the pages to
finally load.
We decided to fix this problem for the users.
Aside of the price, all product data is in PopScan’s database anyways, so
while we need to wait for prices, everything else, we could display
immediately.
So that’s what we do now: Whenever we load products and we don’t have a price
yet, we’ll launch a background job which asynchronously retrieves the prices.
The frontend will immediately get the rendered products minus the prices.
But of course, we still need to show the user the fully loaded products once
they become available and this is where the cool server based event framework
comes into play:
The JS client in PopScan now gets notified on arbitrary events that can happen
on the server (like “product data loaded”, but also “GPRS scaner data
received”). The cool thing about this is that events are seemingly pushed
through instantly as they happen on the server giving the user the immediate
response they would want and lessening the load on the server as there’s no
(well. only long-) polling going on.
$(ServerEvents).bind('product-data', function(data){
// product data has changed!
}is all that we need on the client. The rest happens automatically.
Also remember though that PopScan is often used in technology-hostile
enterprise environments. Thus, features like web-sockets are out and in
general, we had to support ancient software all over the place.
We still managed to make it work and today this framework went to production
use for that one customer with the badly performing SAP system.
Over the course of the next few weeks, I might write in detail about how this
stuff works given the constratins (ancient client-software behind hostile
firewalls) and what software components we used.
Seeing this work go life fills me with joy: I’ve spend to many hours designing
this framework in a fool-proof way in order to not lose events and in order to
gracefully continue working as components in the big picture die.
Now it’s finally live and already contributing to lower waiting times for all
users.
gnegg 