Short-lived Tokens in Ets-backed Resource
I was wondering if it makes sense to store short-lived tokens in an ets-backed resource. The tokens are created -> read -> deleted in usually < 2 minutes and they should have ttl of 5 minutes. I could just do everything in postgres but perhaps it makes sense to do it in a cache in memory. Initially I thought of using ets and use it directly through changes/preparations (with the set_result thing) or just use a normal phoeinx controller and deal with those endpoints myself. Then I remembered about the ETS data layer but the notice of not recommended in production kinda scared me.
So I have like these 4 directions to take (ets-backed resource, phoenix controller using ets, ets via changes/preparations on a postgres-backed resource, just postgres) and not sure which I should do. So just seeking some advice 😅
4 Replies
Will there be many of these tokens? The main issue of the recommendation not to use it in prod is just that it's not optimized for a lot of data
You could also make a resource with manual create actions and store it in ETS yourself
It's basically the anti-forgery state token in the open ID connect flow, so yeah there might be cases where a lot of token are generated if many users have to authenticate at once in an hypothetical world where users sign in my app 😂
So, if the scale is hypothetical etc I'd just use PG
Otherwise I'd probably use a couple manual/custom actions
Yeah you're right, better keep it simple. Thanks!