SyncedCron or JobCollection

I was wondering what is the best solution for scheduled jobs
what do you suggest from your experience ?

1 Like

Depends on what your use case is.

SynchedCron will give you the ability to run functions at certain times based on some schedule you create. This is good for recurring things like wanting to fetch records from a third party on a schedule.

However, JobCollection goes a lot further towards a job processing architecture. Jobs are put into the queue as either recurring or single run jobs. It includes dependencies between jobs, automatic retry on failure, job cancellation, and the ability to throttle how many jobs of a single type can run at once.

I am working on a service which includes processing videos. When a new video comes in, I want to queue up jobs which generate thumbnails, encode the video in different sizes, and gather information about the video from the metadata. For my use case, JobCollection allowed me to do this well.

A great benefit of jobcollection is that you can create non-meteor workers. Which makes job collection an easy solution for almost any kind of background task, even if it needs to run outside of your meteor app.

thank you guys …
but i was wondering why do i have to use it from client side
all what i want to do is to assign some functions to run on the server to make updates based on dates
any advice ?

For your simple case, https://atmospherejs.com/percolate/synced-cron is probably the best. Doesn’t involve the client at all. Let’s you schedule jobs. They run, you sleep, all good. The jobs can query collections by date and update (or even delete) things that need updating.

Thanks a lot
but i am facing a strange behavior , so i was wondering do the Roles or the simple schema affect the synced-cron in a way ?
updating collections using synced-cron is functioning well only on some particular collections … any idea ?

Roles no but simple-schema enforces the schema on both the client and the server so if you’re updating a collection in synced-cron on the server those changes have to fit the schema. Check your server console to see what errors are being generated. You will also see each synced-cron job start in that console.

thats what i have just figured out …
i had in a way to validate the simple-schema to proceed on …
but this is really weird … it should not be like that
coz all what i wanna do is an insert operation for a small document
why then do i have to modify my whole simple schema for that purpose ?
am i mistaken ?

Does your insert not satisfy the schema requirement? You may need to make certain keys optional rather than required?

100% thats what i did to move forward … but again why ?
as i mentioned before, it is a small documents X to be inserted in collection Y … why the simple schema has to come in between ?

One of the features of SS is the enforcement of your schema rules on both client and server. That’s by design. It’s very helpful with regards to security since it makes it much harder to tamper with your data.