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

41–50 of 114 posts

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

#41

Post by anon223345 »

fswd wrote: post #31

Why a company with VC backing for something so simple? I am confused why somebody would think this is so important, they would need funding. Anybody with 1-2 years development experience should be able to hack something up in redis or even just crontab and flag files. I use postgraphile graphile-worker https://github.com/graphile/worker for this. For example, every month we roll over credits. For each user, when they…

Most corporate developers don’t really, really suck, but they’re really bad at new things

I could see this selling fast to corporate

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

#42

Post by wittydeveloper »

numinoid wrote: post #25

Not sure if this is intentional, but your blog posts seem to be ordered alphabetically rather than by time. Having that as default behavior feels a bit weird.

The first blog post is actually pinned but an icon or label to highlight this is missing, you're right! I'll fix it soon.

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

#43

Post by anikdas »

I think BullMQ with deployment in kubernetes gets people off the ground quite quickly and scale out quite well without needing to worry about fine tuning the solution. Also RabbitMQ has also worked pretty well for us handling around 150k RPM messages with delayed exchange enabled while running in kubernetes without any tweaks. As a dev working on solution that is used in the industry of customer support, I am more worried about,

1. Data locality

2. Privacy

3. SLAs and Uptimes

While SaaS solutions like these can get us MVP/PoCs fast but a home grown solution is more preferable when SLOs are tight and security is a huge concern.

[edit: formatting]

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

#44

Post by programmarchy »

fswd wrote: post #31

Why a company with VC backing for something so simple? I am confused why somebody would think this is so important, they would need funding. Anybody with 1-2 years development experience should be able to hack something up in redis or even just crontab and flag files. I use postgraphile graphile-worker https://github.com/graphile/worker for this. For example, every month we roll over credits. For each user, when they…

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

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

#45

Post by benatkin »

andrewmcwatters wrote: post #39
benatkin wrote: post #35

Earlier quoted context omitted.

Either you're mistaken or that's the quickest ninja-edit I've ever seen. Sequoia's has a diagonal line through it. Defer's does not.

I'm teasing of course. :)

Haha, I fell for it. Nice :)

Thanks for pointing that out g_delgado14 but I still think it could work as their logo, because with a simple logo it's hard to not make it look a little bit like some other logo.

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

#46

Post by gearnode »

bluelightning2k wrote: post #28

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…

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

You are right. We provide an infrastructure service. We mean by "zero infrastructure" that you don't have to implement and/or manage your own. Our service could run on a platform other than AWS, though, as we are not relying on AWS-only specific services (e.g., lambda, SQS, etc.). Of course, like any other cloud or on-premises service, we could have downtime.

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

Glad to hear this. Although we don't mention it, our client is written in Typescript. If you want to know more, you can check out the code: https://github.com/defer-run/defer.client.

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

#47

Post by jsnk »

Not fully related to this post but ...

I think there's a huge opportunity for whoever that can create Spark or Flink like framework that works in Node.js or at least has Node.js API.

It's a huge challenge to create a tool like that, but I believe there's an appetite for such tool. JS community is huge. JS is a flexible language that can conceptualize distributed computing well. JS community and developer ecosystem generally has superior emphasis on developer experience, outreach and education than the communities around existing tools.

Given how economically valuable companies that exist around big data distributed computing are, I think a company that can create an open source Node.js distributed computing tool will be like the next MongoDB, Elastic and Databricks.

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

#49

Post by bastawhiz »

I don't understand how the example on this page works:

https://docs.defer.run/features/delay/

Does the "defer" directory make the exports of those modules special? Because the defer function isn't called until the endpoint is hit, there's no way to really know (without static analysis, which is a can of worms) which functions will actually get deferred.

Moreover, how does the defer function know, at runtime, which function on the Defer platform needs to run? I could pass any arbitrary function to defer(), which surely can't be run externally. How does the defer platform know which function it can see (by importing my code) is the function my application has called defer() on?

Without knowing exactly the constraints of this, I have a lot of FUD.

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

#50

Post by gearnode »

johtso wrote: post #37
gearnode wrote: post #24

Earlier quoted context omitted.

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.

Just ideally the dev experience should be `result = await somethingThatMayHaveBeenCalledBefore(id=txnref, params)` You shouldn't need to first do a check to see if the task already exists using a different api, and then choose whether or not to run a new task. At least this is my preference.. a-la Durable Objects. If you don't specify a custom unique id when calling the task it would then be treated as a task that ca…

Completely agree with you on the importance of idempotency. We will release our implementation shortly with a pattern close to the following:

``` const somethingThatMayHaveBeenCalledBefore = idempotent(myFunc, txnref); const result = await somethingThatMayHaveBeenCalledBefore(params); ```

Post reply on HN