31 ms·

Where better to put cron work? In another repo? If the cron jobs are 100% unrelated to the codebase, yeah, it might be weird. If the jobs are "run the foo()

Where better to put cron work? In another repo? If the cron jobs are 100% unrelated to the codebase, yeah, it might be weird. If the jobs are "run the foo() method every 2am"... having that info colocated with the foo() method itself makes a lot of sense, imo.

nightpool 3y ago
Just a normal yaml file...? Why go through the complexity of putting it in another codebase when you can just make a single config file? There are probably some benefits of using the Deno.cron syntax for some functions, and benefits of using a config file for others, but acting like the only other option is "put it in a completely seperate codebase" doesn't make any sense to me.
- rafram 3y ago
  Or even a crontab! You know, the thing that this is named after.
  - nightpool 3y ago
    I think there are sensible reasons people don't like using unlabeled, whitespace-delimited formats that require an ascii-art diagram to explain in the modern day.
    - rafram 3y ago
      I mean this is just that same format but wrapped in a JavaScript method call, so I don’t see a huge difference.
everforward 3y ago
To me, it would depend on whether you always wanted to deploy the cronjobs with the codebase. I think I usually want the option to deploy them separately. Just as an example, if you have 8 nodes or whatever, your cronjob is going to get updated when the first one is deployed, not the last. The other nodes may or may not support that cronjob until they get the update. Going the other direction, if you have to roll back a single node for whatever reason, now you have conflicting cronjob versions. I typically want those rollouts to be separate so that I can handle failures in the app deployment before I update the cronjob.
codedokode 3y ago
You can put ordinary crontab into your repo.
- jacobyoder 3y ago
  That too - but keeping the items that deal with the code with the code seems simplest for most use cases.

nightpool 3y ago

Just a normal yaml file...? Why go through the complexity of putting it in another codebase when you can just make a single config file? There are probably some benefits of using the Deno.cron syntax for some functions, and benefits of using a config file for others, but acting like the only other option is "put it in a completely seperate codebase" doesn't make any sense to me.

rafram 3y ago
Or even a crontab! You know, the thing that this is named after.
- nightpool 3y ago
  I think there are sensible reasons people don't like using unlabeled, whitespace-delimited formats that require an ascii-art diagram to explain in the modern day.
  - rafram 3y ago
    I mean this is just that same format but wrapped in a JavaScript method call, so I don’t see a huge difference.

everforward 3y ago

To me, it would depend on whether you always wanted to deploy the cronjobs with the codebase. I think I usually want the option to deploy them separately. Just as an example, if you have 8 nodes or whatever, your cronjob is going to get updated when the first one is deployed, not the last. The other nodes may or may not support that cronjob until they get the update. Going the other direction, if you have to roll back a single node for whatever reason, now you have conflicting cronjob versions. I typically want those rollouts to be separate so that I can handle failures in the app deployment before I update the cronjob.

codedokode 3y ago

You can put ordinary crontab into your repo.

jacobyoder 3y ago
That too - but keeping the items that deal with the code with the code seems simplest for most use cases.