Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 114 posts

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

#91

Post by programmarchy »

atleta wrote: post #58
programmarchy wrote: post #44

Earlier quoted context omitted.

With your solution you need to manage infrastructure. Why not abstract that away?

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

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

#95

Post by buglungtung »

wittydeveloper wrote: post #90
buglungtung wrote: post #88

I have two questions 1. Does the retry function work based on the logic that the same input will always return the same output, even if the code uses non-deterministic methods like "new Date()" or "Math.random"? If not, your retry logic may produce unpredictable results and therefore not be safe. 2. According to the article "How Defer Works" ( https://docs.defer.run/platform/how-defer-works/ ), you will be running ou…

1. Yes, we currently provide a simple approach to retries but are already working on providing features for idempotency. 2. All sensitive data (tokens, env vars) are encrypted on our side, however, we don't prevent users to print their values in the logs yet - it's planned in our next releases.

I see. I hope you have a great journey. I used to want to implement a system like that for my import/export tasks because my workload heavily involves importing and exporting CSV files. But the deadline defeated me ;) I have no time to design a system like that By the way, I really love how simple the defer API is to use

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

#97

Post by bayesian_horse »

gearnode wrote: post #18
brap wrote: post #14

I only skimmed through the landing page so maybe I missed it, but the value proposition isn't clear to me. If you're going to `await` for the contacts import to finish anyway, what's the advantage of separating the import logic from your main API? It's blocked, so might as well be part of the same service, no? I could see maybe if the API returned right away with a pointer the user can later poll for task progress, b…

> I only skimmed through the landing page so maybe I missed it, but the value proposition isn't clear to me. > If you're going to `await` for the contacts import to finish anyway, what's the advantage of separating the import logic from your main API? It's blocked, so might as well be part of the same service, no? > I could see maybe if the API returned right away with a pointer the user can later poll for task progr…

That got me stuck too and it wasn't obvious.

I used to use Celery a lot and find Hangfire lacking. To get the same value out of Defer, you'd need to "listen" to those handles.

And listening may actually mean writing another local background job...

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

#98

Post by bayesian_horse »

bluelightning2k wrote: post #4

If we all have at least one cloud, why would we seperate out this one piece and run it in Defer instead? I don't mean to be unkind it's a legitimate question not sarcasm. It just seems like a subset of Cloud Functions or a subset of Lambda - without being connected to the rest or any of our existing workflow, monitoring, secrets, etc.

You already set up that workflow. That can be a major PITA.

Also I don't think this is as much about the "compute" of the background job as much as the nodejs app saying "take care of this for me please, got this? Don't bother me again until I ask for the result".

Endpoint handlers are flaky. They aren't guaranteed to run to completion even through no fault of their own. They should ideally have short and predictable run times, otherwise scaling is much more painful. That's why people separate out certain stuff into those background jobs. And getting that just right, scale it and so on can be quite a bit of work, but yes, something like Cloud Functions or Lambda would serve very similar functions. If you set up all the CI/CD pipelines to make that work.

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

#99

Post by bayesian_horse »

netfortius wrote: post #11

This reminds me of the jobs where I had to come in, "post-mortem", identify source(s) and fix performance, outages, costs and - most importantly - security issues, post "agile" work, in some DevOps orgs, which had no consideration to / interest in at least understanding what was "underneath". In my opinion adding yet another level of abstraction, and asking the creators of the high(est) tier to not [have to] know wha…

Yes, if some projects depend on Defer and that startup blows up because it's not profitable enough or by one of the myriad reasons why most of these companies fail, that's going to be majorly painful.

I mean, basically anyone paying for this service would have to scramble to find and implement another solution once Defer shuts down.

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

#100

Post by bayesian_horse »

johtso wrote: post #83
gearnode wrote: post #71

Earlier quoted context omitted.

Locally (without `DEFER_TOKEN` environment variable), your functions run synchronously, but apart from this, you get the same API behavior (arguments serialization, execution id, etc.).

This is fantastic! I was hoping it would "just work" and seems like it does! Unless I missed it I think the docs should explain this. It would definitely be a selling point for me compared with having to run a local server like with Temporal.

That was one of my questions too. Without a local execution for fallback there are all sorts of problems with this, especially in development.
Post reply on HN