You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[docs] Example integration with external persistance layer #48
There's a need to track, discuss, and document best approaches around adding jobs persistence layer on top of bree. This issue is a focused continuation of this comment:
An example in the README for using sockets, or redis pubsub to communicate with Bree to add new jobs (?)
I would recommend keeping dynamic jobs actually stored in a queue, with a persistent database, and then have a job that runs every so often to flush the queue (with limited concurrency).
References
How job persistence is approached in other job processing/queuing libraries:
forwardemail.net - here jobs are generated based on state of records in the database
TBD: expand this list with more examples for future reference
Expected outcome
What I think would be the ideal outcome for this issue is documentation an example implementation of persisted jobs queue on top of bree. Ideally the example would be backend agnostic so that multiple storage approaches - NoSQL, SQL or key/value stores like Redis, could utilize it.
Maybe bree could even provide an adapter/plugin system to optionally add persistence for (1) scheduled one-off jobs and (2) failed jobs 🤔
Reacted by gilbertkaradja, Martin Eboh, Josh Lyon, Pepijn Verburg, Agung, Lukas, shivam-marwaha167, Mads Hargreave, Bruce C, Abe Suni M. Caymo and 9 more
What I think would be the ideal outcome for this issue is documentation an example implementation of persisted jobs queue on top of bree. Ideally the example would be backend agnostic so that multiple storage approaches - NoSQL, SQL or key/value stores like Redis, could utilize it.
Maybe bree could even provide an adapter/plugin system to optionally add persistence for (1) scheduled one-off jobs and (2) failed jobs 🤔
How about using an abstraction layer like TypeORM (good support for SQL databases + MongoDB. Doesn't support Redis tho). You write job model/schema once and then it gets migrated into a database of user's choice by TypeORM.
Activity
Zireael commentedon Jan 23, 2021
How about using an abstraction layer like TypeORM (good support for SQL databases + MongoDB. Doesn't support Redis tho). You write job model/schema once and then it gets migrated into a database of user's choice by TypeORM.
dturton commentedon Nov 30, 2021
Prisma can be another great option to TypeORM.