Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno Cron

deno.com

Post reply on HN
Print view View original

111–120 of 190 posts

Re: Deno Cron

#111

Post by igorzi »

syrusakbary wrote: post #98

I was pleasantly surprised to see this, but it seems that the JS context in each run of the cron script is cloned so cron jobs are actually run in a separate "process". Namely, I ran this example. let s = 0, r = 0; Deno.cron("Add second", "* * * * *", async () => { console.log(`Add second ${s++}`); }); Deno.serve(async (_req) => { return new Response(`Seconds Running: ${s} / Number of requests: ${r++}`); }) Example d…

If you need to manipulate state - you should use Deno KV or some other persistent database. V8 isolates are created on-demand to handle Deno.cron and Deno.serve requests, potentially in different regions. You should not make assumptions that the same isolate will be used to handle all requests.

Re: Deno Cron

#114

Post by ramesh31 »

seanw265 wrote: post #97

I like a lot of what Deno does, but I'm having some trouble understanding why this (along with Deno's KV and Queues offering) is part of the Deno runtime. The blog post touts this as a feature to reduce the amount of code to get up and running, but a library would accomplish the same thing. A first-party library could even directly integrate with Deno Deploy in the same way that this appears to. Why pollute the runti…

>Why pollute the runtime with something unrelated?

Because money.

They are venture funded and need to show some kind of path to profitability.

Re: Deno Cron

#115

Post by FragenAntworten »

phoe-krk wrote: post #87

The AI-generated imagery at https://deno.com/blog/cron/cover.png is actually painful the longer you look at it. The multiple watch hands might be an artistic effect, but the clock lacks the tenth hour and has two elevenths, the dinosaur's legs make absolutely no sense, and the water reflections show a different pattern on the dinosaur legs and a completely different set of clock hands than what is visible above. I kn…

It's especially disappointing to see Deno doing this, because in the past they've used endearing art made by an artist, hashrock, which I liked very much.

Re: Deno Cron

#116

Post by danfarrelly »

aleksiy123 wrote: post #55
danfarrelly wrote: post #27

Earlier quoted context omitted.

This is pretty much what Inngest is ( https://www.inngest.com/ ). Runs on Deno as well.

Ingest is definitely nice. Its design is an orchestrator/scheduler where you offload your workers as serverless functions. The only issue is for background jobs you need to design it in such way to not run in to timeouts. Which makes it slightly more complex then just having a single executable running periodically. There is also https://www.defer.run/ which run your code on their infra and don't have timeouts. But t…

We'll also be supporting long-running services as well in the near future which subscribe to updates from Inngest, rather than get invoked via HTTP.

Currently, to get beyond the ~5 min limit per step, you'd need to deploy to something non-serverless like Fly.io, Render, or your own instance running Express.js or similar.

Re: Deno Cron

#117

Post by ilaksh »

Great, but do they really have to leave the cron schedule format as the only option for specifying? It seems like a great idea if it's 1975 and you are dealing with limitations of that time. And I think it's good to keep it as an option.

But why not include any kind of schedule specifier that is a bit less cryptic and error prone? Is it really so much code?

Maybe someone has a package already that can wrap this or output a schedule from a human readable description or something. Maybe something like `human-to-cron`.

Re: Deno Cron

#118

Post by bsnnkv »

There is no doubt that this is a cool technical feat, but I don't think you'll catch me handling cron-like scheduling like this alongside application code.

I can see from comments like vvpan's that there is a fatigue around managing services in AWS/GCP/etc, but I have gone very much in the other direction in the last few years towards bare metal servers managed with NixOS. I feel much more confident in handling scheduled jobs on bare metal with Systemd timers than tying myself even deeper into a specific language+deployment solution ecosystem.

Re: Deno Cron

#119

Post by FuriouslyAdrift »

mike_d wrote: post #43
vvpan wrote: 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 -…

It is really disappointing to me when I hear takes like this. As an industry we are splitting the roles of programmers and engineers so that programmers can just throw spaghetti at the wall and it is the engineers problem to happily run it. We need more well rounded people that also fundamentally understand how their code is executing on the backend so performance and cost can be optimized.

What you are descibing is an SRE... in the old Google definition.

Re: Deno Cron

#120

Post by alexgarcia-xyz »

ilaksh wrote: post #117

Great, but do they really have to leave the cron schedule format as the only option for specifying? It seems like a great idea if it's 1975 and you are dealing with limitations of that time. And I think it's good to keep it as an option. But why not include any kind of schedule specifier that is a bit less cryptic and error prone? Is it really so much code? Maybe someone has a package already that can wrap this or ou…

A JSON schedule format is coming soon: https://github.com/denoland/deno/pull/21340
Post reply on HN