I am currently working on a mobile app..where I am fetching a response from a REST GET call.
Every thing is perfect. But , I want expert suggestion on how to re-render this data if user reloads the page.. or what is the best way to handle this scenario. Caching / storage won't help me here as this is sensitive data.
Need expert opinion please?
Maybe you should consider session storage. It will persist only as long as the current session is active (until tab or window is closed), and you can certainly think of additional security strategies, such as encryption and expiration.
Build an AngularJS service for your data source which will first query the session storage as a cache, before bothering your servers. I'd recommend creating a service that wraps session storage itself - maybe call it a ThingCache - that would be injected into the main data service.
Related
My idea is to reduce the number of requests to the server from the web client. Say, a view/component that shows user data (first retrieved before this view/component is rendered), if the user reloads the page (F5) then the whole application is reloaded and initialized again, so another request to the server to get that data again, is there any way to maintain or "caching" that state locally?.
I don't know how to implement this.
you can try redux presist link : https://github.com/rt2zz/redux-persist
or you can use localstorage : https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
Like others have said, local storage is probably your best bet, but I don't think it's a very good idea. If the users reloads the page, that's essentially a blank slate for your app. You could get the data from local storage but how do you know it's still up to date? You'd need to check with the server anyway.
You should definitely look into a redux/store solution where you can store data for use while the user is using your app, so you can share data between components and don't have to fetch the same data every time. But actually storing it locally just reeks of bad practice, IMO.
So I'm working on a react application as a front and as the back python, Django and rest.
I'll do the front part in a few days, but a question spawn: how can I manage all my apps for the user with an account and the other (without the account)?
I look a few options but I don't really know which one is better:
local storage
context API
cookies
For example if the user is connected and wants to see him own profile page, he could without fetch in the code cause it's just a few information like name, email, ...
I don't know if it's enough to clear but hopefully enough to get some suggestions.
Cookies are mainly for reading server-side, whereas local storage can only be read by the client-side.
An other point is saving data, a big technical difference is the size of data you can store, localStorage give you more space.
Context API you'll use it eather you work with cookies or localStorage
You can call the API for fetching information the first time the user logs in, and then you could store the information on the app state for the whole session. If you want to store information between sessions localstorage works just fine, is easy to access. However, you'll have to check if this information exists when the user logs in.
Context API can help you to access the stored data easily by using useContext react hook API in other child components and manage them by React, but localStorage is a way to persists Context API changes with localStorage to get them back after every page reloads(prevent losing data in page refresh). But cookies have a maximum length(I don't know how much is it) which isn't the best way because it has security issues and a use-case of cookies is using them on the server-side by the backend.
After logging into an app (React.js), I am caching the member data in localStorage as a lot of my components are using it and request only needs to be done upon log-in, ideally.
However, a few properties in this member object may be changed in the backend manually so the frontend doesn't have a way to know whether the member object has changed at all. (Again, ideally, any change to the member object should go through some form submission that directly changes the DB, with which an update can be triggered for the localStorage, but this is not an option at this time.)
Example scenario: There's a generic form in the app to request for additional credits. Customer service will receive an email regarding the request. Credits would be manually updated for Customer A (in DB). If Customer A doesn't re-login (where the get request for member is done), localStorage will still show the old no. of credits.
If this is the situation, what's the best way to go about it?
Don't store member data in localStorage at all so as to keep the data fresh. Just call the endpoint whenever it's needed.
Use sessionStorage instead?
Trigger a refetch when the user refreshes the page / app (although user may not know that they need to do this to update the data).
Suggestions?
Calling the endpoint whenever its needed is ideal if the data is going to change based on things outside of the user's control.
Session Storage is just local storage that gets wiped when the browsing session ends, you'll still have the exact same issue
This doesn't really solve the problem, and it's typically a bad user experience to require the user to perform regular maintenance tasks in order to use your application to the best of its ability
I'd go with just getting the data fresh.
At a high level, you have two choices:
Poll (periodically call the back end to refresh the data)
Open a persistent connection (like a web socket) to the server, and have the server push updates to clients.
The latter option would require a lot of changes, and it changes the scalability of your app, so the former choice seems like the most reasonable option for you.
It's smart to keep using localStorage so you have an offline copy of the data and aren't blocking rendering during page load; you can have a background periodic refresh process that doesn't disrupt the user in the meantime. If your data is mirrored in something like redux or context, then your UI could seemlessly update if/when the data changes.
If you do not know when member has been updated, don't store it. You should query the back end every time you need member. That is the only way to keep the data sync with your database.
I am developing a website and i am having a problem in finding the best solution to maintain user login session.
Currently i am using Html5 web storage "session storage" to store whether user is logged in or not. But problem in this is that this only works in a single tab not across multiple tabs of a browser.
What should i use either Cookies or LocalStorage or i should maintain server side session and check every times a page loads on server whether the user is logged in or not ?
What is the best solution? please guide me.
I am using Node.js and mongodb in the backend and Angular and jquery in frontend.
First thing you must know is that sessions are made only for server-side not for client side. Second thing, if you want your user to not load everytime, try to save the data in user's cookies also don't think about it will require more time to load on server. Because sessions are only made for security purpose and i guess by storing them on client side you are not using that purpose. Also now major question is how to store them on the server side. Suppose your server goes down now all of your sessions will get deleted. Now to avoid that use some external data store like connect-mongo/connect-redis. redis is faster than mongo but if you want to use only memory store then search for memcached/cookie-sessions/jWT hope this answer helps :)
I'm not getting the concept web api and session.
I've created asp.net web api project and integrated angularjs in it.Every time I'm gonna call web api.
I have read the articles which state its not good to use session in Web api. I do understand that web api is stateless approach. I do agree. stil there is a way to use session.
First question: If, after login, i want to show user name on every page what should i do with web api approach????
second question: they say don't use session in webapi. then what is the other way/approach to store client information safely.
If I use HTML5 local storage, it can be editable.
If cookie is used, it can be deleted.
What and how should I do it for user till application is in running mode?
This is where semantics often clouds the discussion. People confuse the Session object with statelessness. And often say: 'don't use session because it isn't stateless!'.
However they really mean that you should strive to have your the restful calls to be idempotent, meaning they don't change their behavior depending on whatever it is you do in the background.
Session, or the runtime-cache, or whatever it is you use to cache data, has no effect on your stateless design, because really, what's next? Your database is statefull too? And you shouldn't read data from that? Nonsense obviously; your underlying storage, if it's in-memory or on disk has no reflection on your state to the client.
Although I feel #MajoB makes other valid points about not using the session object, there is really no harm using some kind of cache in the web api, session or something else. But never let the fact if something is IN session return a different result then when something is OUT of session.
I would recommend you to avoid asp.session because it may cause performance issues and can expire anytime regardless of your application state, does not scale on cloud, it will block concurrent ajax requests). Better approach would be to use HTML 5 storage mechanism especially in conjunction with AngularJs (you can use ng-storage https://github.com/gsklee/ngStorage).
I would recommend you use asp.net identity and render user information on server.