I think about cache the response of Auth::user(). I started with redis and and ask myself, if I could cache the user data. I read that Auth::user() is a singleton. That is good, because database is hit only one time. But I'm not sure if that is a security risk. And what can be the cache key? I have a vue app which use passport... (user:sessionid). Should i maybe use the token to generate a key in store user:access_token? Does anybody had this problem or maybe say that is a stupid idea?
But I'm not sure if that is a security risk
What is a security risk about a singleton exactly?
The authenticated user is resolved from the Request one time; and is kept in-memory for the duration of that Request. There is no need for you to separately cache that User instance in Redis or anywhere.
If the user reloads the page, I want to avoid load user data from mysql db every time. Or when a lot of users login at the same time. So i think about store the user with id, username, email and avatar image into redis. Sorry, that with security risk... I mean is it a security risk to save it in redis? I only mean that i know it is a singleton, but it will still be called one time a user loads the page.
@Pixelairport this users query probably is the very least of your worries in the context of an application - I believe you may be prematurely optimising for a problem that doesn't really exist! If you must... you would need to implement Illuminate\Contracts\Auth\UserProvider that would retrieve the User from cache first (deferring to the database if not found), and update the auth config to use your driver.
@tykus thx. Maybe you are right. You mean there is no problem when 5k-10k users login in a time between 10 seconds?
@Pixelairport that'll be a problem for the server rather than the application.
@tykus Thx. But I think mysql could also be a probelm. Sure ... also the server must be good and scalable, but dont you think mysql could also be a bottleneck? For this reason i use now redis, that i dont have to do so much mysql calls.
@Pixelairport are you actually experiencing this problem; or planning for this problem? I am not saying that the database might not be a problem; but in the context of this one query (which uses the primary key); it very likely is not! If the database is going to fall over because of this query; your app will be experiencing bigger issues elsewhere!
Ok. Thx @tykus ... Normally I build websites, shops or apps with normal registration. I mean the people register in a long period and the app slowly grows. This time I build an app, where i have peaks. And when I get a customer he brings a lot of users, which all will register in a few seconds. But maybe I have at first smaller customers who only bring 1k-3k users and then i will see how database and servers will run. I decided to get a architect for this, when i have first customers. But thx that you say there will be bigger issues. Then i will cache the other things and this special part will be done with mysql. I will change this later when i grow.
@pixelairport Solve problems you have. Not problems you think you’ll have.
Caching the authenticated user look-up is going to cause more problems than it will solve.
@martinbean I know... :) I dont have the problem, but this is really a special project, because it will not work with a few users and when it works for example with a radiostation, tv-station or streamer as a customer, they bring a lot of users at the same time. And when the radiostation says the people have to do on the website something in the next 10 seconds, i think there will be a lot of users. But i will start with smaller customers, to be sure dont have to much users at the start. So I can make some tests. Maybe i will do a closed beta with <1k to see how the people will use it and the server will work. And then slowly get bigger customers with more users. Thx @martinbean and @tykus
@Pixelairport This is the second or third question I’ve seen from you where you’ve asked something around pre-optimisation. Solve problems you actually have.
Stop trying to solve problems you think you’re going to have. If you try and predict the future, you will get it wrong. You’re inventing problems (“I need to cache the user look-up”) with absolutely no evidence that it’s actually a problem.
@martinbean thx. Maybe you're right and I'm just thinking it is a big problem to handle those amount of users and its not. Never had a big app like that and maybe im too scared... I will finish without caching that and let my first test customers in. Sorry for my question.
@Pixelairport better to have a server that can 10x the throughput than to worry about 1 simple query. Your application is going to face more complex bottlenecks if those users need to access the database for other reasons.
@Snapey yes... I think I understand now. I only want to setup everything right. But maybe it is already everything ok to start with. I will finish the last steps with what I have now and go live with smaller customers who don't have too much users. Thx to all who helped me... thx for your time.
Please or to participate in this conversation.