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

21–30 of 114 posts

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

#21

Post by brap »

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…

I see, makes perfect sense then. I would clarify that in the example (maybe add another snippet for querying the status).

If your friend is open for business, maybe give them a shoutout ;)

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

#22

Post by wittydeveloper »

johtso wrote: post #16
wittydeveloper wrote: post #10

Earlier quoted context omitted.

The Builder part is clearly a differentiator; however, background functions are different from Serverless functions on many points - on top of being natively integrated with our Scheduler. First, they allow a maximum execution time comparable to “pure server” environments, instead of 15min. Then, the code-first approach allows configuring the execution parameters (concurrency, retries, and more) from the function’s c…

Oh interesting! So say if you wanted to call 3rd party API in your function, with some exponential backoff retry, without blocking your concurrency allowance, would you model that as recursively calling the same function with an attempt argument? Does this look nice in the observability layer?

Yeah, that will be the way to go. This is actually how on of customers is achieving this behaviour for polling analytics.

Right now our Executions list is not ideal for such pattern but we will soon release filtering based on arguments which will help to get all the executions linked to a specific sequence.

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

#23

Post by johtso »

gearnode wrote: post #19
johtso wrote: post #15

Earlier quoted context omitted.

Yeah it's not clear how you uniquely reference a task, a super core feature and something that the Temporal documentation for example covers very early on.

When enqueuing an execution, you get back a unique ID referencing it. We will make that clearer in our documentation, thanks.

Often you want to specify your own unique id based on some property of the job, like a transaction reference, or just a unique combination of parameters. This means you can later refer to it without having to store the reference somewhere. Is this possible?

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

#24

Post by gearnode »

johtso wrote: post #23
gearnode wrote: post #19

Earlier quoted context omitted.

When enqueuing an execution, you get back a unique ID referencing it. We will make that clearer in our documentation, thanks.

Often you want to specify your own unique id based on some property of the job, like a transaction reference, or just a unique combination of parameters. This means you can later refer to it without having to store the reference somewhere. Is this possible?

We specify our unique ID based on KSUID specifications. In addition, we are soon releasing the tag feature, which will enable you to store your references on your Defer executions to identify them your way.

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

#26

Post by gearnode »

brap wrote: post #21
gearnode wrote: post #18

Earlier quoted context omitted.

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

I see, makes perfect sense then. I would clarify that in the example (maybe add another snippet for querying the status). If your friend is open for business, maybe give them a shoutout ;)

> I see, makes perfect sense then. I would clarify that in the example (maybe add another snippet for querying the status).

It is true that we don't elaborate on this point on our landing page. We will take that into consideration, thanks.

> If your friend is open for business, maybe give them a shoutout ;)

Again, glad you like his work! He's not available at the moment, but we will stay in touch :)

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

#27

Post by chronicom »

A couple of days ago, I was actually thinking about the impact long-running analytical queries would have on the costs when using edge functions that are billed by GB-s, so this is a rather interesting solution.

Just a small note that on the landing page, the snippet under Define has the file path `defer/helloWorld`, while the snippet in Enqueue is importing `importContacts` from `defer/importContacts`. As I was reading it, I thought it seemed as if the Enqueue snippet was supposed to be importing from the snippet written under Define. Just thought I'd mention it in case that's what it's supposed to show.

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

#28

Post by bluelightning2k »

I'm kind of perplexed by this.

It's very clearly infrastructure. Putting "zero infrastructure" in the title and using the same API as Lambda invoke etc. doesn't make it true.

I also get double the risk of downtime, security as it's a third party running on top of AWS vs. just running on AWS.

The API looks nice - but no mention of typescript at all in this post or the website, so presumably type-safety isn't the thing.

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

#29

Post by consequential »

What gets run on your infrastructure and what gets run locally?

This is imporant as I'm not sure I'd want to trust yet another service provider with my customers' data, especially one that is VC-backed and therefore inherently less trustworthy in the long-term than others.

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

#30

Post by gearnode »

chronicom wrote: post #27

A couple of days ago, I was actually thinking about the impact long-running analytical queries would have on the costs when using edge functions that are billed by GB-s, so this is a rather interesting solution. Just a small note that on the landing page, the snippet under Define has the file path `defer/helloWorld`, while the snippet in Enqueue is importing `importContacts` from `defer/importContacts`. As I was read…

Thanks for your interest! Also thanks for the side note on the snippet, we just fixed it.
Post reply on HN