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 what's running their "stuff", is like giving chatGPT the task to architect your next app(s).
Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
11–20 of 114 posts
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#12This is an awesome value proposition. Congratulations on launching! I have a project that I've been dreading on how I would tackle its background processing. It is a long-running process that should start and scale based on a user starting his work. I'm AWS certified and still wasn't thrilled about setting this up. Defer would solve this for me. I can see myself suggesting this solution to clients who want to run com…
you’ve not even used it yet
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#13Where are the encryption keys stored? Is this CronAAS suitable for sensitive workloads?
> Where are the encryption keys stored?
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?
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#14I 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, but it doesn't seem like this is the case?
Side note: I like this type of web design, is it an in-house job or did you hire someone external?
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#15I 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…
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.
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#16This may be a bit simplified take but is this sort of like Lambda functions/serverless functions as a service where you can also build the code (nodejs only) ?
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?
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#17This looks really exciting! This is a space that's desperate for innovation. Will be interested to have a play and see what the dashboard looks like. Other options in this field like Temporal have a high learning curve and DevOps cost. Something like Cloudflare Durable Objects are also a very tempting option but require rolling your own visibility / dashboard stuff. I'm guessing this is a "just make sure everything y…
Thank you!
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.
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#18I 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 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.
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#19I 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…
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.
Re: Launch HN: Defer (YC W23) – Zero-infrastructure background jobs for Node.js
#20This looks awesome. I'm really excited about trying this. I'm curious who your target customer for this? As someone who likes to work on side projects, this seems ideal for me, but I would imagine people will graduate to more mature solutions once they have decent volume. The concurrency limit is something that seems especially concerning in that regard.
Thank you, good question!
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.