Should processing/filtering be performed client side or server side for catalog based apps

Question

Device targeting for product XML catalog

We currently have a webservice that outputs an XML of products based on get parameters in the request. The webservice is consumed from a windows mobile application.

In front of the webservice we have an HTTP accelerator/cache that caches the results for identical URLs.

The business guys, want a new feature to allow products to be targeted for specific device configurations.

We consider a device configuration can be made of parameters such as:

• hardware model
• firmware
• geographic location
• cellular provider
• etc...

This may drastically kill the cache hit/miss ratio (efficiency) since we will be sending a param "deviceConfigId" which will be different for many devices, but will affect the list of applications outputted. We are talking 10,000 configs minimum. Our hit/miss ratio went from 75% to 40% after adding a few new features and filters via the URL one year ago.

Except for using mechanisms such as Edge Server Includes ( https://stackoverflow.com/questions/5960598/varnish-and-esi-how-is-the-performance/9914643#9914643 ) , one of the ideas we are flirting with is to movie part of the filtering to the mobile devices.

Moving filtering client side

The mobile developers cringe because this may make their mobile devices less responsive. The client devices will need to download all product information(page by page as people scrolll down) but the device will need to filter out entries. Additionally, at the beginning of loading the device must download a list of rules applicable to the specific configuration in order to apply them on all future requests and the products listed in the XML.

Keeping all filtering on the backend

The backend developers cringe with the idea of adding the "deviceConfigId" to all the requests. This will require adding even more network infrustructure and resources. The problem can be solved by adding a better load balancer and adding more servers behind it (as well as moving to more distributed technologies later on).

If we consider that user experience should be the highest priority and that slower/older devices should function as smooth as possible it seems we should use server side filtering for the product listings.

However, newer devices are coming out and older devices are being thrown out continously. Forcing the clients to do some filtering but keeping load off the backend is quite tempting.

Are there any other pros/cons, and more importantly solutions to such an issue?

Thanks

Answer 1

A good mobile developer should be able to handle the filtering on the client without affecting responsiveness by using a forward data reader. With devices being multi-core these day, filtering should be fast on reasonable sized data sets without impacting the UI. However, the time it takes to pull down the XML could make the user experience not so great. The app will remain responsive since your developers are not pulling down the data on the UI thread (right?). You can you mitigate some of this by using HTTP compression as XML is a great candidate for compression.

One reason I choose to go with a server side approach is you can fix bugs or make changes without pushing new versions of a mobile app out. If you have never been through the process of getting stuff approved for app stores, this is a big win. On top of this you don't have to worry about people running old versions of your app since you have control of version on the server.

Another option is to apply the filtering on the server side after the caching. That way you can maintain and utilize the caching already in place.