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

Right now, you will need to ensure that your background functions are idempotent but we plan to introduce an API for “retried execution” so you can clean up. Also, by default retry is an opt-in configuration option to avoid any unwanted side effects, the same goes with concurrency.

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.

As @thdxr mentioned, our goal is also to provide top-notch queueing/scheduling features that are complicated to achieve with Lambda/SQS/Cloud Functions, such as dead letter queue support, throttling, or a product-oriented dashboard. In the same idea, we plan to provide better integration, for example, as you mentioned on secrets management by integrating with Doppler, AWS Secrets Manager, and more - the same goes with linked deployment pipelines.

a lot of times these specialized services can really nail a more narrowly scoped feature set to the point where it's worth having stuff running outside of your primary cloud

it always depends, for me personally that bar is very high because like you said, now you have to copy paste secrets into yet another service among other things

some services are so good, like planetscale, especially compared to the cloud option that I'm willing to do that

For our users concerned about data locality, we recommend pushing the minimal data as arguments (ex: ids or external ids) and fetching the data during the execution on our side, if needed, through a dedicated SSH tunneling setup. Once an execution is done, its associated isolated container - gets a dedicated VPC and disk - gets destroyed permanently. We will also provide on-premises solutions for Enterprises.

In local environment (dev), background functions run completely synchronously and locally, no call is made to Defer.

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

> 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, but it doesn't seem like this is the case?

As you suggest, the API returns right away with a pointer the user can later poll to get the function result. Also, using `await` ensures the function is enqueued on our system.

> Side note: I like this type of web design, is it an in-house job or did you hire someone external?

Happy to hear this! We are working with a friend who is a professional designer.

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.

When a background function gets a call from your application, the `defer()` wrapper intercepts this call and pushes an execution to the Defer API with the function’s name and serialized arguments.

I hope it makes thinks clearer, let me know!

[update: grammar]

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 code and enables to write workflows by applying well-known code patterns such as recursion or map-reduce (calling child background functions is a workflow).

Finally, you can write a background function that requires any kind of dependencies, whether they be internal, external, or even native.

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.

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]

We want to enable developers working on a side project to build apps faster and new startups to have a faster time to market by avoiding spending time on infrastructure and building custom layers of API and dashboard.

We also want to help bigger companies to take back control of their custom background jobs stack and to be able to ship new features or sub-products quickly. Again for growing companies, we provide Custom Pricing which comes with degressive pricing with custom concurrency to support, for example, high throughput needs.

I could see this selling fast to corporate

Something something Dropbox, something something rsync.

Charly, Bryan consider yourself flattered.

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.

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.

We use AWS KMS to perform data-at-rest encryption on all data we store. We perform another encryption pass for sensitive data (e.g., Github Token, Secrets, etc.) before storing the data with a symmetric PGP key.

> Is this CronAAS suitable for sensitive workloads?

It should be. Could you elaborate?

Defer: Down and to the right

Not a good look. Calling it now.

If you are able to run and maintain a continuously integrated microservice on a kubernetes cluster (or something similar, maybe severless), then you really don't need Defer, as far as I understand it. There's already a lot of CI/CD and autoscaling open sourced.

I haven't tried it yet, but I guess most of the "runtime" is already open sourced, otherwise the background jobs can't run locally...

We aim to provide a similar feature set as Sidekiq (throttling, unique jobs) but with a complete hosted solution.

While Defer and Temporal can both be used for writing background jobs, workflows, and CRONs, there are some core design differences.

Temporal has been created as the Kubernetes of highly distributed systems, enabling developers to write code that runs on multiple regions without worrying about possible termination of the program and interruption of workflows spanning across multiple steps.

While Temporal can be used for background jobs, workflows, and CRONs, its main goal is to ensure that highly distributed tasks will reliably be executed. That's the main reason why Temporal API is so verbose, with many concepts to deal with.

Defer, on the other hand, provides comparable reliability while focusing on the developer experience.

You can write workflows, CRONs, and jobs that run for hours without worrying about them being terminated.

All this, with a simple API that enables you to write some workflows (background functions calling other background functions) in plain TypeScript, with no mental model to fit in.