by 0xedb on 11/29/23, 4:03 PM with 183 comments
by vvpan on 11/29/23, 6:41 PM
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.
by phoe-krk on 11/29/23, 8:36 PM
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.
by syrusakbary on 11/29/23, 9:13 PM
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++}`);
})
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?
by seanw265 on 11/29/23, 9:08 PM
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?
by ilaksh on 11/29/23, 10:03 PM
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`.
by koolba on 11/29/23, 6:56 PM
> 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.
by aleksiy123 on 11/29/23, 5:52 PM
This isn't quite that but close.
From my experience there 5 main components for larger scale system.
- Request server
- database
- queue
- background worker
- offline batch jobs
I feel like so far serverless has the first 3 fairly well developed but the last two are still underdeveloped.
But maybe I'm just not aware of other solutions?
by bsnnkv on 11/29/23, 10:05 PM
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.
by manicennui on 11/29/23, 8:22 PM
by lambtron on 11/29/23, 4:20 PM
by its-summertime on 11/29/23, 9:30 PM
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.
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.
Yes I could round the Date.now() to the last minute, however, if Deploy ever goes over the minute boundary, that's all kaput.
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)
https://www.freedesktop.org/software/systemd/man/latest/syst...
by skybrian on 11/29/23, 5:42 PM
by leroman on 11/29/23, 6:30 PM
by mirkodrummer on 11/29/23, 11:42 PM
by obblekk on 11/29/23, 6:05 PM
Would be really awesome if this could be used to offload long lived jobs from the request.
Defer.run is building this for vercel and it’s really cool.
by shepherdjerred on 11/29/23, 7:51 PM
I spent a day or two migrating a TypeScript project [-1] over to Deno from NodeJS. Here's what I had to do:
* 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`
* 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.
* 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 https://esm.sh, which worked for some packages but not others.
* Figure out how to get Lodash working with TypeScript. It's not simple. [0]
* Use a hack to get typeorm with sqlite working. [1]
* 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.
* 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 `
* 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].
* 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:
* 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.
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.
[-1]: https://github.com/shepherdjerred/glitter-boys/tree/sj/deno
[0]: https://stackoverflow.com/a/66073607
[1]: https://github.com/typeorm/typeorm/issues/6123#issuecomment-...
[2]: https://github.com/Sansossio/twisted/issues/97
by phatboyslim on 11/29/23, 9:42 PM
by asim on 11/29/23, 9:02 PM
by tengbretson on 11/29/23, 8:03 PM
by blitz_skull on 11/30/23, 1:28 AM
by ushakov on 11/29/23, 5:44 PM
by JLCarveth on 11/29/23, 7:48 PM
by Dig1t on 11/29/23, 5:36 PM
by iobdas on 11/29/23, 4:48 PM
by TimTheTinker on 11/29/23, 11:49 PM
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.
by vcryan on 11/30/23, 12:07 AM
by souvlakee on 11/30/23, 7:11 AM
by rabbits_2002 on 11/29/23, 11:07 PM
by cja on 11/29/23, 6:01 PM