Live data from Hacker News

Deno Cron

deno.com

31–40 of 190 posts

Re: Deno Cron

#31
post #17

My first question when I am considering a product like this is how can I get an email when there's an error in my application. Why isn't that in the top level feature list of everything like this, or am I unusual in thinking that this is an essential feature of any hosting system?

I think the answer to that is the same as the answer to "how do I send an email in Deno?", since this lets you run arbitrary code.

System level cron needs that feature built in because you're just telling it a command to run, and you're limited in how you deal with error and output handling of that command. That's not a problem when you're in the language you're using to define the action. Just catch your errors, or grab all STDOUT/STDERR with some solution and do with it what you want on success or error.

Re: Deno Cron

#33
post #31
post #17

My first question when I am considering a product like this is how can I get an email when there's an error in my application. Why isn't that in the top level feature list of everything like this, or am I unusual in thinking that this is an essential feature of any hosting system?

I think the answer to that is the same as the answer to "how do I send an email in Deno?", since this lets you run arbitrary code. System level cron needs that feature built in because you're just telling it a command to run, and you're limited in how you deal with error and output handling of that command. That's not a problem when you're in the language you're using to define the action. Just catch your errors, or…

The downside is that when it has to be done on a job-by-job basis, you can’t rely on the cron system handling failure modes you didn’t anticipate.

Re: Deno Cron

#35
post #31

Earlier quoted context omitted.

I think the answer to that is the same as the answer to "how do I send an email in Deno?", since this lets you run arbitrary code. System level cron needs that feature built in because you're just telling it a command to run, and you're limited in how you deal with error and output handling of that command. That's not a problem when you're in the language you're using to define the action. Just catch your errors, or…

The downside is that when it has to be done on a job-by-job basis, you can’t rely on the cron system handling failure modes you didn’t anticipate.

It's code. There is not necessarily a single solution that makes sense. The thing you're calling could throw an exception, or it could return a failure value. If it fails, you may want to set off some extra routine that retries, or perhaps you want to handle some specific errors and retry or notify, but other errors are critical and cause failure, not just notification. Having it handle those automatically is not a feature in some cases, it's a problem.

System cron is simple, by design, because as a DSL there's a benefit to not complicating it. If you're already in Javascript/Typescript, a lot of the benefits of that are mitigated by the benefits of having much more control over exactly how it functions in every care.

As an example of this, there's a bunch of cron "helpers" to deal with the shortcomings of cron's simplistic approach, such as those in moreutils[1].

P.S. Personally I wouldn't have even called this implementation cron and use the cron syntax for it, since that just makes people assume cron usage and the cron scheduling format is not an asset if you're already in a language where you could just pass in a structure with the specific fields you want set by name.

1: https://rentes.github.io/unix/utilities/2015/07/27/moreutils...

Re: Deno Cron

#36
post #17

My first question when I am considering a product like this is how can I get an email when there's an error in my application. Why isn't that in the top level feature list of everything like this, or am I unusual in thinking that this is an essential feature of any hosting system?

[deleted]

Re: Deno Cron

#37
I 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 - its unnecessary developer hours. The functionality is so common that it should just work. Perhaps stemming from that there seem to be two recent trends:

1. Services like this cron with Dyno Deploy or Vercel where the cloud things are abstracted away for you.

2. I have no data to back it up but it seems like JVM is experience a bit of a comeback with a few companies adopting Kotlin for backend and, also subjectively, talk about Elixir has increased here on Hacker News (we've all seen that table that shows how the Erlang VM is cron/background jobs/logging service/KV store all rolled into one). And if those are not the trends I feel like they should be.

Both of those are very appealing to me as a team lead. Honestly, I have never been a fan of managing services in AWS/GCP/etc - the setup overhead rarely seemed to outweigh the pros, at least until some heavy amount of data start moving around. I might be stating the obvious - less work is definitely better, but pretty much every company I have consulted for in the last few years had a (crappy) bespoke cloud setup that was a massive time sink.

Re: Deno Cron

#38
post #6

Earlier quoted context omitted.

we've gotten a bunch of interest for this and the team is discussing it :)

Personally I would stay within your niche and focus on documentation, guides, and outreach to convert more people to your stack. A few simple but very reliable easy solutions is better than a lot of not great solutions.

[deleted]

Re: Deno Cron

#39
> How exactly does Deno Deploy know there’s a cron in your code, even when there’s no web server handling requests?

> When a new production deployment of your project is created, an ephemeral V8 isolate is used to evaluate your project’s top-level scope and to discover any Deno.cron definitions. A global cron scheduler is then updated with your project’s latest cron definitions, which includes updates to your existing crons, new crons, and deleted crons.

Having cron jobs defined in the code itself just feels weird. I get the convenience of doing things "in one place", but it's such an orthogonal concept. But I suppose combining things is part of the allure of deno any way.

Now that aside, the Flavor Flav dinosaur is the best thing I've seen all week.

Re: Deno Cron

#40
post #37

I 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 -…

For sure. As someone who has stayed away from this part of the biz, infrastructure always looked like makework to me. Necessary, mind you, but still makework that was indicative of poor/insufficient computing primitives for services.

> it seems like JVM is experience a bit of a comeback with a few companies adopting Kotlin for backend

JVM 21 adding virtual threads, and Spring Boot 3.2 using them with one line of config is huge. We can now write simple code that looks blocking and let the runtime handle it instead of writing async function/await everywhere. Personally I'm loving Spring Boot 3.2 with Kotlin, especially for the fact that I can bundle scheduled jobs, API, and frontend all in one place for my indie projects. Plus the JVM world of devs seems to have a somewhat decent appreciation of how to make web services that aren't rife with unnecessary coupling.

The bad? There is a legendary amount of cargo-culting blog posts and questionable advice around Spring Boot, often for older versions.

Post reply on HN