search

stevenleeg / geemusic

A bridge between Google Music and Amazon's Alexa
GNU General Public License v3.0
664 stars 181 forks source link

Queues (and other stateful information) should be managed in a DB/kv store, not in memory #260

Open mikeage opened 5 years ago

mikeage commented 5 years ago

Currently, the queues and other information about state is kept in RAM, but this means that a restart of the service loses all of the information. It also means it can't be scaled behind an LB (probably not relevant for a single user), and to be honest, I'm not quite sure how this can work in a lambda, where there's no persistence.

Ideally, I would think that something like redis would be a better place to store persistent data.

fergyfresh commented 5 years ago

In order for the Queues to work in Lambda we will need to not have them in memory. I really only use Play some music intent.

fergyfresh commented 5 years ago

But yeah. the LB thing isn't something we should design around because this hack shouldn't be distributed to the scale that would require a LB tbh.

mikeage commented 5 years ago

Fair enough, and AWS ELBs, ALBs, and NLBs are not cheap, at least compared to a lightly used lambda or EC2. But even without the LB issue, lambdas don't keep their memory for too long...

fergyfresh commented 5 years ago

They keep it for long enough to run through the 25 songs in the i'm feeling lucky playlist, or atleast that's been my experience thus far. XD