I have an ASP.net MVC application with a "Wallboard" screen. The problem is that this particular page takes a long time to load (it has to cycle through a bunch of databases and calculate several numbers to be displayed).
When I clicked on the "Wallboard" menu item, the browser wheel would spin for ~30 seconds before bringing up the page. I know this is very obnoxious for users, so I decided to store the previous values of the strings being displayed (last time the page was loaded) in a cookie and instantly load the page with those strings while an AJAX call retrieved newer values.
The page indicates that it's retrieving newer values, but these values don't change that often, so it's useful for the user to be able to see older values right away.
It's working but my question is, are cookies the best way to store this data? The server doesn't really care at all what values are stored, just that the page instantly loads instead of hanging. If the page has never been loaded then the wallboard is blank until the AJAX call completes.
No, it is likely not a good idea, unless it is very small amount of data.
I more appropriate solution would be to use the Caching
For example, this will cache the database data for 30 minutes, at which point the cache will expire, so any one who access the page will get a cached version and that will speed up your web site dramatically.
Cache.Insert("key", "database-data", null, DateTime.Now.AddMinutes(30), TimeSpan.Zero);
Cookies are not the right way to store large amounts of data on the client side as they are transferred to the server with every request.
I recommend you to take a look at the Local Storage API.
If you need to store a significant amount of data and require common database features, take a look at
IndexedDB.
Related
I have a 40-50MB JSON object that I need to persist across to a different page.
This only needs to happen once (one transition) but I'm still way over HTML5 LocalStorage limits, what other options do I have?
Unfortunately, that is too much data to store for most browsers. Even combining sessionStorage and localStorage both will not get us even close.
There are a few options you can try though:
You can store the data on your own server. This will depend on what web server/environment you are using.
You can use someone else's server to store the data. For example, you could use Google Drive's API. This does mean that your user needs a google account. You could also pay for a service like Amazon S3 to store it.
You could create a 'container' page, which loads and displays the pages, but keeps the session going. How exactly this works depends again on your environment.
40-50m is too huge for a browser, the worse part is if mobile is involved, what you can do is split the data into chunks, keep some in sessionStorage, localStorage and the remaining on your server, so that the part on the server will be fast enough to load, You will have to join them once all is loaded and done. I wouldn't recommend this method though.
I am creating a complex social networking website that is all one single page that never refreshes unless a user presses the refresh button on the browser.
The issue here is that when I edit files and upload them to the server they don't take effect unless the user refreshes the browser.
How would I go about and fix this problem? Should I do a time interval of browser refreshes? Or should I poll the server every 10 minutes to check if the browser should do a refresh?
Any suggestions?
Server
I would communicate the version number through whatever means you're already using for data transfer. Presumably that's some kind of API, but it may be sockets or whatever else.
Whatever the case, I would recommend that with each response - a tidy way is in the header, as suggested in comments by Kevin B - you transmit the current application version.
Client
It is then up to the client to handle changes to the version number supplied. It will know from initial load and more recent requests what the version number has been up until this point. You might want to consider different behaviour depending on what the change in version is.
For example, if it is a patch number change, you might want to present to the user the option of reloading, like Outlook.com does. A feature change might do the same with a different message advertising the fact that new functionality is available, and a major version change may just disable the site and tell the user to reload to regain access.
You'll notice that I've skated around automatic reloading. This is definitely not a technical issue so much as a UX one. Having a SPA reload with no warning (which may well result in data loss) is not the best and I'd advise against it, especially for patch version changes.
Edit
Of course, if you're not using any kind of API or other means of dynamically communicating data with the server, you will have to resort to polling an endpoint that will give you a version and then handle it on the client in the same way. Polling isn't super tidy, but it's certainly better - in my strong opinion - than reloading on a timer on the offchance that the application has updated in the interim.
Are you talking about changing the client side code of the app or the content? You can have the client call the server for updated content using AJAX requests, one possibility would be whenever the user changes states in the app or opens a page that loads a particular controller. If you are talking about changing the html or javascript, I believe the user would need to reload to get those updates.
My AngularJS app behaves similarly to Gmail, in that it loads up a bunch of data to the browser with a "loading" screen. There are 3 javascript objects being retrieved from my database here and they take a little a few seconds each to load.
Once loaded, they permeate through the app and are used in various views and controllers.
However, if a user opens up one of the app's links in a new tab, they obviously to be re-loaded. I can see why this happens, but I'd much rather save the 5-10 seconds of loading time for the user and have someway of sharing the data between different tabs.
Is this possible at all, perhaps using Angular's $cookie service or caching? I'm quite new to this style of programming so detailed answers are most definitely appreciated!
As the two people above answered, you can do this via LocalStorage. However, if you begin to write your data to the LocalStorage, and try to keep the LocalStorage in sync with your server storage, that task quickly becomes a full time job that is full of bugs. Use a library for this.
THIS SITE has a few options.
I know, localStorage supports up to 5MB only. In our application we are planning use localStorage (sessionStorage doesn't fits for our need, since we support multiple tabs). Currently there is only one big javascript object serialized and stored in localStorage, in the future it may exceed up to 15 objects but definitely not more than that.
The problem is, clearing the localStorage. Since our application allows user to login in multiple ways (SSO etc...). So without landing in Login page, they can login into our application and as well as signing off in other application will sign off in our application too or close the browser. For security reason, we need to clean the localStorage once the user session is over.
So we planned to store the personId in localStorage, in every page request along with the html response we send the personId from the server, and if it doesn't match with the localStorage's personId then it will clear the localStorage.
My doubt here is, search in localStorage is not asynchronous so will it take much time to search personId out of 15 keys (Which has some large string as value)?
localStorage.setItem("personId", 1234);
localStorage.setItem("object1", "A very big serialized form of javascript object gets stored");
Writing values is really fast and there is no significant difference between large and short values: http://jsperf.com/local-storage-set
You can test the search on this site too... You could share the search code too, so others can take a look on it.
I'm working on a web based form builder that uses a mix of Jquery and PHP server side interaction. While the user is building the form I'm trying to determine the best method to store each of one of the form items before all the data is sent to the server. I've looked at the following methods
Javascript arrays
XML document
Send each form item to the server side to be stored in a session
The good, the bad and the ugly
Depends on your application functionality and requirements, but Javascript would probably be the best way. You can use either arrays or objects or whatever in javascript. It's server independent and it will preserve data over a long period of time as long as client session stays present (browser window doesn't close for whatever reason) but this can be quite easily avoided (check my last paragraph).
Using XML documents would be the worst solution because XML is not as well supported on the client side as you might think.
Server side sessions are good and bad. They are fine if you store intermediate results from time to time, so if client session ends because of whatever reason, user doesn't loose all data. But the problem is that it may as well expire on the server.
If I was you, I'd use Javascript storage and if needed occasionally send JSON serialized results to server and persist them there as well (based on business process storig this data somewhere else than session could be a better solution). I'd do the second part (with sever side combination) only if I would know that user will most probably build forms in multiple stages over a longer period of time and multiple client sessions. but can be used for failure preventions as well. Anyway. Javascript is your best bet with possible server-side interaction.
Preserving data between pages on the client
Be aware that it's also possible to preseve data between pages on the client side. Check sessvars library for this. So even if the page gets refreshed or redirected and then returned all this can be stored on the client side between these events like magic. Marvelous any rather tiny library that made my life several times. And lessened application complexity considerably that would otherwise have to be implemented with something more complex.
I used TaffyDB to store data, and it's just wonderfully easy to implement.
Hope this helps you
You may want to check out PersistJS, which exposes a cross-browser persistent storage object. Of course, being persistent, data stored with this library survives sessions, not just page changes.
The latest version (0.2.0) is here – note the version in the above linked post is 0.1.0.
A combination of #1 (although I'd use objects, not arrays necessarily) and #3 would seem like a good approach. Storing the data locally in the browser (#1) makes it immediately accessible. Backing that up with session-based server-side storage defends you from the page being refreshed; you can magically restore the page just as it was.