Closed Serif773 closed 2 years ago
@Serif773 Redis is optional, but not recommended for production. User will not be logged out as and when the server restarts as sessions are stored in memory till that.
There are 2 tokens
For now, there is no way to configure expiry time for jwt, soon there will env for that. It is in our roadmap already.
@Serif773 Redis is optional, but not recommended for production. User will not be logged out as and when the server restarts as sessions are stored in memory till that.
There are 2 tokens
- The refresh token expires in 90 days (though rotated with each token request, so that there are fewer chances of the token being exposed). Also refresh token is validated with fingerprint
- Access token expires in 15 min (silent refresh is done in FE library to get new access token)
For now, there is no way to configure expiry time for jwt, soon there will env for that. It is in our roadmap already.
Since jwt expires so quickly, if there are a bulk of users, there could be a lot of users requesting new access tokens. With respect to heroku(512mb ram, 1vCPU), how many GET/POST requests would it be able to handle in a second? It would help me to know how many users I'd be able to support with the free tier limits
@Serif773 I haven't done benchmarking / stress testing for heroku,
But we can do it using https://github.com/tsenart/vegeta
Also, there are benchmarks available for the Go Gin server which we are using (https://github.com/gin-gonic/gin#benchmarks) Though numbers will change on heroku
@Serif773 are we good to close this issue?
@Serif773 are we good to close this issue?
Yes
If I use heroku, and don't use Redis, would users be logged out after 27 hours?(average heroku restart time is 27hours). In short, is Redis optional? And if I don't use redis on heroku would I users be logged out?
Also, additionally, how do I increase the expiry time of jwt token? I see one reference to
expires_at: Int64
. Do I need to change something over here?