3 ms·
Thanks for this well detailed feedback. 1) Yes, it's on our roadmap. 2) It was/is a design choice, we aren't so familiar with using redis as a persistence sto
by subomi 5y ago
Thanks for this well detailed feedback.
1) Yes, it's on our roadmap.
2) It was/is a design choice, we aren't so familiar with using redis as a persistence store. The goal was to enabled people switch backends depending on what they're comfortable with.
3) Thanks for bringing this up, there are a ton of things we should document.
4) We're working on improving things from a security perspective.
On application-wide keys, we're considering making this configurable, so you can choose what works best for you, we only started with app-wide keys, next is endpoint-keys. :)
On public/private keypair, this is new to me as well! we haven't found anyone doing this in prod. But yes, I can see how this can be useful in specific environments, definitely something we'd like to support.
- nicoburns 5y agoWe’re not currently providing we hooks, but I can see a using something like this if we need to at some point. I’d definitely appreciate a Postgres options for the queue backend. We currently have an “everything in Postgres” approach for operational simplicity. It works great, and it would fantastic if we could slot this in there too.
- subomi 5y agoHmm. To clarify, do you mean Postgres as a queueing backend or storage backend? We have it planned for a storage backend but not for queueing at the moment.
- nicoburns 5y agoBoth! For context, we're currently using https://github.com/timgit/pg-boss https://github.com/timgit/pg-boss as a task queue on top of postgres and it works great. No need to complicate things with Redis. I believe it's quite straightforward to implement a task queue on top of postgres using the SKIP LOCKED functionality.
- subomi 5y agoNice! Thanks for the context, super helpful. Yes, I am putting this on the roadmap! :)