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

51–60 of 114 posts

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

#51

Post by gearnode »

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…

I can see your point; sometimes, there is little consideration/interest in such issues. We created Defer to try to fix that gap and make it easier to understand and identify problems related to your long-running tasks, not the other way around.

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

#52

Post by wittydeveloper »

pseudostem wrote: post #3

>As a managed platform that brings modern development standards to background jobs (ex: multi-env support, zero-API design), we enable Node.js developers to build products faster and scale without effort and infrastructure knowledge. Can you please elaborate more on the modern development standards bit? I've always been intrigued by changes on development forefront from early 90's time.

Sure, please note that was referring to “modern development standards” in the Node.js ecosystem.

Node.js, with the flexibility of the JavaScript language, allowed the rise of great abstraction and other domain-oriented API designs, a bit like Ruby on Rails did with Ruby.

The arrival of React.js Server Components pattern enabled the isomorphic pattern (first applied to mobile and front-end apps) to reach the server side of things with patterns such as Server side rendering, popularized by frameworks like Next.js or Remix.

Those new patterns and abstractions allow Node.js developers to move faster while building more complex applications to match users’ requirements: real-time, performant apps, richly integrated with third-party products.

Beyond code, those new coding habits came with new products such as Vercel or Supabase that help them to get the infrastructure done in no time, without any DevOps knowledge (good article on this topic: https://vercel.com/blog/framework-defined-infrastructure).

“modern development standards”, applied to Node.js, do not only apply to coding experience and productivity (ex: the rise of monorepos, TypeScript, SSR) but also to enabling developers to configure their infrastructure from the code.

[update: typo]

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

#54

Post by intelVISA »

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…

Simpler is better for VC funding: easier to demonstrate the value prop.

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

#57

Post by wittydeveloper »

lucasfcosta wrote: post #40

I'd be curious to hear about how you've got your first customers. Would you be willing to share that? I can't think of a top-down approach working for technical folks, especially cold outreach.

Sure!

We got our first customers from both channels: network (sales) and inbound (twitter discussions, etc). I agree that top-down is not working well for a newcomers but getting better at a later stage.

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

#58

Post by atleta »

programmarchy wrote: post #44
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?

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 much better uptime than what you could do on-site. And whatever the case is with that, it's still on top of that.)

Abstractions aren't free. (BTW, I don't see it as an abstraction, it's simply outsourcing. You'd use some kind of API anyway even if you hosted the job queue yourself.)

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

#60

Post by wittydeveloper »

anikdas wrote: post #43

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

I agree with you, as mentioned in the article, I’ve built similar solutions as yours at Algolia, using Redis and Kubernetes. However, not all developers know and want to do Kubernetes or RabbitMQ and not all companies can afford to invest time to set up and manage it (https://docs.bullmq.io/guide/going-to-production).

We address privacy by encrypting all the data on our side (doing a second pass with a symmetric PGP key for tokens such as GH tokens, and environment variables) and advise companies that want to keep their data on their infra to push as minimum data in arguments while leveraging a dedicated SSH tunneling setup between our infra and theirs.

When it comes to the SLA/up-time of home grown, my POV would be that, again, achieving good results on those often requires SRE engineers, which is an investment.

Post reply on HN