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?
Deno Cron
151–160 of 190 posts
Re: Deno Cron
#152I 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 -…
There is a collection of new tools trying to address this exact problem such as Nitric, Winglang and Ampt for example. (disclaimer, I work on Nitric)
Re: Deno Cron
#153What I see is yet another way that the backend JS world is finally achieving something .NET had over 10 years ago[0]. 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. [0] https://www.hangfire.io/
To be fair, Visual Studio is completely optional (and subjectively much worse for publishing/deployment than using CLI).
Some developers are moving over to macOS with Rider + Visual Studio Code combo nowadays.
Re: Deno Cron
#154Earlier 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…
This whole post was great except for the first sentence.
I'm getting old and I feel overwhelmed by the creep of "stuff" that I need to know. For me, it used to be UNIX + C + bash shell was enough to survive. My only defence is to write a small Wiki page for each category of "stuff". After a year on the job, I have built an organic encyclopedia that I can quickly search to remind me about "stuff" that I use infrequently.
And, to be fair, holy shit is modern web programming complicated. I am consistently amazed by the results on a wide variety of platforms.
EDIT
Wow, the link that you shared is amazing. Very well written. Thank you to share.
Re: Deno Cron
#155Nice, 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…
I'd add a 6th one:
- workflow system
Re: Deno Cron
#156I 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 d…
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` should be allowed at the top-level? That still wouldn't handle objects really, but it'd be better than nothing.
Re: Deno Cron
#157I 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 -…
> 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.
Part of that shift is that prior to the cloud, the development environment and production environments were very similar. By that I mean if a programmer could set up his debian / redhat laptop from the command line, then it wasn't a big jump to set up a server running debian / redhat in a production environment.
But no one in their right mind runs k8s on their laptop just to support VSCode and a compiler. Worse they could not run AWS/GCP because they are proprietary, insanely large, complex and forever changing. I'm pretty sure becoming an expert engineer in those environments is a full time job. The end result is a new class of engineers have arisen that look after the production side, and the developers just throw their code over the wall once it's tested.
I'm sure the cloud providers love this, as they have created a cohort of engineers that have invested years in learning their product, now have their wages dependent on that product being used within their organisation, and a total monopoly over that product because it can never be reproduced by anyone else. But for the industry as a whole, it looks to be a backward step. Once the problem expands beyond what a single human mind can cope with, you need teams. The communication overhead of a team means they don't have a hope of being as productive as a single person.
The share amount of complexity introduced by these proprietary cloud frameworks looks to be unnecessary. Most of it smells like technical debit created by organic growth together with an insistence on backward compatibility (don't want to give those locked in customers an excuse to move). And desktop OS's are (Debian / Windows / ...) are insecure by design, at least when compared to their phone brethren. And, their phone brethren look somewhat like cloud designs now, Phones have isolated apps with private data areas. The apps communicate via channels provided by the OS, and the availability of those channels is controlled by permissions assigned by the user. In the cloud we isolated things for performance as they could run on distance machines, whereas in a personal device we did it for security. But the end result looks similar.
So maybe one day we will end up where we started, with a developer environment looking like the cloud we deploy too. I fear I'm too old to experience if / when it does happen, but it does seem like something we should aspire to.
Re: Deno Cron
#158Earlier 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…
While I agree that there is a lot to frontend development, that list is ridiculous. It is useful as far as knowing what categories of things you may come across at some point. But as far as things you need to know? This is significantly overstating it.
It's a pretty fair list of things I have come across in my career. As lead, it's my job to know at least generally about all these things, and for many to have deep experience and intuition into others.
The breadth of my frontend career has only kept expanding over the last 10 years, it's definitely harder than when I started.
Re: Deno Cron
#159Earlier 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.
Straight up have engineers I work with on the regular who don't know how to use a Linux distro. The concept of a VPS or SSH'ing into something, not even a prod env, is seemingly terrifying to people.
I feel this deeply, many of the devs in my company don't know linux, kubernetes or even docker, though the services they developed run on these things, I can understand that they need to focus on business logic and implementations, but it just seems odd for me that they don't even try to understand the underlying infrastructure, they just leave it to devops guys.
Re: Deno Cron
#160I 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 -…
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.
And security