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

161–170 of 190 posts

Re: Deno Cron

#161

Post by lucasyvas »

conradfr wrote: post #50
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 -…

For cron jobs in Elixir you can use: - [0] Quantum, quite simple and supports cron syntax. - [1] Oban, which is a job runner, requires a DB, but also supports periodic jobs with a cron syntax. (probably others but that's the ones I've used) [0] https://github.com/fanduel/quantum-elixir [1] https://github.com/sorentwo/oban

There's a good argument to make that you should never use your application code for running tasks better handled by infrastructure. Eventually you will want an operations team of some kind and they will absolutely hate you for doing this.

It doesn't scale, organizationally speaking. Logic? write it in app code sure. How it's triggered or runs? Probably don't go near that. Use your job scheduler (CRON) or cloud infra to do it. Your operations team can port it, scale it, and cost optimize it without breaking a sweat.

If more sysadmin / DevOps are hired to help they are going to roast your development team if they can't actually help you. Elixir may be able to glide by some of this given how flexible its process model is - but it's not good general advice.

Re: Deno Cron

#162

Post by qudat »

pseudosavant wrote: post #156
igorzi wrote: post #111

Earlier quoted context omitted.

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.

I love Deno, and it is because it usually avoids these kind of footgun situations. It is hard to grok that you can access those variables in the shared scope, but if you manipulate them, they are actually in completely different isolates. I understand architecturally why it is that way right now though. I just wish there it was more obvious that you are really inheriting a fresh state somehow. Maybe only `const` shou…

I agree, this seems error prone. People do all kinds of crazy stuff with module variables, this is a big foot gun.

I’m all for making access to cloud services easier, but this screams product development not language development.

Re: Deno Cron

#163

Post by demosthanos »

pseudosavant wrote: post #156
igorzi wrote: post #111

Earlier quoted context omitted.

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.

I love Deno, and it is because it usually avoids these kind of footgun situations. It is hard to grok that you can access those variables in the shared scope, but if you manipulate them, they are actually in completely different isolates. I understand architecturally why it is that way right now though. I just wish there it was more obvious that you are really inheriting a fresh state somehow. Maybe only `const` shou…

Is this really that surprising of a behavior, though? PHP apps threw away state after each request, and in the Node.js world data doesn't persist across server restarts or across instances of the app.

The only way I could see someone being confused about this is if they thought Deno Deploy was just a single VM running a single instance their code.

Re: Deno Cron

#164

Post by brundolf »

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

+1, as someone whose company has a crappy bespoke cloud setup that's a massive time sink

Re: Deno Cron

#165

Post by white_dragon88 »

iteratethis wrote: post #131
mike_d wrote: post #43

Earlier quoted context omitted.

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.

You're wrong. App/mobile and web developers are stretched beyond belief as it comes to skills expected of them. This handbook gives a reasonable overview of the scope of a front-end developer: https://thoughtworksinc.github.io/front-end-handbook/en/ Yet it's still incomplete, most of the cloud stuff isn't even included. We're over-asking people. Take Spotify. Has an army of quite decent engineers. They had to actuall…

[dead]

Re: Deno Cron

#166

Post by SOLAR_FIELDS »

white_dragon88 wrote: post #165
iteratethis wrote: post #131

Earlier quoted context omitted.

You're wrong. App/mobile and web developers are stretched beyond belief as it comes to skills expected of them. This handbook gives a reasonable overview of the scope of a front-end developer: https://thoughtworksinc.github.io/front-end-handbook/en/ Yet it's still incomplete, most of the cloud stuff isn't even included. We're over-asking people. Take Spotify. Has an army of quite decent engineers. They had to actuall…

[dead]

This is a hot take statement in both directions.

Git is complicated. You’ll also probably only use 10% of it unless you’re writing Git tooling as part of your work.

One does not simply understand “just Git”. One also is not a poor excuse for a developer for not bothering to understand the 90% of Git that is never even used in a day to day workflow, and it’s not really true that an average developer struggles to understand the 10% of Git that they need to know to do their jobs.

Re: Deno Cron

#167

Post by CGamesPlay »

hu3 wrote: post #148
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…

This is something I like about in Laravel: $schedule->call(new DeleteRecentUsers)->daily(); $schedule->job(new Heartbeat)->everyFiveMinutes(); $schedule->exec('node /home/forge/script.js')->lastDayOfMonth('15:00'); $schedule->command('foo') ->weekdays() ->hourly() ->timezone('America/Chicago') ->between('8:00', '17:00'); $schedule->command('emails:send') ->hourly() ->days([Schedule::SUNDAY, Schedule::WEDNESDAY]); htt…

As someone who has not seen this syntax before, it's OK. But, "timezone" shouldn't be a separate method, it should be a parameter to the function taking the time specification. Functions named as nouns should be named "onNoun" instead (onWeekdays, onDays). It's also very unclear what happens if I do something like ->daily()->weekdays() ("daily on weekdays") or ->weekdays()->lastDayOfMonth('15:00') ("on the last weekday of the month at 15:00").

Re: Deno Cron

#168

Post by demosthanos »

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…

The docs already link out to a cron string generator: https://www.npmjs.com/package/cron-time-generator

Re: Deno Cron

#169

Post by pseudosavant »

demosthanos wrote: post #163
pseudosavant wrote: post #156

Earlier quoted context omitted.

I love Deno, and it is because it usually avoids these kind of footgun situations. It is hard to grok that you can access those variables in the shared scope, but if you manipulate them, they are actually in completely different isolates. I understand architecturally why it is that way right now though. I just wish there it was more obvious that you are really inheriting a fresh state somehow. Maybe only `const` shou…

Is this really that surprising of a behavior, though? PHP apps threw away state after each request, and in the Node.js world data doesn't persist across server restarts or across instances of the app. The only way I could see someone being confused about this is if they thought Deno Deploy was just a single VM running a single instance their code.

Kind the point of Deno Deploy is that you never have to think about a unit like a VM or container.

The runtime shouldn’t allow you to mutate variables in a parent scope. It probably shouldn’t allow any shared context at all. Because it isn’t actually doing that.

Everything should be passed into the cron function as an argument. It seems like this should be more like the interaction with web workers where those clearly execute in their own context.

Re: Deno Cron

#170

Post by imbnwa »

ramesh31 wrote: post #114
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.

People acting like Bun, which is also ventured funded, isn't going to be doing a lot of similar things once they stabilize their runtime. Node had a lot of runway in the era/climate it was made in.
Post reply on HN