views:

92

answers:

4

I need to load a couple thousand records of user data (user contacts in a contact-management system, to be precise) from a REST service and run a seach on them. Unfortunately, the REST service doesn't offer a search which meets my needs, so I'm reduced to just loading a bunch of data and searching through it myself. Loading the records is time-consuming, so I only want to do it once for each user.

Obviously this data needs to be cached. Unfortunately, server-side caching is not an option. My client runs apps on multiple servers, and there's no way to predict which server a given request will land on.

So, the next option is to cache this data on the browser side and run searches on it there. For a user with thousands of contacts, this could mean caching several megs of data. What problems might I run in to storing several megs of javascript data in browser memory?

+1  A: 

Storing several megs of Javascript data should cause no problems. Memory leaks will. Think about how much RAM modern computers have - a few megabytes is a molecule in the drop in the proverbial bucket.

Matt Ball
Thanks Bears. That was my thought as well, just needed folks to back me up. When I got in to this business, I would spend all day trying to shave a few k off images. Things have changed...
morgancodes
+1  A: 

You can manage tens of thousands of records safely in the browser. I'm running search & sorting benchmarks with jOrder (http://github.com/danstocker/jorder) on such datasets with no problem.

Dan Stocker
Thanks Dan. What about in an app served to a broad user base, some of whom will be on older machines?
morgancodes
Well, I've run tests so far in up-to-date browsers running on recent hardware, but I think it's safe to say that as long as there's enough RAM in these old machines, it would work.
Dan Stocker
"Safe to say" makes me nervous :) But good to know you haven't run in to any problems.
morgancodes
This just in: free text search with jOrder on 1000 rows in 1st gen. iPod touch Safari runs below 2ms. No memory complaints. (35ms w/ iteration).
Dan Stocker
+1  A: 

I would look at a distributed server side cache. If you keep the data in the browser, as system grows you will have to increase the browser cache lifetime to keep traffic down.

Jim
Thanks Jim. The problem wouldn't be as the "system" grows, it would be as an individual user's list of contacts grows. Realistically, most users will have less than 1000 contacts. But some could have thousands. Not quite sure what you mean by "increase the browser cache lifetime to keep traffic down".
morgancodes
I was attempting to say that as the users increase so will traffic. And one way to decrease the traffic would be to cache the data longer. Sorry, I wondered a bit. Ignore the second part.
Jim
+1  A: 

Be careful when doing anything client side if you intend your users to use mobile devices. While desktops won't have an issue, Mobile Safari will stop working at (I believe) 10Mb of JavaScript data. (See this article for more info on Mobile Safari). Other mobile browsers are likely to have similar memory restrictions. Figure out the minimal set of info that you can return to allow the user to perform the search, and then lazy load richer records from the REST API as you need them.

As an alternative, proxy the REST Service in question, and create your own search on a server that you then control. You could do this with pretty quickly and easily with Python + Django + XML Models. No doubt there are equally simple ways to do this with whatever your preferred dev language is. (In re-reading, I see that you can't do server-side caching which may make this point moot).

godswearhats
Thanks, and thanks for the link to the mobile safari article.
morgancodes