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

171–180 of 190 posts

Re: Deno Cron

#171

Post by demosthanos »

pseudosavant wrote: post #169
demosthanos wrote: post #163

Earlier quoted context omitted.

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

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

What you're proposing alters the semantics of JavaScript-the-language, which is outside the scope of the Deno project. Pretty much everyone is already in the habit of avoiding variables in the global scope. Why should they go to the trouble of redefining the semantics of JavaScript for something that is already widely understood?

Re: Deno Cron

#172

Post by st0le »

cja wrote: post #95
skybrian wrote: post #25

Earlier quoted context omitted.

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

https://sentry.io/welcome/ ?

Re: Deno Cron

#173

Post by brycelarkin »

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…

I don’t think having a breadth of knowledge in frontend, backend, and cloud infra is too much to ask.

Think of how much is asked from other white collar professions such as law and medicine.

Re: Deno Cron

#174

Post by mfateev »

aleksiy123 wrote: post #16

Nice, I was just wondering if there was an opportunity for a product similar to vercel for batch jobs. 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…

Check out temporal.io. It has support for schedules as well.

Re: Deno Cron

#175

Post by alberth »

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

PaaS

Sounds like you’d like to use a PaaS provider.

Heroku/Render/Fly/etc.

Re: Deno Cron

#177

Post by theshrike79 »

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]

Very few people "understand" git outside of the core development team.

People do know how to use git in their day to day life. Clone, pull, push, maybe a cheeky rebase if they're up for it.

But bisecting and all that deep level stuff? No way an "average developer" will do that without prompted.

I consider myself a senior developer and in many cases I just resort to re-cloning the repository and copying my changes over to it by hand instead of spending time fighting git tooling to get everything done Properly. My way is faster and I can go on with my day.

Re: Deno Cron

#178

Post by pseudosavant »

demosthanos wrote: post #171
pseudosavant wrote: post #169

Earlier quoted context omitted.

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

> 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. What you're proposing alters the semantics of JavaScript-the-language, which is outside the scope of the Deno project. Pretty much everyone is already in the habit of avoiding variables in the global scope. Why should they go to the trouble of redefining…

`Deno.cron` isn't JavaScript-the-language. It is part of a runtime. They could implement this in a different way. Just like how Web Workers still just use JavaScrip-the-language, but within a different execution context than ``.

Re: Deno Cron

#179

Post by gorbypark »

phatboyslim wrote: post #112

Anyone here using Deno in a production workload? Genuinely curious about your experience.

It depends on what you mean by production! I am using Supabase in a hobby-level project that's "in production" (aka live on the internet). Supabase uses Deno to deploy functions. I am currently using Supabase functions (which are Deno Deploy functions) for both an API (interfacing with data not in a Supabase database) as well as some web-hook listener fuctions that keep Supabase accounts in sync with Stripe user IDs.

Overall, no issues or complaints. It's always a bit odd coming from npm/node into something like Deno, but the differences are really trivial. I believe Deno has become much more compatible with Node since I really had to update the project, so the differences are probably even smaller now.

Re: Deno Cron

#180

Post by auggierose »

lucasyvas wrote: post #161
conradfr wrote: post #50

Earlier quoted context omitted.

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…

Doesn't make any kind of sense to me. It might be best practices, but if you can automate things, you should be doing it. And the best automation happens behind a great abstraction.
Post reply on HN