Oh great, thanks for your work.

One thing to mention: I've introduced the JobDbRepository to "abstract" away the datbaes layer,
in your implementation the database querys (.collection.updateMany()) are now implemented directly in the index.ts file, can you refactor it so that you just move the "updateMany" things into the JobDbRepository and call the method instead.
What's the idea behind: have adapter/database logic abstracted away from application/business logic. this helps to easier read and test code, but also gives the possibility to switch the database layer, without changing any application code/logic.

Thanks again for your contribution.

@simllll I love the idea that we could switch out db layer in the future.
But I think we can support many features like (watching for new jobs and even job defs) if we stick to mongo

@simllll I love the idea that we could switch out db layer in the future. But I think we can support many features like (watching for new jobs and even job defs) if we stick to mongo

Yep, my main concern is to keep "business" logic and adapter logic seperat, this helps maintating a cleaner code :) But it would be a possible "side effect" that allows swichting the layer too, but this is for sure another topic we can discuss in the future ;-)

Took a quick pass at abstracting things out. I like the idea of making it more DB agnostic, but I imagine the transition will be challenging, especially for something like this which is so interconnected with mongo syntax.

I'll try to take another pass at cleaning up the formatting in the next few days