Live data from Hacker News

Deno Cron

deno.com

91–100 of 190 posts

Re: Deno Cron

#91

Earlier quoted context omitted.

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

> But it's mostly dictated by overarching decisions that constrain both how it runs and how it's made (AKA, outside somewhere).

While annoying, there's often a good reason behind those if you can drill down to the engineers that asked for that rule.

Just as an example, it's easy to provide a single HA solution at the infrastructure tier... provided the infra people can make a few assumptions about your app (stateless, can handle multiple copies running at once, etc). It's virtually impossible to build HA that makes no assumptions, and it's incredibly burdensome to support 85 different HA implementations with varying sets of assumptions.

It makes business sense to have infra do the HA instead of each developer team, and that means restrictions on how apps are built and run.

What you're experiencing is the platform-ization of a bunch of aspects of the app.

Making nice spaghetti usually consists of finding the rules, finding the people who made them, and then grabbing them and asking "what does it take for this app to be in prod 15 minutes after we push the last commit?". It sounds like it will be a lot of people because there's a lot of rules, but there's usually like a half-dozen teams that make all the rules.

It will likely force you to build differently than you would have, but it will also mean that you're more likely to have 0 friction and you're more likely to get help with the friction you do encounter.

Re: Deno Cron

#92

Have the team at Deno not heard of systemd timers?

I agree. "0 * * * *" to schedule something hourly is a poor for developer experience. systemd timers use a more human readable "hourly". "0 1 * * *" to run at 1:00 daily becomes "1:00". systemd timer calendar events read like actual timestamps.

Re: Deno Cron

#93

Earlier 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.

You can put ordinary crontab into your repo.

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

Re: Deno Cron

#95
post #23

Earlier quoted context omitted.

I've started tossing https://ntfy.sh/ alerts into my Deno apps to get push notifications for things I'm interested in

My wife has had good luck using Pushover [1], which seems similar. I wonder how these services compare? [1] https://pushover.net/

I actually use Pushover for a project but it just does the notification part and requires me to catch all errors and send them to Pushover. I'm looking for the hosting service to catch unhanded errors automatically

Re: Deno Cron

#96
post #42

Earlier quoted context omitted.

You should check Windmill.dev.

I will check out windmill. Though it does look somewhat complex. One tangentially related is I'm looking for somewhere to just run a python script once a day. I'll see if I can do that with windmill.

Yes, you can do that quite trivially on WM.

Re: Deno Cron

#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 runtime with something unrelated?

Re: Deno Cron

#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 deployed here: https://weak-stoat-26.deno.dev

So, effectively, it seems that Deno.Cron clones the JS context but any changes done to that context will not be reflected in the Deno.serve. And, if that's the case, why don't handle Cron jobs in a different flow rather than mixing them with Deno.serve? (I think it can lead to unintended side-effects)

I'd love if someone from the Deno team could provide more context here, maybe I missed something?

Re: Deno Cron

#99

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 hard to ignore when it takes up my entire screen and I have to scroll to see anything else. AI artwork is popping up everywhere and I don't think it looks as cool as people seem to think. It comes off incredibly tacky.

Re: Deno Cron

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

I don't understand the reluctance to hire a system administrator. If you have two or more technical folks, at least one of them should be a sysadmin (or "devops" if you prefer). Pretending that it's an unskilled role that anyone should pick up reflects a poor understanding of the industry.
Post reply on HN