This really seems to muddy the distinction between the data layer and the application layer. I'm sure they've put a lot of thought into this, but it seems like there could be some bizarre edge cases.
Deno Cron
71–80 of 190 posts
Re: Deno Cron
#72I am a lead on a small startup team and one of the biggest pain points is dealing with infrastructure. We have no dedicated devops person and much of that work falls on me and other people who would be better writing code. I think the cloud paradigm is experiencing a shift. Few of us want to deal with cloud infrastructure (whether clicking around or via Terraform or equivalent) to execute a function every X minutes -…
Or you could just use an actual host running actual cron. No clicking, no terraform, just crontab -e. The last thing small short-staffed startups with no infra people should be doing is messing around setting up cloud infra to run something on a schedule.
Okay, but who's taking care of the actual host? I know this is HN and we're all server admin wizards, but there is some effort and maintenance required.
This is theoretically even easier than that. Yay for a spectrum of options!
Re: Deno Cron
#73Earlier quoted context omitted.
> 1. Services like this cron with Dyno Deploy or Vercel where the cloud things are abstracted away for you. I agree with the sentiment, but to me it’s a shame this even qualifies as abstraction in the first place. Periodic execution of a function is extremely basic and already exists in almost every programming environment. If this needs to be a service (instead of a library call), there is something deeply wrong els…
> Periodic execution of a function is extremely basic and already exists in almost every programming environment. Periodic execution is surprisingly complicated. What happens when your node is down when it was supposed to execute and then comes back up? What happens around timezone changes and leap years? What does this thing do if a run takes so long that the previous run is still going? How do you get logs/notifica…
> What happens when your node is down when it was supposed to execute and then comes back up?
If you want at-least-once scheduling you’d probably use a library that writes a last-completed time to your db.
> What happens around timezone changes and leap years?
For wall-time scheduling you’d need to handle it, yes. Why would a service be better than a library though?
> What does this thing do if a run takes so long that the previous run is still going?
I think we’d need either another db entry or simply prevent overlap directly in the library.
> How do you get logs/notifications if it fails?
Same way as other things in your app that fails I guess. Perhaps logging a critical event?
If you’re talking about external health monitoring then yes, you’d need to have a separate service by definition, preferably with a completely different provider/host.
Re: Deno Cron
#74Earlier quoted context omitted.
> 1. Services like this cron with Dyno Deploy or Vercel where the cloud things are abstracted away for you. I agree with the sentiment, but to me it’s a shame this even qualifies as abstraction in the first place. Periodic execution of a function is extremely basic and already exists in almost every programming environment. If this needs to be a service (instead of a library call), there is something deeply wrong els…
I wonder why more people don't just set up a cheap VM and run this sort of thing via crontab.
The same reason why most people stopped manually editing some random files via FTP to do deployments: to get a proper reproducible, automated and monitored production environment.
Re: Deno Cron
#75hey, andy from the deno team here. we're really excited to land this. happy to answer any questions or pass questions along to the team!
Why on earth would you copy Cron's incomprehensible syntax? You're writing code in a statically typed language! You can make a nice type checked API that actually is understandable without having to use one of the many many crontab generator UIs.
Crazy API design!
Edit: seems like there is a WIP typed API but I still have no idea why you would lead with the terrible one...
Re: Deno Cron
#76Earlier quoted context omitted.
We need decently designed environments where running stuff is trivial. It's not practical to expect the same person to be able to deal with both all the bullshit that comes from making the spaghetti and all the bullshit that comes from making it adhere to the wall.
It is practical, a lot of us do it. Besides, the amount of bullshit it takes to make the spaghetti stick to the wall is dictated by how it was made. Make nice spaghetti and it sticks to the wall effortlessly. Make bad spaghetti and it takes 4 people and a dozen rolls of duct tape to get it up there.
> the amount of bullshit it takes to make the spaghetti stick to the wall is dictated by how it was made
I really don't know where the bullshit coming from. Often it looks like every single person is fighting for their lives against it, and yet it keeps growing.
But it's mostly dictated by overarching decisions that constrain both how it runs and how it's made (AKA, outside somewhere). Of course, there exist people on both sides that create problems all by themselves, but those are always easy to solve.
Re: Deno Cron
#77Not using something more intuitive than cron's schedule format seems like a missed opportunity.
Re: Deno Cron
#78I am a lead on a small startup team and one of the biggest pain points is dealing with infrastructure. We have no dedicated devops person and much of that work falls on me and other people who would be better writing code. I think the cloud paradigm is experiencing a shift. Few of us want to deal with cloud infrastructure (whether clicking around or via Terraform or equivalent) to execute a function every X minutes -…
Or you could just use an actual host running actual cron. No clicking, no terraform, just crontab -e. The last thing small short-staffed startups with no infra people should be doing is messing around setting up cloud infra to run something on a schedule.
It's not an option if you have more than one machine and you want the machines to be uniform. If they are not uniform means it's back to square one - bespoke setups. And then I want reproducibility across environments and environments that are easy to set up (for testing for example). Basically I think it's not an option.
Re: Deno Cron
#79Earlier quoted context omitted.
Or you could just use an actual host running actual cron. No clicking, no terraform, just crontab -e. The last thing small short-staffed startups with no infra people should be doing is messing around setting up cloud infra to run something on a schedule.
It's not an option if you have more than one machine and you want the machines to be uniform. If they are not uniform means it's back to square one - bespoke setups. And then I want reproducibility across environments and environments that are easy to set up (for testing for example). Basically I think it's not an option.
Why does a small startup need several machines though?
Re: Deno Cron
#80Earlier quoted context omitted.
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.
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.
Or even a crontab! You know, the thing that this is named after.