I have a huge list of products like 800-1000 may be more[dynamic].In the admin panel I want to show the list. Each time fetching the data takes time and admin has to wait. So if I want to save the data on first fetch and store it locally to reuse faster.
Which one would be better local storage or browser cache ?
Related
Every time someone hits an API route I want to store that information in database, connected with req. IP.
Afther I would like to find some association rules based on similar searches.
Should I store some information in cookies or to use local dartabase?
Example on some hotels site:
I want to store info that i got a lot of request for cheap hotels in some specific area.
Thnaks.
Definitely in a database. Cookies wouldn't make sense because
You cannot rely on cookies for persistent data. They can expire, be cleared, etc.
Cookies can hold a very limited amount of data (4093 bytes usually)
Cookies are stored locally on your client's browser, you want information across all of your clients.
Tracking user behavior data is very common web feature. You may want to use a web analytics service such as Google Analytics rather then implement your own.
I would have liked to know what the difference is between LocalStorage and SessionStorage. Also, in the context of authentication, what should be used? Because the user can view and change the content of SessionStorage and LocalStorage in the browser.
Session Storage is deleted as soon as the browser tab in question is closed. Local Storage exists until deleted or it hits its expiration (usually a very long time). Neither should be used for Authentication unless you don't have any private data being thrown around. If it's more of a pet product to keep track of someone being logged in, Local would be the better of the two.
https://www.quora.com/What-is-the-difference-between-sessionstorage-localstorage-and-Cookies
Cookies, session and local storage serve different purposes. Cookies are primarily for reading server-side, local/session storage can only be read by the client-side. In your app, who needs this data — the client or the server?
If it's your client (your JavaScript), then by all means switch. You're wasting bandwidth by sending all the data in each HTTP header.
If it's your server, local storage isn't so useful because you'd have to forward the data along somehow (with Ajax or hidden form fields or something). This might be okay if the server only needs a small subset of the total data for each request.
LocalStorage is an implementation of the Storage Interface. It stores data with no expiration date, and gets cleared only through JavaScript, or clearing the Browser Cache / Locally Stored Data - unlike cookie expiry.
I am creating a browser extension which retrieves data from a JSON feed.
I would like to store this data locally to prevent having to fetch the feed to often. The feed will eventually have over 100 results and the call is made on every new website that is visited, in the end I need an array with the results.
I am not sure at all on how to do this, but I guess (wild guess) that I have two options:
Option 1:
Store it all with chrome.storage.sync.set, will I be able to do this with such a large array?
And only refresh from feed every week.
or
Option 2:
Write my array to a local file containing the entire array.
And only refresh from feed every week.
Does anyone have any ideas on how to do this? Are both options actually possible? Which would be best?
You can use https://developer.chrome.com/extensions/storage to save your data. Usually the local storage is enough. Sync is used when you need to sync saved data across different user profile instances (when user logged in chrome with same account on desktop and notebook for example)
Also you can store data via file using filesystem api or webstorage api like IndexedDB or WebSQL - https://developer.chrome.com/apps/offline_apps.
I am finding myself placing all my data from my api calls in the device local storage and I am not sure if it matters whether I put things in local storage vs putting them in a service. When should I use local storage from device vs using a Angularjs service?
You are a bit mingled up with concepts. When it comes to angularjs services, they persist data as long as the page is not refreshed, as soon as you refresh your page or close the browser tab, The data's gone.
Consider Angularjs services as mere variables that you declare, which are scoped to the lifetime of your browser tab. Hence, you can use it to store some temporary flags and values that aren't meant to be carried forward to next session.
Whereas, When it comes to localStorage, consider it as a database kind of stuff. Whatever you store in localStorage, is saved inside the browser, and will be available across multiple tabs, and sessions of your apps [Until and unless user clears browser data].
Since you're using Ionic and Cordova, you must use localStorage to save stuff such as user name and password, so that the user can use them the next time he opens your app. Take a note that, closing your app is equivalent to closing a browser tab.
Whereas, if you have certain data that keeps refreshing each time user visits your app, you can use services to store them, so that they are removed as soon as the app's closed.
Metaphorically, localStorage --> Secondary, non-volatile Storage, angularjs services --> Primary, volatile storage.
Data stored in local storage is persistent. So, if you reload you web app the data in local storage is till there. Local storage is typically limited to 5MB. See this
Services are in memory constructs. So, if you place anything in service it is in the browser's memory and are lost when refreshing the browser.
So it depends on what you need.
You can use this localstorage plugin for your app. https://github.com/grevory/angular-local-storage
In a web application, we often come across a form submission process that spans across several pages, for ex: In first form we capture basic information, next page capture some other information and so on. I have a scenario where I've 7 screens to capture all the details about user and "Submit" button appears on 7th page.
Usually we store all the intermediate values in HttpSession and when its time to submit we retrieve all the values from Session and create an entry in database.
With this approach, by the time user completes all the form entries (i.e. from Page 1 to Page 7), everything resides in Session.
I would like to know, is there any alternative apart from HttpSession for storing the intermediate values?
I'm actually trying to find the ways to make my HttpSession less bulky.
You can also store just the reference in a session which then maps to a cache like e.g. Memcached. Or if it is important that you don't lose the data while the user walks through the steps, you can also persist the data in a database and just refer via a key from a session to it. To store too much data in the session is sometimes not the best choice, so I would just store a reference there.
You can try caching technology of .Net, this might be useful instead of using session for all the data, also you can just use the id of the session for the cache id.
Second option I think is configuring your Session-State mode to use SQLServer mode for the storage.