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:<p>1. Services like this cron with Dyno Deploy or Vercel where the cloud things are abstracted away for you.<p>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.<p>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.
The AI-generated imagery at <a href="https://deno.com/blog/cron/cover.png" rel="nofollow noreferrer">https://deno.com/blog/cron/cover.png</a> 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.<p>I know that displaying artwork is not the point of the article, but please, at least make it believable when you look at it for more than one second.
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".<p>Namely, I ran this example.<p><pre><code> 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++}`);
})
</code></pre>
Example deployed here: <a href="https://weak-stoat-26.deno.dev" rel="nofollow noreferrer">https://weak-stoat-26.deno.dev</a><p>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)<p>I'd love if someone from the Deno team could provide more context here, maybe I missed something?
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.<p>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.<p>Why pollute the runtime with something unrelated?
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.<p>But why not include any kind of schedule specifier that is a bit less cryptic and error prone? Is it really so much code?<p>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`.
> How exactly does Deno Deploy know there’s a cron in your code, even when there’s no web server handling requests?<p>> 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.<p>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.<p>Now that aside, the Flavor Flav dinosaur is the best thing I've seen all week.
Nice, I was just wondering if there was an opportunity for a product similar to vercel for batch jobs.<p>This isn't quite that but close.<p>From my experience there 5 main components for larger scale system.<p>- Request server<p>- database<p>- queue<p>- background worker<p>- offline batch jobs<p>I feel like so far serverless has the first 3 fairly well developed but the last two are still underdeveloped.<p>But maybe I'm just not aware of other solutions?
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.<p>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.
Overlapping as an option would be nice, if I'm using cron to pull data to append to a database, and the append fails, I can normally retry. However, without overlap, I can't sit there doing retries since that will block future cron runs.<p>Timezones would be nice, "This helps avoid issues with time zones which observe daylight saving time." But it also causes issues with daylight saving time. I can't run something at 9 in the morning, I need to run it 1-2 hours before-hand, calculate the offset, and then queue a run 1-2 hours later. Or I can run 2 crons and have one or the other die early. Point being, all solutions become very hacky very fast.<p>It would be nice if an object was passed to the handler that had a targetDate for the ideal start time would be, so runs can be easily labeled and separated.<p>Yes I could round the Date.now() to the last minute, however, if Deploy ever goes over the minute boundary, that's all kaput.<p>In a similar vein: Systemd timers have some nice features, AccuracySec/RandomizedDelaySec/FixedRandomDelay, some options similar to that would be nice (of course, with minute resolution instead) (and of course, fixed delay can be pre-calculated, but it would be nice to just say 30m and have deno runtime manage that for me)<p><a href="https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html" rel="nofollow noreferrer">https://www.freedesktop.org/software/systemd/man/latest/syst...</a>
Nice, years ago I wrote a TypeScript (originally CoffeeScript re-written to TypeScript) library to generate schedule times for a cron between two time points, should be easy to write a service like this with it.<p><a href="https://github.com/romansky/JsCron">https://github.com/romansky/JsCron</a>
Vercel is it you? Seems like Deno Runtime is implementing what Deno Deploy would sell. While I understand it from a business perspective it totally makes me uninterested, I’d rather keep my dysfunctional marriage with AWS
How long does the job get to run?<p>Would be really awesome if this could be used to offload long lived jobs from the request.<p>Defer.run is building this for vercel and it’s really cool.
I want to love Deno. It seems to really modernize TypeScript development. I just haven't had good experiences with it.<p>I spent a day or two migrating a TypeScript project [-1] over to Deno from NodeJS. Here's what I had to do:<p>* Change all of my local imports to something that would work with Deno. That meant appending `.ts` or `index.ts` for folders, except in some cases where Deno requires `.js`<p>* Modify my monorepo to play nice with Deno -- an import map does this easily. Deno has documentation around import maps, but I had to figure out the solution myself. Also, import maps are currently broken in JetBrains IDEs.<p>* Change my NPM imports to something that would work with Deno. The most straightforward thing to do was just change `import "foo"` to `import "npm:foo"`, but this felt hacky so eventually I used <a href="https://esm.sh" rel="nofollow noreferrer">https://esm.sh</a>, which worked for some packages but not others.<p>* Figure out how to get Lodash working with TypeScript. It's not simple. [0]<p>* Use a hack to get typeorm with sqlite working. [1]<p>* Try out `deno compile`, only to determine that it somehow works differently than `deno run`. My project simply wouldn't work with `deno compile`, probably because my project has some system dependencies that don't get properly linked/included.<p>* Setup my scripts to properly lint my project. Deno has formatting/linting built-in, but it's split across many commands with different usages. For example, I can run `deno fmt` to format my entire project, but I have to give Deno a path to run `check` or `lint`, e.g. `deno check src/index.ts
`<p>* Patch a third-party library that was setting an HTTP header to `null`. NodeJS handles this case just fine, but Deno throws an error [2].<p>* Attempt to build my UI (astro + react) with Deno. It seems some people have gotten this partially working, but I gave up and stayed on NodeJS for building my UI. This led to me:<p>* Using dnt [3] to build a Deno package for consumption with NodeJS/npm frontend. This was actually surprisingly simple; kudos to the author of the dnt library.<p>After all of that work, I finally was able to use Deno in my project. It was really cool! Unfortunately, both VS Code and IntelliJ with Deno are essentially unusable [4]. Or, at least, unacceptably slow compared to what I had with NodeJS.<p>[-1]: <a href="https://github.com/shepherdjerred/glitter-boys/tree/sj/deno">https://github.com/shepherdjerred/glitter-boys/tree/sj/deno</a><p>[0]: <a href="https://stackoverflow.com/a/66073607" rel="nofollow noreferrer">https://stackoverflow.com/a/66073607</a><p>[1]: <a href="https://github.com/typeorm/typeorm/issues/6123#issuecomment-1824773630">https://github.com/typeorm/typeorm/issues/6123#issuecomment-...</a><p>[2]: <a href="https://github.com/Sansossio/twisted/issues/97">https://github.com/Sansossio/twisted/issues/97</a><p>[3]: <a href="https://github.com/denoland/dnt">https://github.com/denoland/dnt</a><p>[4]: <a href="https://github.com/denoland/vscode_deno/issues/895">https://github.com/denoland/vscode_deno/issues/895</a>
Wrote similar when I was working on an API platform. Used http callbacks. <a href="https://m3o.com/cron/api#Schedule" rel="nofollow noreferrer">https://m3o.com/cron/api#Schedule</a>
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.
I love Deno. I’ve been playing with it for a long time now. But the fact that Deno Deploy still doesn’t have a “deploy” button but we’ve got cool crons just seems… backwards?
What I see is yet another way that the backend JS world is finally achieving something .NET had over 10 years ago[0].<p>Node/Deno/Bun/etc. + npm sounds super straightforward (and it is at first). But I've thought for years that it's far easier to be productive on the backend on .NET in Visual Studio, since it's simpler to design, deliver, and maintain infrastructure.<p>[0] <a href="https://www.hangfire.io/" rel="nofollow noreferrer">https://www.hangfire.io/</a>
while this looks useful it certainly shows what they are most concerned about which is making money off their cloud service.
I don’t think they have much interest in being a Node alternative anymore.
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?