I have a node js application which displays graphs based on the selected parameters, these parameters can vary based on a users interest. I would like to collect information about a users activity , so that the next time the same user uses the application, it should display relevant feeds based on the graphs visualised before.
Can I do this without having to register a user in the db? How will the application remember every unique user? Can we do this via cookies?
If you do not want to store user information server side, you could try cookies or browser storages like LocalStorage and then requests that attached with parameters can be recognized what the user's preferences are.
Related
Disclaimer: I'm finding my way and not sure how to ask the question. This is what I want to do:
I am getting data from twitter API in my app (this is working).
I then want to store that data (as an array), and serve it to whichever user is accessing the app (so that I don't need to query the API everytime, just poll every 10 mins).
What do I need to be able to do this? (external database? or can I just save to a file on the server in someway? or something else)
For ref I'm building with sveltekit, and deploying with vercel.
If you are using Twitter's API directly within your own app, every user of your app needs to query the API at least once to get some data. You cannot serve the results that are returned to one user to other users without having your own back-end server and handling this accordingly. However, you can save a copy of the data returned to each user to that user's localStorage so that specific user does not have to query the API every time.
You can save the data on the client's localStorage and save an expiry timestamp that allows you to query the API again after the timestamp has passed.
Here is a tutorial on how to use localStorage with SvelteKit
I am creating a web application, and need to store some user data (like their favorites history in the app). I had considered using IndexedDB for this purpose, as it would be a little easier to implement than on the server side where I am using MySQL. But, I do want to run analytics against this user data, such as to ask what are the most popular pieces of content that users are saving to their favorites list. If I use IndexedDB, I could use some Javascript on the client side to occasionally forward user data from each IndexedDB store so that it could be analyzed. My question is: would this be scalable for > 25,000 users? Or, am I just asking for trouble with this kind of an approach, in which case I should just store all the user data in MySQL on the server side to make analytics easier?
Those are two different concepts as i understand your question.
indexDB is store locally on the user browser and it's subject to local user behaviors - clean cach , cookies refresh and browser options that are enable.
You should use the indexDB if your site/app load some data to the user browser - like a table/graphdata/friendlist etc. and you want to allow quick navigation with no server calls for some queries sending back to the server.
with this in mind you can store different user sessions and build a small key/value data base and send this when you want to you Server MySQL DB and save this on your side and allow you user to navigate this data or to use the JS API in order to load the right content for your user.
MySQL DB on your server side can do the same but you got some more latency parameters in here - user location vs Server Location , DNS ,network latency , server CPU , Disk , Table structure and Table size that can slow you down.
You should decide what you need in order to learn more on your users on the server side and which data your users need for quick and easy use with your APP . Those 2 data flows are not tied up and you can run them with no code blocking using asynchronies JS commands.
Regarding the scale Issue , IndexDB is good for 1-2MB of data and you should think on a cleansing process or counting main features on the App if you will have 1 key of favorite site . then you just need to add +1 for this key value - sitename_favorite - 5
this data is per user only and the load will be on your MySql server that will get updates from time to time for the users. the IndexDB will be managed by the local machines of the users so 25K users is not relevant for the indexDB part, the load will be on the MySQL server once users updates arrive.
I have been developing a SPA with AngularJS and I have stored the user data in an Angular Value service but I do not feel confortable with that, basically because the Angular Value is not shared between browser tabs. So if the user opens a new browser tab and on every page refresh (F5) I have to request the server the user data like full name, email, etc. I am using a REST API.
Is this approach fine or not?. If I use localStorage it will help me to share data between tabs but I do not know if it is a better technique.
There are only 3 places you could store your data in a browser
Cookie
Local storage
Database (IndexedDB or Web SQL)
You can open your console panel to see these option.
Consideration:
Security
It depends on how important or sensitive your data stored in the
browser, if it is user sensitive, you should never stored them in the browser in the 1st place!
Size
how big is the data, you going to store? if it is huge it is good to store them in the Database, you could check out some of this framework (PouchDB)
if it is small, you could just store them in the local storage
I'm pretty new to web development and have for most of you trivial question.Where and how to store website progress user did? I mean...for example.We have javascript variable
var a=0;
and
<div id="clickhere" onClick="a=a+1;document.getElementById('clickhere').innerHTML=a">
.Imagine someone clicked on that division once and leaves website.I want him to see displayed number one in that div after returning to website.
You either need a server side to store this data, identify the client by some uid or login and retrive the data on repeated visit. or a simpler solution, use a client side cookie.
If you only want visit data viewable to each individual user, you can use a local storage mechanism. For clients whose browsers support HTML 5 you can use localstorage to store a retrieve the variable between user visits. You could get he JavaScript to set a cookie and then check if a cookie exists per user visit, if it does, increment the visit count.
A more robust solution would be to persist the visit count server side. You can issue a cookie to a user, on each future visit, you can either send the visit data to the server via Ajax, or by form submit. This would then need to be persisted to a database using a server side language such as php, ruby or .net.
I am working on a commission calculator and would like to know how I take sales the users would input and save them to return MTD/YTD commission amounts?
I am currently working on learning the html/javascript for the input form, but now I am wondering how I can link the sales data to a nice calendar.
You have two main directions to go:
You can save sales data to a central server so that the user can login and view their info from any computer and so that it is securely saved.
You can save sales data on the local computer in Local Storage (modern browsers only). Local Storage is generally persistent, but not guaranteed to last forever and it is ONLY on that particular local computer.
If this is an important business application, I would generally think you would save the data to a central server in which case you would need a server and a server-side language (perhaps PHP) and database (perhaps mySQL) that you could receive the form data and store securely with a server-side web application. You would probably also need to create a login system so that users got access only to their own data.