I am building a web app, where there is a lot of user specific data. Prior to HTML5, I would have just saved all this data in a database on the server.
Eg: Username, List of books read.
With HTML5 Local storage, I imagine I could just store it on the client. The problem is, what if there are multiple users using the same client (computer & web browser).
Is there a way to separate the user data for each user in local storage ? Is this not what HTML5 Local Storage was intended for ?
In most cases you should clear the localStorage for each user for privacy reasons.
However, if the data is generic, non-identifiable data, something simple like a high score from a game, then yes a object based storage might be ok.
If the data is anything specific, or identifiable, deleting the localStorage after a timeout, logout, or login is preferred.
Clear the localStorage:
localStorage.clear();
and start fresh after one of the above events.
Otherwise a web-savvy person could view the browser's localStorage content and each user's data.
Store an array of 'users' object. Html 5 Local Storage is quite flexible. You can then search for the object using an id for example.
Related
I have a system that uses CouchDB as DB, and the clients connect through PouchDB, having a local copy of the database for offline use. The app has no backend API, it connects directly to the DB.
Many databases on the system contain one or more fields that should be unique (no other documents should have the same value). Since CouchDB doesn't really have a "unique costraint" for fields, the uniqueness of the documents is managed through code on the client side. The issue comes from the offline synchronization from PouchDB.
Let's say there is a pages object in the system that has two fields that should be unique, name and slug. Through code we make sure that before posting a new page, those two fields do not exist in the DB. Then let's say one PC goes offline for a day, and creates a page with the slug "homepage", while the same day, a PC that was online created another page with the slug "homepage" now saved on the remote DB. When PC 1 goes online, it will sync the local and remote DBs skipping the validation code and adding a second "homepage" page.
One workaroung to this is to set the must-be-unique field as the _id of the document and manage syncing conflicts, but that is not possible in a reasonable way for more than one unique element. (I would still appreciate a response that only takes into account a single unique field tho).
Also in some cases it is less than ideal to use the _id as the unique field. For example, in a POS system, cashiers have a pin to check in with when taking an order. Using a 4 number pin as _id does not seem ideal.
Another option is to ask an action from the user before syncing when noticing a conflict. But that would require a pre-syncing phase that checks the whole database, and interrupts the user. I'm not sure how to implement it in a seamless way in the system regarding user experience tho.
Any suggestions on how to handle this massive issue?
I understand the textbook definition/concept of localstorage and sessionstorage. I really should write, "I believe I do". My 2 questions are as follows:
Can you provide a clear example of when one (localstorage/session storage) should be used over the other? Basically, what data should
be stored in the localstorage and what data would be stored in the
sessionstorage? I have read a list of country codes could go into the local storage, I ponder if this is really right. What would happen if the country list changes, wouldn't the old list always display and how would one refresh the list upon a change?
What happens when the localstorage and/or sessionstorage hits
the max mb for the browser?
1) The data you store either with LocalStorage or SessionStorage depends on how you want your user to experience your application.
For example, if you have a login page, the username should be something kept with LocalStorage, because probably this same user will log into your app multiple times and not necesseraly wants to save the password in the browser. Having the username in LocalStorage will make it easier for the user to login in the future, even after closing the browser or changing tabs.
But, if you have a system that provides services like booking, searching or maybe comparison between products, storing data with SessionStorage would be better, because although the values set by the user while using your application won't change during this session, they might - and probably will - change in a future use of your application.
In your case specifically, and repeating what was said in the beginning, even with changes in your list of countries, you need to have in mind how your user will interact with your system and what are your needs with the data that is being provided by them.
Don't forget you can always clean the localStorage if you need, and set new values as they appear.
2) There's a really good explanation of how the browser responds to a full memory here
I'm looking to implement notifications within my node.js application. I currently use mysql for relational data (users, submissions, comments, etc). I use mongodb for page views only.
To build a notification system, does it make more sense (from a performance standpoint) to use mongodb vs MySQL?
Also, what's the convention for showing new notifications to users? At first, I was thinking that I'd have a notification icon, and they click on it and it does an ajax call to look for all new notifications from the user, but I want to show the user that the icon is actually worth clicking (either with some different color or a bubble with the number of new notifications like Google Plus does).
I could do it when the user logs it, but that would mean the user would only see new notifications when they logged out and back in (because it'd be saved in their session). Should I poll for updates? I'm not sure if that's the recommended method as it seems like overkill to show a single digit (or more depending on the num of notifications).
If you're using node then you can 'push' notifications to a connected user via websockets. The linked document is an example of one well known websocket engine that has good performance and good documentation. That way your application can send notifications to any user, or sets of users, or everyone based on simple queries that you setup.
Data storage is a different question. Generally mysql does have poor perfomance in cases of high scalability, and mongo does generally have a quicker read query response, but it depends on what data structure you wish to use. If your data is in a simple key-value structure with no real need for relational data, then perhaps using a memory store such as Redis would be the most suitable.
This answer has more information on your question too if you want to follow up and investigate more.
I want to make an HTML5 app that can be used offline that accesses a database of words. However, I don't know the proper way to store this data initially. For example, if I wanted to create a spell checker that compared words typed with a dictionary database (thousands of words), how would I store the database of words? This is just an example of what I might want to do, the underlying question is how to create such a database to begin with that can be accessed offline.
Consider using the webstorage API which holds up to 5 MB. Use local storage if you want data to persist across browser tabs and sessions or session storage for session scope. You may also want to consider client-side database storage.
What is the difference between these concepts, and when should I use one in particular? Does this listing also contain different names for the same general concept?
HTML5 local storage
HTML5 session storage
HTML5 web storage
HTML5 web database
Cookies
HTML5 web storage is a generic umbrella term for the new client-side data storage options.
Local Storage is persistent and scoped to the domain. At the moment two flavors are usually mentioned:
'default': stores things in name/value pairs
Web SQL (aka Web Database): uses an SQL database
Session Storage is non persistent and scoped only to the current window.
Cookies are the old school way of doing all of the above. Stores name/value pairs per domain.
I would like to add more information:
cookies are able to store only 4k of data
whereas localStorage is able to store 5mb of data (Depending on browsers)
Websites will save cookies in browsers and next time browser will send that cookie along with http request to be used server-side. Cookies are meant for being used with the server.
With localStorage, you can store more data, but it is restricted to the client by default.
Session Storage:Session storage is introduced where the user is carrying out a single transaction, but could be carrying out multiple transactions in different windows at the same time.Session is terminated once we close the window.
Local Storage:Local storage is specific to domain and is introduced to span across multiple windows.There is no time limit as in the case of Cookies,and can store upto 5MB storage such as Users MailBox etc....
AFAIC:
Cookies are 4k per cookie, and local storage is 5k per domain.
Cookies existance time limits and sorage is just client-side protocol- and domain-specific bin for data.
Another big thing to consider if your users are located in Europe, is that Cookies are illegal in Europe. https://www.sitepoint.com/europe-website-cookie-privacy-law/