Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js • Hacker News Board

Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js

#111

Post by atleta » Sat, Mar 11, 2023, 6:44 PM UTC

bayesian_horse wrote: post #102

programmarchy wrote: post #91

Earlier quoted context omitted.

"It may go down" vs. "Save X hours of dev" Depends what you're building, but likely a good trade if it's an MVP. At $30/mo you're already ahead if it saves you 1 hour of dev time. Most of the time, I don't want control over my infrastructure (boring, low value); I'd rather focus on building features (fun, high value).

And at least when I host stuff it still goes down at least from time to time and I have to put in additional time to fix it. You need to put up significant resources in order to beat a dedicated team running this. Many companies can do that. Many can't. Even Twitter increasingly runs into problems with site reliability...

I never had any issue where the task queue would go down but not the rest of our infrastructure. If it's a large system (which is definitely relative) then it can become a job on it's own to keep this part of the system running. But by then, I guess, you'll have the resources too.

Also, you don't know the team size behind this service, as I mentioned in my original comment.

Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js

#112

Post by atleta » Sat, Mar 11, 2023, 7:03 PM UTC

programmarchy wrote: post #91

atleta wrote: post #58

Earlier quoted context omitted.

Because it's one more service that you have very little control over and one more service that you have to manage over a web interface or (maybe) their own command line tool. It's on a separate network so they may go down and cause outage in your own app, go out of business, etc. (Yes, your IaaS service provider can go down as well, but that's a much larger operation and something that's very-very likely to have a mu…

"It may go down" vs. "Save X hours of dev" Depends what you're building, but likely a good trade if it's an MVP. At $30/mo you're already ahead if it saves you 1 hour of dev time. Most of the time, I don't want control over my infrastructure (boring, low value); I'd rather focus on building features (fun, high value).

Sure, it might be good for an MVP where you don't mind about reliability, developer experience and how long you can expect the service to be in business.

If these start to matter, even picking a service from a list of possible providers takes time. Learning their tools, their APIs takes time, etc. OTOH if you have a project template, a setup you know, doing an MVP with that can be really cheap/quick. If not, I can see how this makes sense. But I'm not sure you can have a sustainable business just by serving people building MVPs.

Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js

#113

Post by bayesian_horse » Sat, Mar 11, 2023, 10:05 PM UTC

rozap wrote: post #110

bayesian_horse wrote: post #96

Interesting you can make money from this sort of thing.

Every time a crazy workaround for node.js's shortcomings arises I think about how hardware engineers must feel. Your magnum opus is giving people 2, 4, even 16 core supercomputers and then the software engineers come along and start using this hot new single threaded tech called node. Sure, run multiple processes and then you get to spend most of the cycles passing stuff around. I think if I was a hardware engineer I…

Nobody is stopping you from running multiple node workers on the same machine. Singlethreadedness actually makes things easier, and even with my limited experience in Dotnet I have already had issues with thread-safety...

Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js

#114

Post by jamesmcintyre » Wed, Mar 22, 2023, 6:31 PM UTC

You mention managing webhooks as another tedious part of integrating with third party api’s at scale but I’m not seeing in defer docs any considerations for this.

I’m guessing while I could use defer to create a job that calls a 3rd party api to create a webhook POST call (later trigger by some activity on their side) I would still be building an webhook endpoint in my app to receive that request and then optionally hand that data to another new defer job? In other words defer does not magically create and handle ingesting webhooks as a way to initiate a job right?

Another question regarding memory / hard disk limits for executions (500mb / 10mb on hobby) is 10mb on “storage” limit pertaining to, for instance, what the final build size of that function would be or does that fall under memory? I ask because for my use case there’s potentially scenarios when the defer function would be using numerous npm libraries and local files so i’m curious what limits im looking at there. (EDIT: Just notice build limits, i’m assuming thats what would pertain to “bundle” size for bundled code?)

Lastly in limits does “concurrency” mean how many executions across the entire account can run at once or is that just for that execution?

Product looks awesome by the way, great job solving a real pain point for devs!